App instances and environments

App instances and environments that stay consistent from dev to production

Create isolated app instances linked to environments for development, QA, staging, previews, and production from one shared stack definition.

Wodby lets your team reuse the same application blueprint across every environment, with app instances connected to the right environment type and settings at each stage of delivery. That means faster previews, safer releases, and fewer environment-specific surprises.

Launch preview, QA, or staging environments in minutes
Keep one stack definition while changing settings per environment
Use the same workflow across production and non-production
Create an app environmentSee application stacks

Choose the right infrastructure for each environment

Production and non-production environments usually do not need the same cost profile. Wodby lets you keep one delivery model while changing where an instance runs.

Run production instances on managed Kubernetes for resilience, while development and staging can sit on leaner K3S clusters to lower cost. Your team still works through the same interface and deployment flow in every case.

  • Keep production on a cluster built for uptime and operational consistency.
  • Use smaller K3S environments for feature work, QA, and internal testing.
  • Avoid one-off provisioning steps when a team needs another environment.

Apply environment-specific settings without branching your stack

Environment differences should live in configuration, not in parallel infrastructure definitions that drift over time.

Wodby lets every application instance inherit a shared base configuration and then apply the settings that only make sense for a specific environment. You can turn on debugging in development, keep tighter security in production, and preserve production-like behavior in staging without maintaining separate stacks for each stage.

  • Production environments focused on reliability, performance, and security.
  • Development environments tuned for debugging and rapid iteration.
  • Staging, testing, and feature environments that mirror production where it matters.

Roll out configuration changes from one shared stack

A central stack definition keeps environment changes intentional and easier to review before they reach production.

Each app instance starts from a versioned application stack. When you change services, configs, or variables in that stack, you can decide when each environment should pick up the update. This reduces configuration sprawl and makes the relationship between development, staging, and production much easier to reason about.

  • Test infrastructure changes in lower environments before production.
  • Keep a clear revision history for application configuration changes.
  • Let teams manage their own instances without losing central control.

Support safer releases and faster feedback loops

Isolated environments make it easier to validate work before it reaches customers.

When developers, QA, and stakeholders can work in dedicated environments, release work stops competing for the same shared setup. That gives teams a cleaner path for feature testing, bug reproduction, and final verification before a production rollout.

Combined with CI/CD, app instances become a practical way to shorten review cycles while protecting production from unfinished changes.

Next step

Create the next environment without recreating your platform

Ship feature branches, staging builds, and production releases from the same application blueprint while keeping clear boundaries between environments.

Start with app instancesRead the docs