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.

Copy compatible configuration from another instance of the same app
Pause idle instances while preserving configuration and persistent data
Keep one stack definition while changing settings per environment
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 self-hosted Kubernetes environments 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 self-hosted Kubernetes 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.

Start a new environment from compatible existing configuration

Reuse the choices that still fit instead of rebuilding every new app instance field by field.

When you add an instance to an existing app, Wodby can prefill compatible configuration from another instance of that app. The new instance still uses its selected stack revision and remains an independent environment; the copy step provides a reviewed starting point rather than cloning runtime state.

  • Copy CI and container registry selections for future builds.
  • Reuse compatible public build boilerplates and connected Git repositories.
  • Prefill supported service settings, integrations, and volume sizes.
  • Reuse compatible external database selections only after reviewing the connection.
Imports, backups, persistent-volume data, and database data are not copied. If the source uses an existing external database, copying its selection can connect both instances to the same database; choose a different or new database when the environments must stay isolated.

Pause an idle environment without deleting it

Stop Kubernetes workloads when an environment is not needed, then resume it with its configuration and persistent data still in place.

On paid plans, pausing scales application workloads to zero, stops scheduled and active workload resources, and makes the instance's endpoints unavailable. Routes, configuration, secrets, persistent volumes, and Helm releases remain associated with the instance so it can be resumed later.

  • Release requested workload CPU and memory back to the Kubernetes cluster.
  • Stop counting enabled services toward app-service plan usage after Kubernetes verifies the pause.
  • Skip automatic cron jobs and backups that become due while the instance is pausing, paused, or resuming.
  • Resume explicitly when the environment is needed again; a pause has no automatic expiration.

Persistent storage and cluster infrastructure remain provisioned and may continue to incur separate costs. Read the app instance pausing announcement or the lifecycle documentation for the full behavior.

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