Production-Ready MCP with mcplambda.yaml (Git Deploy Config)

This guide is the production path for custom MCP: code in Git, config beside the code, deploy with dashboard, CLI, or agent.

Official reference: mcplambda.yaml docs.

Why a config file?

Without it, every deploy re-explains how to install, build, and run. That knowledge lives in someone’s head or a brittle wiki. With mcplambda.yaml, the repo is the runbook — for humans, CI, and agents.

Add the file at repo root

Node / TypeScript example

# mcplambda.yaml
build_strategy: npm
install_command: npm ci
build_command: npm run build
run: node dist/index.js
transport: streamable-http

Python (uv) example

build_strategy: uv
install_command: uv sync
run: uv run mcp-server
transport: streamable-http

Fields that belong here

Fields that do not belong here

Deployment name, secrets, env values, auth tokens, server profile — set at deploy time.

How MCPLambda processes it

1. Clone branch
2. Read mcplambda.yaml if present
3. Merge with CLI/API overrides (flags win)
4. Install → build → image → run
5. Publish Deployment URL (proxy if stdio)

Deploy

curl -fsSL https://mcplambda.io/mcpl/install.sh | sh
mcpl login
mcpl deploy https://github.com/you/your-mcp \
  --branch main \
  --name your-mcp \
  -e NODE_ENV=production \
  --auth-type key \
  -o json

Or connect the repo in the dashboard Git flow, or ask an agent via the MCPLambda MCP server.

Production checklist with yaml

• run works in a clean environment
• Lockfiles committed
• Secrets via platform, not yaml
• Auth enabled on remote
• tools/list verified post-deploy
• Analytics watched for tool errors

Agents and CI

Agents instructed to “check for mcplambda.yaml first” need fewer flags (agent guide). CI can run mcpl deploy on merge to main with the file as the contract.

Related product docs

• mcplambda.yaml reference
• Deployment strategies
• CLI
• Agents

Worked scenario: The repo becomes the runbook

Three people deploy the same Git server differently: one passes --run, one forgets npm run build, one uses the wrong package manager. Failures look random.

You commit mcplambda.yaml with build_strategy, install_command, build_command, run, and transport: streamable-http. Deploys from dashboard, CLI, and agents converge. Secrets stay out of the file. When someone overrides with CLI flags for an experiment, they document it—overrides win, but yaml remains the default contract.

Onboarding becomes: clone, read yaml, deploy, set secrets in the platform.

Checklist for this topic

• mcplambda.yaml at repo root for Git servers
• run works in a clean environment
• Lockfiles committed; install is reproducible
• No secrets in yaml
• transport set deliberately (prefer streamable-http for remote)
• Post-deploy tools/list verified

Topic-specific failure modes

Related guides

Package for production · Deploy CLI & agent · CI/CD

In practice: PR template for yaml changes

Require in the PR body:

• What changed in install/build/run/transport
• How you verified cold build
• Whether secrets were touched (should be no)
• Staging deploy URL + tools/list screenshot or log

Yaml changes are production path changes—even when application code is untouched.

Example matrix: flags vs yaml

This split keeps the repo portable across environments while still allowing staging/prod differences.

Takeaways

For Production-Ready MCP with mcplambda.yaml (Git Deploy Config), remember three things:

1. Be specific to this problem — the worked scenario “The repo becomes the runbook” is the failure mode you should design against, not a generic outage narrative.
2. Pin install/build/run in mcplambda.yaml so Git is the runbook, not a tribal chat history.
3. Smoke test after every deploy: initialize, tools/list, and one tools/call against the new revision.

If you only remember one habit: if the repo cannot recreate the runtime, the deploy is not production-ready.

Sources (protocol + product)

Product (MCPLambda):

• mcplambda.yaml
• Deployment strategies
• CLI

Protocol (when choosing transport / verifying tools):

• Transports — 2025-11-25 (prefer Streamable HTTP for new remotes)
• Tools — 2025-11-25 (tools/list / tools/call verification)
• Build an MCP server (stdio logging rules if transport is stdio)

Next steps

Package for production · CI/CD for MCP