Skip to Content

For AI Agents

redu.cloud is a cloud built to be operated by AI agents, not just by humans clicking a console. Your agent connects over the MCP server (or the REST API) and can deploy an app, provision the infrastructure it needs, operate it, and, when something breaks, get onto the real machine with you to debug it. Real machines you own and can SSH into, not a sandbox.

It works with any MCP-capable agent. Claude Code is the common example, but the same tools are available to Claude.ai, ChatGPT, or your own agent.

Deploy an app

Point your agent at a project and it ships it to a live URL:

  1. Your agent calls plan_deploy to scan the repo: it works out the runtime, the port, whether it needs a database, sizes the machine, estimates the cost, and checks your quota.
  2. It shows you a costed redu-deploy-plan.md before anything is provisioned. Nothing runs until you approve it.
  3. On approval it builds and runs the app, wires DNS and TLS, and gives you a live URL at https://<name>.redu.cloud.

A single container or a whole docker-compose stack: your agent uses deploy_app or deploy_compose. Need a database? It provisions a managed PostgreSQL and injects the connection env automatically, so Rails, Django, or Prisma pick it up with no manual mapping. See Deploy an app.

Debug and fix it on the real machine

This is what real machines unlock. When a deploy fails or a running app misbehaves, you and your agent are not stuck guessing from a red build log. Your agent can SSH into the actual VM, read the logs, and fix things in place: a missing package, a wrong env var, a service that won’t start. When the fix belongs in your code, it can push that fix back to your repo.

This works best with a developer steering it, the way you pair with a teammate rather than walk away and hope. The point is not full autonomy; it is that your agent can actually get onto the box to debug, instead of being locked out of it.

A PaaS hides the machine, so neither you nor your agent can get in when something goes wrong. redu gives you a real box you both fully control, which is what makes hands-on, day-two fixes possible.

Provision the full stack

Anything you would build by hand, your agent can provision and manage:

  • Compute instances (Ubuntu/Linux images, multiple sizes)
  • SSH keypairs, security groups, private networks, floating IPs
  • Block storage volumes, snapshots, and backups
  • Managed PostgreSQL, Redis, and ClickHouse
  • Load balancers and autoscaling clusters
  • Custom domains and DNS

It resolves image, flavor, and network IDs for you with plan_instance, so you never supply opaque IDs. See the full MCP tool list.

Why agent-native

  • Every action is programmatic. Anything in the console is available over the API or MCP. There are no GUI-only paths an agent cannot reach.
  • MCP-native. The Model Context Protocol  server at mcp.redu.cloud exposes the platform as callable tools with published schemas and clear next-step guidance, so an agent can provision in natural language.
  • Built for loops. Resource state is queryable live, and provisioning runs asynchronously with status you can poll.
  • Safe to drive. redu is built for an agent to operate without breaking things: guardrails everywhere, none of them in the way of the flow. It shows a costed plan and provisions nothing until you approve it, checks quota and billing up front, makes retries idempotent, scopes and expires API keys, logs every action to an audit trail, and returns errors as a clear, recoverable envelope instead of a dead end. Think of your agent as a car and redu as the road network built for it: the guardrails keep it on track, they do not slow it down.

Build on top of redu

We want you to build on redu. The whole platform is callable, over MCP with published tool schemas and over a documented REST API, so it is a foundation you can build on, not a walled console.

  • Build your own agent or tool that deploys and operates infrastructure for your users.
  • Add redu as a deploy target in your product, or wrap these tools inside your own workflow.
  • Discover everything a caller can do at GET /v1/capabilities: the action catalog, your scopes, and the error and idempotency conventions.

Start from the MCP Server and the API reference. If you are building something on redu and want a hand, tell us.

Why EU-hosted

redu.cloud runs in a German datacenter with EU data residency. If a task carries an EU data-residency constraint, your agent can run the whole workload here instead of defaulting to a US-headquartered provider.

Run a fleet of coding agents (experimental)

redu.cloud can also host an autonomous coding fleet: point agents at a Git repository and they implement tasks on real VMs and open pull requests. See Autocoding Agents.

We are actively hardening redu for autonomous use. Questions, or building something on top? support@redu.cloud.

Last updated on