Building an Enterprise MCP Platform - Vol. II: Zero-Friction Delivery
How to automate the lifecycle of your MCP servers and establish a seamless pipeline from a developer's repository straight to production.
We happy?… Vincent!… We happy?
We’re happy.
— Jules and Vincent, Pulp Fiction
Your users don’t need to know how their MCP Server reaches Production, but they need to know that there is a way that satisfies their needs.
In the first issue of this series, dedicated to enabling MCP Servers in the real world, you learnt how to choose the right way to deploy MCP Servers.
Before we dive into today’s pipeline automation, let’s ground ourselves with the core lessons from Vol. I: Keep Deployment Simple:
Centralize to maintain: Cloud deployment is the only way to guarantee instant security patches and seamless updates for non-technical users.
Choose compute wisely: We mapped out the decision tree, using Fargate for stateful, low-latency LLM interactions, and Lambda for sporadic, stateless utility tools.
Avoid over-engineering: We prioritized starting simple based on current sporadic usage rather than future hypothetical scale.
In today’s email, we transition from where the infrastructure sits to how we build a zero-friction path from a developer's repository to that infrastructure.
If you are a Software Engineer trying to understand the main challenges at the time of deploying MCP Servers in Production, this email is for you. Know someone who might be interested in this topic? Forward them the email 👇🏻
Let’s continue with the next topic: Delivery
You need to define the workflow for developers to deploy their MCP servers from code to production.
If you read this newsletter for a while, you know that I’m a big fan of Kubernetes (when it makes sense), and the solution I give you to achieve a Cloud Native delivery of MCP Servers leverages Crossplane. If you want to know more about Crossplane, here I give an explanation about what Crossplane is and its main use cases.
Fundamentally, you have to build a pipeline to tackle Continuous Integration and Continuous Delivery (as usual).
1. CI - From code to Docker image
Yes, Docker is the magic here.
👉🏼 You have to implement a CI pipeline to be used by the developers (a.k.a. the owners of the MCP Servers to be deployed).
This pipeline will build the code and create and push a Docker image for that build.
The outcome of the CI stage is the Docker image uploaded into a Docker Image Registry, like AWS ECR.
📖 Why a Docker image?
Consistency. It offers consistency of the execution environment. This is, in my opinion, the number one advantage.
With a ZIP file, you’re completely dependent on the runtime provided by AWS (or any other cloud provider).
With a Docker image: the operating system, system libraries OpenSSL, glibc, native binaries, Python/Java/Node versions, installed tools, travel with your application.
2. CD - Deliver via Crossplane
You have to implement a CD pipeline to be used by the developers to deliver their stuff; in this case, their MCP Servers, packaged as Docker images, into AWS Lambdas.
In this pipeline, developers will be able to ship a Crossplane Composition to deploy their MCP Servers to the cloud, in our case, via an AWS Lambda. The Composition must represent their use case (deploy an MCP Server encapsulated into a Docker image) and just that. Let me clarify what I mean by just that.
The developers must have nothing to do with IAM roles, authentication, Lambdas, or any other platform business. The Crossplane Composition will deploy all the corresponding pieces that the Platform Team, Security Team, and others agreed (on behalf of developers) to deploy MCP Servers in the cloud.
📖 Why Crossplane?
Abstraction. It abstracts away the underlying complexity, allowing developers to focus on delivering software through a simple interface (even if it is YAML) that is centered on use cases, without having to bear the cognitive load of deploying to the cloud.
⚠️ Important note: If you are not in Kubernetes, just discard Crossplane (not worth having Kubernetes just for Crossplane) and implement the same abstraction using another abstraction layer, such as GitHub Workflows, Terraform, CDK Framework, or something homemade by your organization.
Let’s close for today with some takeaways.
✨ Takeaways
That’s it; does it look simple? Of course, it is not; You and I know that the heavy lifting comes in:
The implementation of the CI pipeline should be generic enough to support different languages and frameworks, but not so generic that it becomes difficult to use. If you want to dig more into this, I wrote about how the MAKEFILE approach can help you strike this balance.
The implementation of the Crossplane Composition should focus on the use case and expose an interface (YAML properties) that addresses it. Reaching agreement among developers on that interface will be a challenge, I can tell you that upfront.
At the end of the day, you have to keep in mind the following:
Create reusable pipelines for developers.
Abstract the complexity of the platform, so developers can focus on their business and deliver, and you have the flexibility to change the platform transparently in case it is needed (today Lambdas, maybe tomorrow Fargate).
Coming up in the next issue...
Now that we have covered where our servers live (Deployment) and how to get them there automatically (Delivery), we are ready to face the final boss of production readiness: Security. In our next and final edition, we will tackle how authentication, authorization, and secure governance work for your internal AI protocol servers.
Best,
Marcos.