Services

Start with the right services already in place

These are the services enabled by default when you create a new instance from the Laravel stack.

Stack services can be configured, added or removed for specific instances, and their versions can be changed as your workload evolves.

Stack serviceBase serviceRole
Nginx (Laravel)Primary
PHP (Laravel)Required
MariaDBRequired
ValkeyRequired
Ganesha NFS provisionerEnabled by default
MailpitEnabled by default

Explore the full stack service catalog for configs, settings, actions, cron, volumes, links, backups, and imports attached to each service in this stack.

Deploy

Run the same stack on the hosting model that fits

The stack stays the same while the hosting model changes. That lets you keep one stack across lighter environments, production clusters, and self-managed servers.

Wodby Cloud

Start without running a cluster in your own account when you want the most managed option.

Managed Kubernetes

Keep the cluster in your own cloud account while using the same stack to deploy and operate the app.

K3S on your own server

Run the same stack on a VM, bare-metal, or dedicated server when you want a leaner self-managed setup.

Explore hosting options for this stack to compare Wodby Cloud, managed Kubernetes, and K3S in more detail.

Get started

Start a new Laravel app from this stack

Launch a new app instance from the same enabled services, integrations, hosting options, and upgrade model outlined on this page.

Databases

Choose the right database model for each environment

This stack can run container-based databases such as MariaDB and also connect to managed database services such as Cloud MariaDB and Cloud MySQL.

Container databases in this stack

Explore database options for this stack for container services, managed providers, and the connection model used by this stack.

CI/CD

Start shipping from ready boilerplates and stack-aware CI/CD

PHP can build from source as part of this stack.

We already provide public build templates with a Wodby CI pipeline, so you can fork a working boilerplate or connect your own repository from a supported Git provider. External CI and registry integrations still fit the same stack-aware build and release flow.

Public build templates

Connect your Git repository

Explore CI/CD for this stack for boilerplates, Git connections, CI providers, and registries.

Backups

Automate backups and move data between environments

Container-based services in this stack can run automatic backups, upload archives to connected cloud storage, and import working data into other environments when teams need realistic copies.

Run automatic backups on a schedule

Keep backup workflows attached to the stack instead of rebuilding them manually for each environment.

Refresh other environments with working data

Import from an archive, uploaded file, or public URL to create realistic staging copies, onboard developers faster, or test against working data.

Upload backup archives to cloud storage

Send backup archives to third-party storage instead of keeping them only inside the platform.

Services with backup workflows

Explore backups and migration workflows for archive destinations, restore paths, and ways to move working data onto Wodby.

Get started

Migrate an existing Laravel app to Wodby

Use backup and import workflows to move an existing app, refresh another environment, or plan a staged migration onto this stack.

Email

Deliver email reliably with trusted SMTP providers

Mailpit catches outbound mail in development environments, while OpenSMTPD relays real email through trusted SMTP providers when you are ready to deliver it.

Email services in this stack

Trusted SMTP providers

Explore email delivery for this stack for development mail capture, SMTP relays, and provider-backed delivery.

Integrations

Reuse connected providers and secrets across environments

Secrets, variables, and provider credentials belong to the stack so every new instance starts from the same integration model instead of copying values by hand.

That includes product integrations like Algolia, AWS, Anthropic, Auth0, and Cloudflare, and others.

Explore all integrations for this stack to browse email relays, storage, CI/CD, Git, managed databases, registries, and variable-based providers.

Configs

Reuse service configs and settings across environments

Configure services once, override values per environment where needed, and reuse the same setup across many environments or multiple related instances built from this stack.

Explore configs and settings in the full service catalog for the exact stack-level knobs this stack exposes.

Cron and actions

Keep recurring jobs and maintenance steps repeatable

Cron schedules and lifecycle actions are part of the stack, so maintenance workflows and recurring jobs can be reused across environments instead of recreated manually.

Explore cron schedules and actions to see the repeatable maintenance and scheduled jobs defined for this stack.

Stack control

Stay current with managed stack updates

Included service updates can mark the stack as outdated. Upgrading the stack releases a new revision, but existing instances stay on their current revision until you decide to move them or enable automatic updates.

Explore stack control to see how revisions, app-by-app upgrades, and auto-updates work.

Domains and TLS

Use technical domains with auto-renewed TLS

HTTP services in this stack can get technical domains with auto-renewed TLS certificates, so secure preview and non-production environments are ready without extra setup.

Explore technical domains and SSL to see how certificates are issued and renewed automatically.

Environments

Create new environments from the same stack in minutes

Reuse the same Laravel stack for development, staging, production, customer-specific environments, or short-lived feature branches, with per-environment values and configuration overrides where needed instead of rebuilding the stack every time.

Create development and staging environments from the same stack

Teams can test against the same enabled services and integrations instead of maintaining a separate setup for non-production environments.

Spin up dedicated feature environments when teams need them

Short-lived environments can reuse the same stack instead of forcing teams to create a new stack for every branch or task.

Preview app instances on branch push are coming soon

Automatically create a new preview environment on branch push. Coming soon.

Explore app instances for reusable environments, preview apps, and branch-based workflows.

Get started

Launch a new Laravel environment in minutes

Use the same stack for development, staging, production, and other app instances without rebuilding the definition for each environment.

FAQ

Common questions about the Laravel stack

What does the Laravel stack include?

Laravel application stack for teams that want a reusable setup for web, worker, and queue-based PHP projects. Instances created from this stack inherit the services enabled by default, attached integrations, hosting options, and stack revision history.

How can one stack support multiple apps and environments?

You can reuse the same stack for multiple similar apps and for development, staging, production, and other environment types. The stack defines the shared services and defaults, you can set different values for env types such as dev and prod, and each app instance can still be configured individually.

How do stack updates work?

When an included service gets an update, the stack can be marked as outdated. Upgrading releases a new stack revision, but existing instances stay on their current revision until you upgrade selected ones manually or enable automatic updates.

How do integrations work with this stack?

Use the Integrations section to attach providers to this stack. That keeps SMTP relays, backup storage, managed databases, and other providers connected to the reusable stack definition instead of configuring them separately for every app instance.

How should I handle CI/CD for buildable services in this stack?

Start from the provided build templates. They already include a basic Wodby CI pipeline definition in .wodby/pipeline.yml.

You can also use the public wodby/wodby-ci repository as a starting point or reference.

If you prefer your own CI system, run Wodby CLI from GitHub Actions, CircleCI, or similar. It reads your stack information and performs the build, release, and deploy steps for connected services.

Can app instances from this stack run on different infrastructure?

Yes. Development and production instances from the same stack can run on different hosting models, including Wodby Cloud, managed Kubernetes, and K3S on a VM or dedicated server, while keeping the same stack definition and upgrade path.