How to Deploy with Claude Code (to a real cloud)

You have used Claude Code to write an app. It scaffolded the project, wrote the handlers, fixed its own bugs, and the thing runs on your laptop. Then you hit the wall every coding agent hits: it can write the code, but it cannot ship it. Deploying is still your job, in a different terminal, by hand.

That wall is not a Claude Code limitation. It is a missing connection. An agent can only act on the systems it has tools for, and by default it has no tools for your cloud. Give it those tools and “deploy with Claude Code” stops being a figure of speech. The agent provisions the database, pushes the app, and hands you a live URL, without leaving the conversation.

The gap between writing code and shipping it

A coding agent is good at the part that happens inside your repository. It reads files, edits them, runs your tests, and reasons about what broke. All of that lives on your machine, which is exactly where the agent already has reach.

Shipping is different. To deploy an app you have to talk to a cloud: create a service, provision a database, push an image, wire up an environment variable, read back a status. Those are actions on a system outside the repository, and an agent cannot take an action it has no tool for. So it writes a perfect deploy script and then asks you to run it. Close, but you are still the one shipping.

The fix is to hand the agent real tools for your cloud. That is what the Model Context Protocol is for, and it is what turns “generate a deploy command” into “deploy an app with an AI agent.”

Connect Claude Code to a hosted MCP server

MCP is an open standard for giving an agent tools it can call. An MCP server exposes a set of actions, and an MCP client, which is what Claude Code is, calls them. Point Claude Code at a server and its tools become things the agent can do, not just describe.

Scalix runs a hosted MCP server for exactly this. It sits at api.scalix.world/v1/mcp and exposes the platform as 50 tools: run queries and migrations, branch a database, deploy a service, check status, and so on. One API key authorizes all of it. Because the server is hosted and always on, you run and maintain nothing to use it. (If you would rather host your own MCP server instead, we wrote a full guide to that.)

Connecting Claude Code to an MCP server takes one command. Grab a Scalix API key from the console, then add the server over HTTP:

claude mcp add --transport http scalix https://api.scalix.world/v1/mcp \
  --header "Authorization: Bearer $SCALIX_API_KEY"

That registers the Scalix server for the current project. Add --scope project to share the connection with your team through a checked-in .mcp.json, or --scope user to make it available in every project on your machine.

Confirm the agent can see it:

claude mcp list

Inside a session, /mcp shows the connection status and how many tools it picked up. Once it reports connected, Claude Code has a working set of cloud tools. There is nothing to install. Claude Code MCP setup is a URL and a key, and the tools show up in the session.

What the agent can do once it is connected

With the Scalix tools available, the agent’s reach extends past your repository and into your cloud. In plain language, you can now ask it to:

• Set up and work the database. The agent creates a Postgres instance through the platform API with the same key, reads back the connection string, and from there the MCP tools take over: run queries, inspect the schema, apply migrations, spin up a database branch to test something risky. The same agent that writes the code querying a database can now stand up and operate the database it queries.
• Deploy to Scalix Run. The agent builds or references a container image and creates a running service from it, then returns the URL.
• Read status. It can check whether a deploy succeeded and see whether a service is healthy, which means it can also react when something is wrong. For the full log stream, scalix-cloud logs is a CLI command like any other, and a coding agent can run those too.

The last one matters more than it looks. An agent that can only fire off actions is a fancy script. An agent that can also read back what happened can deploy, notice the deploy failed, fix the code, and redeploy on its own. That loop is the difference between generating a deploy command and actually shipping.

A deploy walkthrough

Here is the concrete version. You have an app in your repo, the Scalix MCP server connected, and you want it live. Ask the agent, in the session, to ship it:

Deploy this app to Scalix Run. It listens on port 8080. Provision a Postgres database, pass the connection string in as an environment variable, and give me the URL.

The agent works through the tools in order: it detects the runtime, provisions the database, deploys the service, wires the connection string into the environment, and reports back. Scalix Run deploys straight from source and recognizes Node, Python, Go, Rust, or a Dockerfile, so if the agent just wrote the code, there is no separate build step to babysit.

The deploy itself maps to the same run command you would type by hand. With a prebuilt image it looks like this (the registry namespaces images under your project id):

scalix-cloud run deploy --name my-app \
  --image api.scalix.world/<project-id>/my-app:v1 \
  --port 8080 \
  --min-instances 1 --max-instances 5

You did not run it. The agent did the equivalent through MCP, which is the whole point. When it finishes, the service is live at a stable URL:

https://my-app.run.scalix.world

From here the loop stays inside the conversation. Tell it the app is throwing a 500 and it can check the status, pull logs through the CLI, patch the code, and redeploy without you switching tools. You describe the outcome; the agent operates the cloud.

Wrapping up

Deploying with Claude Code is not a special mode or a new product. It is your agent, plus tools for a real cloud, connected over one open protocol. Write the code in the session you already use, then let the same agent provision the database and put the app online, and read back whether it worked.

If you want to try it, Scalix Run is the service the agent deploys to, and Scalix Coder is our own coding agent on the same platform if you would rather not bring your own. Point an agent at the MCP server, describe what you want live, and let it ship.