Deployments

Every Manufact-hosted server is backed by a deployment pipeline. A deployment goes through the steps Cloning → Analyzing → Building → Deploying → Health Checks → Complete, and you can follow each step live from the Deployments tab.

Automatic deployments

Pushing to your production branch triggers a deployment automatically, the production branch always deploys. You can tune what else triggers a deploy in Server settings:

• Watch paths (globs): only deploy when files under specific paths change (useful in monorepos).
• Branch allow list (globs): control which other branches create deployments.
• Wait for CI: hold the deploy until your GitHub checks pass.

Production and preview environments

• Production is the deployment of your configured production branch. It serves your main gateway URL.
• Preview environments are created per branch. Each gets its own MCP URL of the form https://<slug>--br-<branch>.run.mcp-use.com/mcp, so you can test changes against real clients before merging.

Use the environment selector in the server header to switch between production and preview branches, the URL chip, logs, and environment variables all follow the selected environment.

Manual deployments

From the Deployments tab you can:

• Trigger deployment: deploy a branch on demand.
• Redeploy: rebuild and ship the same source (after changing environment variables or settings). For a production-branch deployment that isn't currently active, this appears as Promote to production.
• Set as Active: switch traffic to a specific deployment.
• Start / Stop / Delete: manage stopped, failed, or old deployments.

Deployment history

The history table shows every deployment with its MCP URL, source branch and commit, duration, and creation time. Click a row to open the detail drawer with Build Logs (broken down by pipeline step) and Runtime Logs tabs.

Build configuration

The build is controlled by settings configured at creation time and editable later in Server settings:

• Framework preset: mcp-use, mcp-python, FastMCP, and others, or Dockerfile for full control.
• Root directory: where your server lives inside the repository.
• Build command / start command: override the preset defaults.

Troubleshooting failed deployments

Failed deployments surface on the org Dashboard under Needs Attention, and trigger an email if you have Failed deployment emails enabled in account settings (on by default). Open the deployment drawer to read build logs step by step, a failure at Health Checks means the deployed server didn't respond correctly, which usually points to a wrong start command or a missing environment variable.