Skip to main content

​
What It Does

Capsules gives every Git branch its own production environment — same cloud provider, same cluster topology, same container images, same deployment pipeline. The only difference is it runs your branch instead of main, and there are no users hitting it. Secrets can be shared with production or overridden per capsule. Push a branch — Monk provisions a dedicated cloud cluster, builds your app, and deploys it with a unique TLS-enabled preview URL. Merge or delete the branch — the cluster is destroyed and all resources are released. No shared staging. No environment conflicts. No forgotten resources running up cloud bills. Available on Pro and Team plans.
Capsules and CI/CD are complementary. CI/CD deploys a selected branch (typically main) to an existing, long-lived cluster. Capsules uses CI/CD to create isolated, ephemeral clusters for every other branch — each cluster lives only as long as the branch does.

​
Problems It Solves

The staging bottleneck. Teams share a handful of staging environments. Developers queue up to test, conflicts arise when multiple features land on the same environment, and bugs slip through because the test environment doesn’t match what ships. Capsules eliminates this — every branch gets its own isolated environment. AI code verification. AI agents can generate code, but without a real environment to deploy into, they can’t verify it works. Capsules give agents a production-grade environment to deploy, test, and iterate against — so the output is code that demonstrably works, not code that should work.

​
Setup

Open the Monk chat and say: 
set up Capsules
You can also say “enable preview environments” or “set up dynamic environments.” Monk walks you through a few choices:
1

Choose your cloud

Pick a cloud provider — AWS, Azure, GCP, or DigitalOcean — and select a region and instance size for capsule clusters.
2

Configure branch filtering

Choose which branches to exclude (typically main and master — your permanent environments). You can also filter by naming convention.
3

Monk generates everything

Monk creates a GitHub Actions workflow and supporting scripts, pushes all required credentials (cloud keys, API tokens) to GitHub as encrypted secrets, and commits the configuration to your repository.
4

Commit and push

Commit the generated files and push:
git add .github/workflows/dynenv.yml scripts/
git commit -m "Add Monk Capsules configuration"
git push
That’s it. From this point on, everything is automatic. You need:
  • A project already deployed through Monk with a build manifest
  • A GitHub repository with Actions enabled
  • Cloud provider credentials for at least one provider
  • An organization and project set up in Monk (Monk prompts you if these are missing)

​
The Automatic Lifecycle

Once Capsules is configured, the lifecycle is fully automatic:
Git eventWhat happens
Push a branchA new cluster is provisioned, containers are built, and the app is deployed. A pull request is auto-created.
Push again to the same branchThe app is redeployed with the latest code. No new cluster needed.
PR is merged or branch is deletedThe cluster is destroyed and all cloud resources are released.
Each capsule appears as a GitHub Deployment, so status is visible directly in pull requests — reviewers can see whether the environment is live, deploying, or failed without leaving GitHub.

​
Schedule Policies

Capsules don’t need to run 24/7. Schedule policies control when environments are up or down so you’re not paying for idle clusters overnight. Set a schedule: 
set capsules to run weekdays 8am-7pm UTC
Check the current schedule: 
show capsule schedule
Override for a specific capsule: 
override the schedule for the feature-auth capsule
Clear an override: 
clear the schedule override for feature-auth
Schedule options:
  • Daily windows — e.g., up from 8 AM to 7 PM, down overnight
  • Weekly windows — e.g., only on weekdays
  • Per-capsule overrides — keep a specific capsule up during a demo, or shut one down early
Schedules can be set at the project level (applies to all capsules) or overridden per capsule. A background job enforces the schedule hourly.

​
Managing Capsules

The Monk extension has a dedicated Capsules panel in the Infrastructure view where you can see all active capsules, their branch, status, cluster, and preview URL. You can also manage everything through the chat: List active capsules: 
show my capsules
Tear down a capsule manually: 
destroy the capsule for feature-auth
Provision a capsule manually: 
provision a capsule for the feature-auth branch

​
Updating Secrets

Capsule secrets can be updated in two modes: 
update capsule secrets
Monk asks you to choose:
  • Global — updates GitHub encrypted secrets and the workflow. Affects all future capsules. Requires a commit and push.
  • Local — injects secrets directly into the running capsule via the CLI. Immediate, but only affects that one instance.

​
Manual GitHub Actions Dispatch

The generated workflow supports manual dispatch from the GitHub Actions tab. You can trigger provision_deploy, deploy, deprovision, or destroy for any branch.

​
How Teams Use It

  1. A developer creates a feature branch and pushes code
  2. Within minutes, a fully deployed preview environment is live
  3. The developer shares the preview URL in the PR for review
  4. QA tests directly against the capsule — no waiting for staging
  5. Product reviews the feature in an isolated, realistic setting
  6. The PR is approved and merged — the capsule cleans itself up
No infrastructure tickets. No environment conflicts. No forgotten resources.

​
For AI Agents

An AI coding agent can use Capsules to verify its own work:
  1. Create a branch and write code
  2. Push the branch — a capsule spins up automatically
  3. Hit real endpoints, observe real behavior, read real logs
  4. Find issues, fix them, push again — the capsule redeploys
  5. Hand off a working, verified pull request — not a guess
The agent operates against a real running system that mirrors production, iterates until things work, and only surfaces results when they’re validated.

​
Key Details

  • Multi-cloud — AWS, Azure, GCP, and DigitalOcean
  • Full isolation — each capsule runs on its own cluster with no shared state
  • GitHub-native — uses GitHub Actions for orchestration and GitHub Deployments for status tracking
  • Secure credentials — cloud credentials and app secrets stored in GitHub’s encrypted environment secrets; short-lived tokens minted at runtime
  • Preview URLs — every capsule gets a TLS-enabled shareable URL
  • Branch filtering — include or exclude branches by pattern

CI/CD

Deploy a selected branch to a long-lived cluster — the pipeline Capsules builds on

Multiple Environments

Permanent staging, production, and dev environments on long-lived clusters