Skip to content
Ownkube

Environments

An environment is a way to organize related deployments by stage. Ship a web app and its worker to Development, promote the same image to Staging, and keep Production on a separate, stable config. All from one dashboard.

Manage them from Settings.

How environments work

Section titled “How environments work”
  • Every organization starts with two defaults: Development and Production. You can create as many more as you need (e.g. staging, qa).
  • A deployment belongs to one environment. Deployments in the same environment share a logical boundary. Names must be unique within the environment, so you can have api in both Development and Production without collision.
  • Environments get color-coded badges so dev vs prod is visually obvious throughout the dashboard.
  • In your own cloud, environments are also cluster-scoped: a deployment belongs to one cluster and one environment, and the uniqueness rule is the cluster + environment pair.

Logical grouping

Organize applications by stage, team, or purpose. However you structure your workflow.

Scoped configuration

Each deployment keeps its own env vars, scale, and image tag. Staging and production stay independent.

Visual isolation

Color-coded badges in deployment lists and the top nav.

Shared infrastructure

Run as many environments as you need side by side. No need to pay for separate infrastructure per stage.

Creating an environment

Section titled “Creating an environment”

  1. Open Settings

    Go to Settings.

  2. Click New environment

    Pick a name (e.g. staging, qa) and a color. The color shows up wherever this environment is referenced.

  3. Start deploying to it

    The new environment appears in the Environment dropdown when you create a deployment from your dashboard.

A typical layout in your own cloud

Section titled “A typical layout in your own cloud”

On the Advanced own-cloud path, most teams settle on this pattern, splitting stages across cluster shapes:

  • Development on a cheap Starter cluster (K3s on one AWS instance). Free Ownkube platform fee, you only pay AWS for the EC2 instance.
  • Production on a Production cluster (managed EKS). Highly available across availability zones, autoscaling.

Both are visible side-by-side in the dashboard. Each environment keeps its own env vars, replica count, and resource limits.

Viewing an environment

Section titled “Viewing an environment”

Each environment and its deployments are visible under Settings. For each environment you can see:

  • All deployments tagged to this environment
  • Health rollup: healthy / syncing / degraded counts at a glance
  • Shortcuts: jump into any deployment’s detail page in one click

Using environments in a deployment

Section titled “Using environments in a deployment”

When you create a deployment from your dashboard:

  • Environment is a required field. Pick an existing environment or create a new one inline.
  • The selected environment becomes part of the deployment’s identity. Changing it later requires a separate flow.

Limits and constraints

Section titled “Limits and constraints”
  • Environment + name is the uniqueness rule (the cluster + environment + name triple in your own cloud). The same deployment name can exist in different environments.
  • Deleting an environment requires no deployments to be tagged to it first.

On the roadmap

Section titled “On the roadmap”
  • Environment-level variable overrides: set a variable once at the environment level and have it inherit to every deployment.
Deployments The four resource types that live inside an environment.
Clusters Advanced own-cloud path: how environments map onto clusters in your AWS account.