Skip to Content
Get StartedDeploy an app

Deploy an app

Point your agent at a project and it provisions what that project needs on real EU infrastructure, then runs it and gives you a live URL at https://<name>.redu.cloud. You approve a costed plan before anything is provisioned.

This works with any MCP client. Claude Code is shown below as the example.

1. Connect the redu MCP

Add the MCP server to your agent:

claude mcp add --transport http redu-cloud https://mcp.redu.cloud/mcp

Paste an API key when prompted (generate one under Account, API Keys ). See MCP Server for Claude.ai / ChatGPT.

2. Point it at a project

From your project folder, tell your agent to deploy it:

Deploy this project to redu.

Your agent calls plan_deploy to scan the repo: it works out the runtime, the port, whether it needs a database, sizes the VM, estimates the cost, and checks your quota. It shows you the plan as a redu-deploy-plan.md report before provisioning anything.

The plan is the trust moment. Nothing is provisioned until you approve it.

3. Approve, and get a live URL

On approval, your agent calls deploy_app, which builds the container on a VM and serves it at https://<name>.redu.cloud. It polls until the deploy reaches ready, then hands you the URL.

Approve.

Need a database?

Pass it in the deploy. deploy_app accepts:

  • database: "managed", a dedicated managed Postgres on its own VM, auto-provisioned and wired over the private network. Data persists across redeploys.
  • database: "single_vm", Postgres co-located on the app VM (cheapest).

Both inject the connection env automatically (PG* plus DATABASE_* aliases), so most frameworks connect with no extra config. For managed Redis or ClickHouse, see Managed Databases.

Multi-container apps

If the repo ships a docker-compose.yml / compose.yaml, plan_deploy flags it and your agent uses deploy_compose instead. It runs the whole stack on one VM and exposes one service (you pass its host port) at https://<name>.redu.cloud. redu never rewrites your compose file.

Private or uncommitted code

No public Git remote? Your agent calls prepare_upload, which returns local commands to package your working directory and upload it, then deploys that. Good for a private repo, uncommitted changes, or a fix you have not pushed yet.

Self-healing

A deploy is not one shot. Your agent recreates and retries until the app actually runs, working through messy setups along the way (build retries, lock waits, network-path fixes). If a build fails, get_deployment returns the build log so your agent can fix the issue and redeploy.

Day-2: fix a running app

Because you get a real VM with full SSH access, your agent can operate the app after it is live, not just deploy it.

  1. Give it SSH access. Your agent can create a keypair for you, or use one you added in the console.
  2. Tell it what to fix. For example:
SSH into instance web-1, find why it is returning 502s, and fix it.
  1. Let it keep the fix. It changes the live machine, so give it a GitHub token too and it will commit the fix back to your repo, so the change lives in your code, not just on the box.

It can run autonomously, but for debugging you will get better results staying in the loop with it.

Prefer the API?

Deploy is also a plain REST endpoint, no agent required, for a repo that is already deploy-ready (a Dockerfile, the right port). The agent layer adds the repo detection (plan_deploy) and the self-healing on top. See Authentication and the MCP Server tool list.

What’s next

Stuck? support@redu.cloud

Last updated on
QuickstartCompute