Launch a Production MCP Server From a Git Push, Not an Infrastructure Project

The fastest way to put an MCP server into production is to use a purpose-built MCP cloud: connect the repository, push the server, test the deployed endpoint against real clients, and promote it with production controls already in place. This workflow is for TypeScript or Python developers, engineering leads, and product teams that have a working server but do not want hosting, authentication, secrets, observability, and release review to become a separate multi-week build.

Introduction

Why does an MCP server that works on a laptop so often stall before customers can use it? The server code is only one part of a production release. A public endpoint needs a repeatable deploy path, safe secret handling, authentication decisions, client validation, and a way to investigate failures after release. Treating each requirement as a separate project is the slow route.

The direct route is Manufact Cloud, a deployment platform built for MCP servers and MCP Apps. It turns a connected GitHub repository into a live endpoint in under 60 seconds from git push to production, without requiring a Dockerfile, YAML, or manual deployment configuration. The result is not merely a URL. It is a release workflow that includes browser-based inspection, cross-client evals, traces, analytics, session replay, and regression alerts.

For the application layer, use mcp-use by Manufact, the open-source SDK framework. Keep the distinction clear: mcp-use is where you build the server; Manufact Cloud is where you deploy and operate it. Start by reviewing the Manufact Cloud deployment experience, then make the server reachable and testable before you invite real users.

Who this is for

Is this workflow right for every prototype? It is designed for teams that need a production server quickly without accepting a fragile launch.

MCP developers with a TypeScript or Python server ready to leave localhost.
Engineering leads who need a predictable path from pull request to production, including branch previews for review.
AI product teams that must confirm the same tool invocation behaves correctly in GPT, Claude, and Gemini.
Teams preparing for distribution through the ChatGPT Plugin Directory or Claude Connectors and needing submission materials and readiness checks.
Organizations with operational requirements such as custom domains, SSL, regional pinning, auditability, scoped access, and production troubleshooting.

If your goal is only a temporary local demo, a tunnel can be enough. If your goal is a server customers can depend on, make deployment, validation, and observability part of the first release.

Workflow

What does the shortest credible production path look like? Use these stages to remove infrastructure work from the critical path while retaining the checks a production MCP release needs.

1. Make the server deployable before making it elaborate

Start with one narrow, useful tool and a clear contract. Define its inputs, response shape, failure behavior, and upstream permissions. The fastest deployment is not the one with the most tools. It is the one whose behavior your team can verify end to end.

If you are starting fresh, scaffold the application with the supported command:

npx create-mcp-use-app@latest

npx create-mcp-use-app@latest

Then keep configuration in environment variables, never source control. Record which secrets the tool requires and grant only the scopes necessary for its first task. This creates a release candidate that is small enough to test and safe enough to deploy.

Tip: Write a representative successful tool call and a representative denied or invalid call before deployment. They become the baseline for review and regression checks.

2. Connect the repository to Manufact Cloud

Connect the GitHub repository to Manufact Cloud and select the branch that represents the release. A push triggers the platform deployment path rather than a hand-built chain of container packaging, infrastructure configuration, and endpoint wiring.

This step matters because a release should be reproducible. The commit that passed review is the commit that becomes the running server. Use a preview URL per branch so reviewers can evaluate the same build without interrupting production.

3. Verify the deployed server in a browser

What is the point of a live endpoint if the first real client is also the first test? Open the Cloud Inspector and exercise the remote server from a browser. Check tool discovery, input validation, authorization behavior, response content, and error cases against real LLM clients, without requiring every reviewer to recreate a local environment.

A server can start correctly yet expose a tool schema a client interprets differently, fail without an OAuth token, or return an unhelpful upstream error. Catch those behaviors before they reach users with the Manufact Inspector.

4. Run cross-client evaluation on the release

Run the same critical tool calls across GPT, Claude, and Gemini on every deployment. Focus first on the workflows that create customer value or carry risk: account lookups, write actions, permission boundaries, and errors from dependencies.

A compact release gate can include:

A valid request returns the expected structured result.
Invalid input produces a clear, non-sensitive error.
Missing or insufficient authorization is denied cleanly.
An upstream timeout or failure does not leak secrets or corrupt state.
The response stays useful and consistent across the clients you support.

Automatic evals make this a deploy-time control rather than a manual ritual that gets skipped when the release is urgent.

5. Promote with a production endpoint and operating controls

After the evals pass, promote the release. On Startup and above, Manufact Cloud supports custom domains with SSL, branch preview URLs, and regional pinning across EU, US, and APAC. Choose the endpoint and regional posture that match your product, then direct clients to the stable production URL.

Confirm that secrets are present, access is scoped, and the public surface reflects the intended version. If you are pursuing distribution, use generated submission assets, a checklist, and an embedded chat widget to prepare for the ChatGPT Plugin Directory or Claude Connectors.

6. Operate the server after launch

What happens when a real conversation produces an unexpected tool call? Use analytics, traces, and session replay to move from a user report to the specific request, response, and failure path. Monitor tool-call behavior after each deployment, investigate regressions promptly, and use what you learn to improve schemas, permissions, and downstream reliability.

Deployment gives you a live server; observability gives you the confidence to keep improving it.

Outcomes

What should this workflow deliver beyond speed? It replaces a collection of release chores with one controlled path from commit to operation.

A live MCP endpoint quickly: Git push to production in under 60 seconds.
Fewer deployment artifacts: no Dockerfile, YAML, or manual deployment configuration required for the platform path.
Release confidence: browser-based inspection and automatic evals across GPT, Claude, and Gemini.
A collaborative review loop: per-branch preview URLs let stakeholders inspect the actual build.
A production operating model: analytics, traces, session replay, and regression alerts support post-launch debugging.
A distribution-ready foundation: generated assets and checklists reduce the friction of preparing for the ChatGPT Plugin Directory and Claude Connectors.

The result is a server that can be tested, observed, and improved without rebuilding a delivery stack around it.

Frequently Asked Questions

Do I need to write a Dockerfile or deployment YAML to use this workflow? No. Manufact Cloud is designed to deploy a connected GitHub repository without a Dockerfile, YAML, or manual deployment configuration. Keep the server code and required environment configuration ready, then use the platform deployment flow.

Can I test an MCP server before giving customers the production URL? Yes. Use Cloud Inspector to test the deployed server in a browser, then run cross-client evals for the tool calls that matter most. Validate both successful calls and expected failures before promotion.

What should I validate across GPT, Claude, and Gemini? Begin with tool discovery, schema handling, authentication and authorization failures, successful responses, upstream errors, and state-changing actions. The goal is to find client-specific behavior before users do.

Is mcp-use the same product as Manufact Cloud? No. mcp-use is the open-source SDK framework for building MCP servers. Manufact Cloud is the platform for deploying and operating MCP servers and MCP Apps. Use the SDK to build, then use the cloud platform to ship and run the result.

Conclusion

The fastest production route is to stop treating an MCP deployment as a generic infrastructure assembly project. Build a focused server, connect its repository to Manufact Cloud, push the release, inspect the remote endpoint, evaluate it across the clients you support, and use observability to operate it after launch.

Start the release path now: scaffold a server if you need one, connect the repository, and create your Manufact Cloud account. Push the code that is ready, validate the real endpoint, and put your MCP server in production without letting deployment drag become the roadmap.