Full disclosure up front: I run one of the four platforms in this test (redu.cloud), so take my framing with that in mind. I recorded every run raw and published every session transcript, so you can check the work instead of trusting me on it.
I wanted an honest answer to a question I actually care about: how well can an AI agent operate real cloud infrastructure today? Not a to-do app on a serverless host, real stateful infrastructure. So I gave the same job to the same agent on four clouds and watched what each one let it do.
The task
One real, stateful, privacy-first deployment. The same outcomes on every platform:
- self-host a private GitLab
- import a private fork of Supabase into it
- deploy the full self-hosted Supabase stack from that fork
- modify the running product (add a Backups view to Supabase Studio) and redeploy it
- put the app's data on storage that can be backed up independently of the compute
- take a real provider-level backup of just the data, then restore it, and verify
- drive that backup from inside the app through a credential scoped to backups only
- add a device VPN into the private network
The rule underneath all of it: nothing on third-party services. A private git host, a private database, everything on one network I control. It's a fair stress test because it needs real primitives, not just a place to run a container.
The method
Held constant across all four: the agent (Claude Code), the model (Claude Opus), the exact prompts, in the same order. Variable: the platform and whatever its tooling and primitives make available. Where a platform reached an outcome by a different mechanism, I counted it as a pass on its own terms.
Every run was screen-recorded raw, only dead time cut, every mistake left in. This is n = 1: a reproducible demonstration of what the agent did, not a statistical study. To repeat it, connect each platform's agent or MCP and issue the same prompts.
redu.cloud (the reference run)
Completed, with everything on one private network the whole way. It wasn't clean: the first backup attempt failed, and the agent rebuilt it live onto durable storage. That's in the video and I left it in. This is the run the others are measured against.
AWS
Completed. AWS has the primitives for all of it, and with a root key its own agent tooling can drive them. Two things stood out. It was slower than the reference run: 45% longer and 29% more tokens. And it provisioned paid resources three times without asking me to confirm: a second EC2 instance, a larger build instance, and the VPN node all came up billable with no cost prompt. It asked about scope; it never asked about spend.
Vercel
Couldn't do it, and that's fair. Vercel is a serverless and frontend platform, built for static sites and short-lived functions. A self-hosted, stateful stack with its own database and a VPN isn't what it's for. Worth including because it marks the edge: this class of platform can't host this class of work, no matter how good the agent is.
Railway
Completed too, and it's the one I'd credit most on developer experience. The interface is the nicest of the four, and it asked before spending, repeatedly, including a cost prompt. Two honest marks against it on this task: it took almost five hours (the reference run took about two), because a one-container-per-service model fought a stack that wasn't designed for it. And it couldn't keep everything private: to finish, the agent had to push custom images to Docker Hub and stand the VPN up on Tailscale, both outside the private network. That's a platform limit, not a failure, and it's the real difference on a privacy-first job.
The numbers
Agent-active time is measured from first action to verified end state, excluding human latency and usage-cap waits, and including all platform time (boot, build, self-heal). Tokens are reported alongside because they're independent of typing speed.
| Metric | redu.cloud | AWS | Railway |
|---|---|---|---|
| Agent-active time | ~110 min | ~160 min (+45%) | ~283 min (+157%) |
| Output tokens | ~1.11M | ~1.43M (+29%) | ~2.07M (+86%) |
| Model | Claude Opus | Claude Opus | Claude Opus |
Same model every time, so the gaps aren't the agent being smarter on one platform. They're how hard the platform made the work. Railway needed the most of both because the workload fought its service model at every step. (Vercel is out of this table because it didn't complete the task.)
On cost, at a 24/7 run-rate:
| redu.cloud | AWS | Railway | |
|---|---|---|---|
| Run-rate | ~£84/mo (~$106) | ~$146/mo | idle ~$90 to $100, load $150 to $230 |
| Billing | flat, provisioned | flat, provisioned | per-minute of usage |
A fair reading: redu.cloud is flat and cheaper than AWS. Railway is cheaper than everyone when it sits idle, and the most expensive under sustained load. For a stack that's actually running, redu.cloud was more affordable in most situations, with no surprise bill. The instances aren't spec-matched either (redu.cloud's box was 4 vCPU / 80 GB, AWS's was 2 vCPU / 30 GB, a gap that favors redu.cloud), so I'm stating it rather than hiding it.
What I take from this
Agents can operate real cloud infrastructure now. But the platform underneath decides how far they get, and the failure modes differ in kind:
- a serverless platform hits a wall on stateful work,
- a hyperscaler will let an agent spend your money without checking,
- a container PaaS can run it but can't always keep it private.
Same agent every time, so none of that is the model. It's what the infrastructure lets the agent do.
Check it yourself
The full write-up, all four raw videos, and the exact session transcripts (credentials removed) are here:
https://redu.cloud/compare/the-proof
We're a small team, and our own product is one of the four named subjects here, which is exactly why I published every raw session. If I got something wrong, it's all in the transcripts.
Top comments (0)