Agent-native cloud.
Deploy and operate your applications through the agent you already use. Go from your project to a live deployment, then make changes and fix problems in the same conversation.
Your cloud, through your agent
Deploy your project, scale its infrastructure, and change its configuration without leaving the agent you already use.
Cloud operations, measured
124 published runs of deployment and live operations across redu, AWS, Google Cloud and Azure, using Umami and Claude Opus 5.
View the benchmark and reproduce it →Agent reliability and safety
Review the deployment plan and cost before approving it. If something breaks, your agent can read the logs and fix it in place, with you steering.
From first deploy to live fixes.
Connect your agent through the redu MCP and give it your project. It prepares a deployment plan with the cost. Review it, approve it, and your agent deploys the application to a live URL.
Once it is running, ask the same agent to change configuration, add capacity, or read the logs and fix a problem in place. It works inside your account and quota, and you see every step.
# 1. Add redu to your agent claude mcp add --transport http \ redu https://mcp.redu.cloud/mcp \ --client-id redu-mcp # 2. From your project folder, run: "Deploy this project to redu" # Review the plan and cost. # Approve it to deploy. # Once live, ask your agent to make # changes or investigate a problem.
Full cloud stack. By the hour.
Our own infrastructure, not a reseller. Real machines in a European datacenter, with EU data residency. Use the console, the API, or your agent. No commitment, no minimums. £200 free credits to start. Full pricing →
Open-source apps, ready for your agent.
Start from a working deployment recipe, review the plan and cost, then approve when you are ready.
Questions, answered.
How is redu different from a traditional cloud platform?
redu lets you deploy and operate your applications through the agent you already use. Give it your project, review the deployment plan and cost, and approve it to get a live URL.
That workflow continues after deployment. Ask your agent to change configuration, add capacity, or investigate a failure on the running infrastructure. You stay in control, and you can also use the console or API.
How is it different from a PaaS like Vercel, Railway, or Render?
A PaaS is a managed slot to run your app in: push code and it runs, nothing to operate. That convenience is the whole appeal, and you pay for it by giving up the machine, their runtime, their limits, their margin.
redu is the real cloud itself: the actual VMs, networks, and databases you would otherwise never touch. Normally that means operating it yourself, so your agent does that instead, and you keep the convenience while getting the control back.
It is like owning the car instead of taking the taxi, except your agent does the driving, so you still just say where to go.
Things you can do on redu that you cannot on a PaaS:
- Your infrastructure is not limited to preset tiers and a fixed network model. The machine, the network, the storage, all of it is yours to shape.
- If a custom deploy breaks, your agent can go into the infrastructure itself and fix it: the VM, the networking, the storage. A PaaS gives you at most a shell inside your app container, never the machine, network, or storage underneath.
- We recommend a path, but we do not enforce it.
- Instead of shaping everything you build to fit the platform, redu shapes itself to you, with your agent.
For example, redu does not offer managed Kubernetes today. But ask your agent and it can build one for you on redu, it has everything it needs. Try that on a PaaS and it will not work without heavy workarounds or hacks.
See it: the same deployment on redu.cloud, AWS, Vercel and Railway →
Why does real infrastructure matter?
It saves you from the two things that bite PaaS users: the bill and the ceiling. A PaaS charges a premium for the convenience, so past a small scale the same workload is often several times cheaper on real infrastructure.
You also get to run what a managed runtime will not: scale just the database on its own fast disk, put services on a private network, run a long job with no timeout or build cap.
There was always one catch: operating it used to need a team. Now your agent does that, so you get all of it without one.
Is it safe to let an agent run my infrastructure?
Yes. Your agent shows you a costed plan and does not provision until you approve, keys are scoped and expiring, retries are safe to repeat, and every action is logged.
Think of your agent as the driver and redu as the road built for it: guardrails everywhere, none of them slowing it down.
What happens when a deployment breaks?
It runs on a real machine, so your agent can SSH in, read the logs, fix it in place, and push the fix back to your repo.
It works best with you steering, the way you would pair with a developer. The point is it has the whole machine to work on, not a locked-down slice of someone else's runtime.
What does it cost, and do I need a card?
Pay as you go, by the hour, with no commitment. Start free on a limited trial, or add a card for £200 in credits and the full platform.
No card is needed to start. The trial has lower limits to keep abuse off real compute. Adding a card lifts them, gives you £200 in credits, and does not charge you by itself.