Skip to main content

What It Does

Monk supports multiple deployment environments per workspace, such as staging, production, or any custom name. Each environment has its own configuration and links to a specific cluster, so deployments stay isolated even when they share code.

How It Works

Creating Environments

Ask Monk to set up environments for your project:
create staging and production environments
Monk creates separate environment configurations and asks which cluster each should use.

Environment-Specific Builds

When building for an environment, Monk tailors the configuration:
build for production
What’s customized: Environment-specific variable values, managed service selections, and sizing are tailored for the target environment.

Deploying to Environments

Deploy to a specific environment by name:
deploy to staging
Monk automatically: Monk switches to the cluster linked to that environment, builds only what’s needed for it, and deploys using its configuration.

Linking Environments to Clusters

Each environment can be linked to a specific cluster. Via Monk (when deploying): When you deploy to an environment, Monk asks which cluster to use if not already linked:
deploy to staging
Monk: “Which cluster should I use for staging environment?” Via Clusters panel (visual management): Open the Clusters panel to see and manage environment-cluster associations. How linking works: Each environment links to one cluster. Multiple environments can share a cluster with separate tags, or each environment can have its own cluster. Changing a link does not affect existing deployments.

Multiple Simultaneous Environments

Deploy to multiple environments in one request:
deploy to staging and production
Monk deploys each sequentially to their respective clusters.

Environment Use Cases

Development → Staging → Production:
You: Create dev, staging, and prod environments
You: Link dev to my-local-cluster
You: Link staging to my-digitalocean-cluster
You: Link prod to my-aws-cluster
You: Deploy to all environments
Each environment deploys to its designated infrastructure. Feature branches:
You: Create feature-auth environment
You: Deploy feature-auth to my-test-cluster
Test new features in isolation before promoting to staging. Multi-region deployments:
You: Create us-prod and eu-prod environments
You: Link us-prod to my-aws-us-cluster
You: Link eu-prod to my-aws-eu-cluster
Deploy the same application to multiple regions as separate environments.

What Makes This Different

Traditional environment management requires:
  • Separate configuration files per environment (.env.staging, .env.prod)
  • Manual variable substitution
  • Complex CI/CD pipelines to manage deployments
  • Keeping environments synchronized
  • Remembering which cluster maps to which environment
With Monk: Define environments once. Deploy by name. Monk handles configuration, cluster switching, and isolation automatically.

Key Capabilities

Environments are flexible in name, visually managed in the Clusters panel, and isolated by their linked clusters. In an organization context, environments can target org clusters, which makes deployments consistent across team members even if each person defines environments in their own workspace.

Managing Environments

List environments:
You: What environments do I have?
Check which cluster an environment uses:
You: Which cluster is linked to staging?
Delete an environment:
You: Delete the dev environment
Visual management: Open the Clusters panel to see all environments and their cluster associations at a glance.

Team Environments

When working in an organization context, environments can target org clusters. This makes deployments consistent across team members even if each person defines environments in their own workspace. Team-scoped secrets are also environment-scoped, so staging and production can have different secret values. → See Team Collaboration for details on shared clusters and secrets.