Application stacks
Reusable stacks for repeatable infrastructure delivery
Define your services and configuration once, then use the same blueprint everywhere your application runs.
Wodby stacks give teams a durable infrastructure definition for application delivery. Instead of rebuilding services and configuration for every environment, you keep one stack, version it over time, and decide when each app instance should adopt a change.
Create the blueprint once and reuse it everywhere
Stacks define the services and configuration behind an application so you do not have to rebuild the same setup for every environment.
A stack contains the services your app depends on, such as Nginx, PostgreSQL, Node.js, and supporting integrations. You can start from one of Wodby's predefined stack templates or build your own, then apply that definition to any number of app instances.
- Keep service choices and configuration in one place.
- Create new environments faster because the blueprint already exists.
- Reduce drift between development, staging, and production.
Manage the full stack lifecycle from setup to upgrade
Stacks are not only reusable definitions. They give teams a repeatable operating model from initial setup through controlled rollout.
- 1
Choose how to start
Add a predefined stack from the catalog, create one from scratch in the UI, or import a stack template from your Git repository using the stack template guide. - 2
Configure the stack for future apps
Prepare it as a reusable blueprint: connect buildable services, choose service versions, and define integrations and environment-aware settings once. - 3
Create apps and extra environments
Launch the application from the stack, then add development, staging, customer-specific, or other environments without recreating the infrastructure model. - 4
Issue new revisions from updates or config changes
Service updates and manual stack edits both create explicit revisions, so infrastructure changes remain visible and deliberate. - 5
Upgrade each instance on its own schedule
Roll new revisions out environment by environment when each app is ready instead of forcing one all-at-once infrastructure change.
Version stack changes before they reach production
Infrastructure updates should be deliberate, reviewable, and easy to stage.
Every change to a stack creates a new revision. Running applications keep using their current revision until you decide to upgrade them, which makes it easier to test service changes or configuration edits in lower environments before they land in production.
- Test stack changes safely before a broader rollout.
- Keep a history of how infrastructure evolved over time.
- Separate the act of changing a stack from the act of deploying it.
Track important service updates with less manual review
Shared stack definitions also make it easier to keep services current.
When you use services from the Wodby catalog, the platform can alert you when stack components need attention. That helps teams spot important updates earlier and plan upgrades through the same revision workflow instead of reacting late to drift or vulnerabilities.
Handle environment differences without duplicating the stack
Consistency matters, but production, staging, and development still need different settings.
Wodby stacks support environment-aware configuration, so the same stack can apply production-only safeguards, development debugging tools, or staging-specific resource values where they belong. You get the benefits of a shared blueprint without forcing every environment to behave identically.
Give more of the team access to infrastructure changes
Stacks turn complex infrastructure work into a workflow more people can understand and review.
Instead of pushing every infrastructure task into raw Kubernetes YAML or bespoke automation, Wodby exposes stack management through the same interface used for the rest of the platform. That keeps platform control accessible to product teams without removing guardrails.
Shared vocabulary
Teams work with stacks, revisions, and app upgrades instead of ad hoc infrastructure scripts and one-off cluster changes.
Safer collaboration
Platform changes become easier to reason about because they live in a workflow the wider team can review and understand.
Next step
Standardize how your team ships infrastructure changes
Move from ad hoc environment setup to a repeatable stack model that supports safer updates and clearer ownership.