Build infrastructure bundles for Massdriver — the internal developer platform that turns infrastructure-as-code into reusable, self-service components with built-in guardrails.
Describe what you want, and Claude designs the bundle, deploys it to a throwaway environment, and iterates until it's working and compliant. It drives Massdriver through the MCP server, which the plugin registers for you — that's why Docker is a prerequisite alongside the mass CLI.
# Add the marketplace
/plugin marketplace add massdriver-cloud/claude-plugins
# Install the plugin
/plugin install massdriver@massdriverThe plugin launches the Massdriver MCP server via a bundled script (scripts/run-mcp-server.sh) that runs the official Docker image — no local binary or language toolchain needed. The only prerequisite is Docker installed and running (Docker Desktop on macOS/Windows, Docker Engine on Linux).
The script runs the container as your user with --pull always, so every Claude Code session starts on the newest published image (an up-to-date image is a fast metadata check, not a re-download), and your ~/.config/massdriver is mounted read-only when it exists. Both auth modes work out of the box:
# Option A — environment variables (take precedence):
export MASSDRIVER_API_KEY="your-api-key"
export MASSDRIVER_ORGANIZATION_ID="your-org-id"
export MASSDRIVER_URL="https://api.massdriver.cloud" # optional; only for self-hosted instances
# Option B — profiles: nothing to do. Your ~/.config/massdriver/config.yaml is
# mounted into the container; the `default` profile is used unless you export
# MASSDRIVER_PROFILE=<name>.Export before you launch Claude Code. The MCP server is a container started once at
session start, and it inherits these variables from the environment Claude Code itself was
launched with. Nothing set afterwards can reach it — not a shell export (Claude Code's Bash
calls are separate, non-persistent shells), and not mass_profile in
.claude/massdriver.local.md, which only the agent reads. To change organization or profile,
exit Claude Code, export, and start a new session.
Optionally pre-pull before your first session to skip the initial download delay: docker pull massdrivercloud/mcp-server.
Verify with /mcp in Claude Code — the massdriver server should be listed with its tools.
Troubleshooting:
- Server shows as failed → the launcher prints the exact reason to stderr (visible via
claude --debugor the/pluginErrors tab): Docker not installed, daemon not running, or missing credentials in the shell that launched Claude Code. - On native Windows (non-WSL), the launcher requires bash — run Claude Code inside WSL, or override the
massdriverserver in your project.mcp.jsonwith a plaindockercommand.
Interactive workflow for creating and testing bundles with deploy loop and compliance remediation.
/massdriver:develop PostgreSQL database for application backends with dev/staging/prod presets
/massdriver:develop S3 bucket for static asset storage with CloudFront CDN
What it does:
- Gathers your design intent (UX, constraints, connections)
- Scaffolds the bundle with best practices
- Sets up a project and an ephemeral test environment
- Adds the bundle to the project's blueprint, so every environment gets an instance
- Deploys it, streaming the logs as they happen
- Iterates: code change → republish → redeploy, until it works
- Remediates compliance findings automatically
- Tears the infrastructure down, then journals what was tested on the environment
Validate bundle version upgrades by forking the production environment and copying its instance config to a test environment.
/massdriver:test-upgrade api-prod-database 1.3.0
Instance identifier format {project}-{environment}-{component}.
What it does:
- Forks production into a test environment, carrying its config across (secrets, remote references, and environment defaults are opt-in)
- Diffs the fork against prod to confirm it's a faithful mirror, low-scaling any dependencies that don't need to match
- Deploys the current version as a baseline
- Bumps to the target version, redeploys, and reports exactly what changed — bundle version and param-level diff
- Tells you whether the upgrade is safe to roll out, then tears the test environment down
Generate a bundle without the deploy loop.
/massdriver:gen RDS MySQL for OLTP workloads
Bring cloud infrastructure that already exists (created by hand, by another IaC tool, or in another account) under Massdriver. The command asks how you want to import, then the agent runs the matching workflow.
/massdriver:import existing production RDS Postgres instance created by hand
Three paths (you choose up front):
- New bundle — author a new reusable bundle, publish it, add it to the blueprint, then
tofu importthe resource into that instance's managed state. - Existing bundle — reuse a published bundle, create/pick an undeployed instance, then import into its managed state.
- Register resource only — create an imported Massdriver resource so other components can connect to it, with no IaC and no lifecycle management.
Paths 1 and 2 put the resource under Massdriver's IaC management; path 3 only makes it
referenceable. Bundles have to stay reusable, so adoption uses the imperative tofu import
command against the instance's Massdriver-managed HTTP state backend — not import {}
blocks, which would hardcode one cloud resource ID into source shared by every instance. The
import runs locally, but the plan runs in Massdriver's provisioner — never tofu plan locally,
where credentials and compliance checks don't apply. The agent loops import → publish → re-plan
until the plan comes back clean, then proposes a deployment with the params that planned clean.
Nothing deploys until you approve that proposal.
Not to be confused with
mass bundle import, which scans a bundle's IaC for variables not yet exposed as Massdriver params.
Turn a plain-language app idea into a governed Massdriver project: the agent probes the (grant-filtered) platform catalog, recommends project layout/bundles/runtime (decisively — it states its reasoning rather than asking), builds and publishes the app bundle directly to the platform, and promotes through environments gated by your permissions. If a needed capability has no granted bundle, it tells the user exactly what to request from their DevOps team instead of improvising infrastructure.
/massdriver:architect a serverless API that resizes uploaded images and stores them in S3
- Design once, deploy everywhere. A component is added to a project's blueprint one time; every environment automatically gets an instance of it. Wire one component's output to another's input and the connection follows into each environment.
- Deploy and watch in one step. Every deploy streams its logs back, so Claude sees failures and Checkov findings as they happen and can act on them without you relaying output.
- Dry runs are always safe. Plans never touch infrastructure and are allowed anywhere, including production — so Claude can check its work before proposing a change.
- Development releases stay out of everyone's way. Publishing with
--developmentand pinning a test instance tolatest+devmeans your iteration never reaches instances on stable. - Day 2 is covered. Fork production into a test environment, upgrade it, diff the result, and roll back if it regresses. Changes that need sign-off can be proposed instead of applied, for a human to approve.
- Environment-scale operations. Deploy or decommission a whole environment in dependency order, or mirror one instance's config onto another with overrides.
This plugin helps platform engineers create and test Massdriver bundles — reusable IaC modules that package OpenTofu, Terraform, or Helm with input schemas, resource type contracts, and operational policies.
Capabilities:
- Interactive development: Full deploy loop with compliance remediation
- Brownfield import: Adopt cloud resources that already exist into bundles, or register them so other components can connect to them
- Upgrade testing: Validate version upgrades against a faithful copy of your production config before rolling them out
- Safety guardrails: Blocks non-development publishes, production deploys and teardown, and automated deployment approval, and asks before any production configuration change — across BOTH
massCLI commands and MCP tool calls - Compliance automation: Iterates until Checkov findings are resolved
- GraphQL reference: Multi-entity queries for when one query beats a chain of tool calls
The plugin auto-activates when:
- Working in
bundles/,resource-type/,platforms/, orprojects/directories - Editing
massdriver.yamlfiles - Asking about bundles, resource types, components, instances, connections, or Massdriver patterns
- Requesting to create, develop, or test bundles
claude-plugins/
├── .claude-plugin/
│ └── marketplace.json
└── massdriver/
├── .claude-plugin/
│ └── plugin.json
├── .mcp.json # Points at the MCP launcher script
├── scripts/
│ ├── run-mcp-server.sh # Runs the Massdriver MCP server via Docker
│ ├── massdriver-safety-check.sh # Deterministic PreToolUse guard (CLI + MCP)
│ └── test-safety-check.sh # Test suite for the safety guard
├── agents/
│ ├── architect.md # Citizen-developer project design (experimental)
│ ├── bundle-dev.md # Full development workflow
│ ├── resource-import.md # Import existing cloud resources
│ └── upgrade-tester.md # Day 2 upgrade testing
├── commands/
│ ├── architect.md # /massdriver:architect
│ ├── develop.md # /massdriver:develop
│ ├── import.md # /massdriver:import
│ ├── test-upgrade.md # /massdriver:test-upgrade
│ └── gen.md # /massdriver:gen
├── hooks/
│ └── hooks.json # Safety guardrails (CLI + MCP tool calls)
├── templates/
│ └── massdriver.local.md # Settings template
└── skills/
└── massdriver/
├── SKILL.md # Core knowledge (mental model + workflows)
├── PATTERNS.md # Bundle and resource type examples
├── snippets/ # Copy-paste templates
└── references/
├── graphql.md # GraphQL multi-entity queries
├── alarms.md # AWS/GCP/Azure monitoring
├── compliance.md # Checkov remediation
└── import.md # Importing existing cloud resources
The plugin includes a deterministic safety hook (scripts/massdriver-safety-check.sh, no LLM in the loop) covering both the CLI and the MCP tools, which hard blocks:
mass bundle publishwithout the--development(-d) flag- Applying to, tearing down or deleting from a production environment, via CLI or MCP:
create_deploymentPROVISION/DECOMMISSION,mass instance deploy/destroy, environment deploy / decommission / delete,orphan_instance, and deleting production projects or instance resources. Plans are exempt —PLANdeployments andmass instance deploy --planare dry-runs and allowed on any environment, including production. approve_deployment— always, regardless of target. Approving proposed deployments (including rollbacks) is a human authorization step; agents can propose, humans approve in the UI.
Configuration changes against production — update_instance, instance secrets, remote references, environment defaults, update_environment, resource grants, copy_instance into production, and propose_deployment — always ask for your approval, even in auto mode. They exist for importing into a production instance that isn't deployed yet; agents never change a deployed production instance. mass config get --show-secrets also always asks, since it reads your API key.
Read-only MCP tools (get_*, list_*, compare_*, evaluate_*, explain_*) are auto-approved — no permission prompt, on any environment. export_resource still prompts since it returns unmasked secrets. Non-applying tools (plan_deployment, rollback_deployment, reject_deployment, abort_deployment) are allowed since they cannot change infrastructure without a human approval.
The production pattern is substring-matched against the environment segment of slugs only — a component named prodcache in a test environment is not blocked, while an environment named preprod is. Anything the hook has no opinion on falls through to Claude Code's normal permission prompt. The policy is tested: scripts/test-safety-check.sh.
Create .claude/massdriver.local.md in your project:
---
mass_profile: default
production_pattern: (prod|production)
organization_id: ""
default_test_project: ""
---| Setting | Description |
|---|---|
mass_profile |
Profile from ~/.config/massdriver/config.yaml. Steers the mass CLI only — the MCP server's profile is fixed when Claude Code launches (see MCP server setup). Set both to the same profile, or the CLI and the control plane will target different organizations |
production_pattern |
Regex to identify production environments (protected by hooks on both CLI and MCP calls) |
organization_id |
Default org ID (optional, used when running raw GraphQL queries; the MCP server gets its org from its own env/profile) |
default_test_project |
Where to create test environments (optional) |
See massdriver/templates/massdriver.local.md for full documentation.
/massdriver:develop PostgreSQL database bundle.
Presets: Development (t3.small, 20GB), Staging (t3.medium, 50GB), Production (r6g.large, 100GB, Multi-AZ).
PITR should be configurable, defaulting to enabled.
SSL enforcement is mandatory.
Needs a network connection and AWS credentials.
Produces a postgres resource (artifact field) with connection info.
/massdriver:develop S3 bucket for static asset storage.
Developers choose versioning (on/off) and lifecycle policy (30/90/365 days).
Encryption at rest is non-negotiable.
Public access blocked by default but configurable.
Needs AWS credentials, produces an S3 bucket resource.
/massdriver:test-upgrade api-prod-database 1.3.0
The agent will ask about your production naming convention, what to copy from prod (secrets, remote refs, env defaults), and whether to mirror or low-scale dependency components.
Test plugin changes straight from a working tree — no publish, no reinstall, nothing lands in main:
# 1. Work on a branch so main stays clean
git checkout -b my-change
# 2. Disable the marketplace-installed copy so it can't shadow your local one
claude plugin disable massdriver
# 3. Launch a session that loads the plugin from disk (this session only)
claude --plugin-dir /path/to/claude-plugins/massdriverThe MCP server registers from the local plugin too (Docker still required — see Installation).
Smoke test inside that session:
/mcp— confirm themassdriverserver is listed with its tools- Run a command (e.g.
/massdriver:develop ...) and confirm it routes to the right agent /agents— confirm the plugin's agents are registered- Try
mass bundle publish(no-d) — the safety hook should block it (scripts/test-safety-check.shruns the full policy suite)
Iterate: --plugin-dir reads the live directory, so edit files → restart the session → retest. No republish cycle.
Validate manifests anytime:
claude plugin validate ./massdriver # plugin.json
claude plugin validate . # marketplace.jsonWhen you're done: claude plugin enable massdriver to restore the installed copy. To ship: PR the branch into main, bump version in massdriver/.claude-plugin/plugin.json, merge; installed copies pick it up with claude plugin update massdriver (restart required).
- Docker (runs the Massdriver MCP server — see Installation)
- Massdriver CLI (
mass) — for bundle/resource-type publishing and local builds - OpenTofu or Terraform
- A Massdriver account, with either an API key exported (
MASSDRIVER_API_KEY+MASSDRIVER_ORGANIZATION_ID) or a profile in~/.config/massdriver/config.yaml
- Massdriver Documentation
- Bundle Development Guide
- Bootstrap Catalog (sample bundles + resource types)
Apache 2.0 - See LICENSE