Status: all four runs (redu.cloud, AWS, Vercel, Railway) complete. Recordings and transcripts are attached in Materials.
Abstract.One real, stateful software deployment was run end to end on four cloud platforms (redu.cloud, AWS, Vercel, and Railway) using the same AI agent, the same model, and the same prompts. The task combined a self-hosted Git server, a self-hosted database platform built from a private fork, a live modification of the running product, an independent data backup and restore, a scoped-credential integration, and a device VPN. Each platform was allowed its own best path to each outcome. All four runs were screen-recorded raw, with only dead time cut and every mistake left in; the full agent transcripts, the complete record, are published with credentials removed. This document records the subjects, the aim, the method, the materials, and the measured results across all four completed runs.
The agent was asked to reach the same eight outcomes on each subject, from the same prompts:
One ground rule ran across all eight: the stack had to stay private. No code and no service could live on an external, third-party platform; everything had to run on the same private network, on infrastructure the operator controls, with the operator deciding how privacy is enforced. This is a first-class requirement of the task, and it is the criterion the four platforms most cleanly separated on.
Held constant across platforms: the AI agent (Claude Code), the model (Claude Opus), the prompts, and the eight target outcomes above. Variable: the platform and the path its tooling and primitives make available. Where a platform reaches an outcome by a different mechanism, that is recorded as a pass on its own terms, not as a failure.
Timing is reported as agent-active time: from the first action to the verified end state, excluding intervals of human response latency and provider usage-cap waits, and including all platform time (boot, build, self-heal). Output tokens generated by the agent are reported alongside, because they are independent of typing speed and idle time.
This is one run per platform (n = 1): a reproducible demonstration of what the agent did, not a statistical study over many trials. To repeat it, connect the platform's agent or MCP and issue the same prompts in the same order. Every prompt is preserved verbatim, as the USER turns in the transcripts linked under Materials. The workload is the public Supabase repository (github.com/supabase/supabase), deployed from a private fork.
Each subject is recorded as its own run. Timestamped chapter markers accompany each recording. The full agent transcripts are downloadable as plain text with all credentials removed.
| Metric | redu.cloud | AWS | Railway |
|---|---|---|---|
| Agent-active time (work only) | ~110 min | ~160 min (+45%) | ~283 min (+157%) |
| Output tokens generated | ~1.11M | ~1.43M (+29%) | ~2.07M (+86%) |
| Model | Claude Opus | Claude Opus | Claude Opus |
Active time excludes operator response latency and usage-cap waits (redu.cloud's raw span was much longer, it included a cap-out wait and slower typing while recording; Railway's session was continuous with no cap-out). Output tokens are independent of typing speed and idle time. Railway required the most of both because the workload fought its one-container-per-service model at every step. Percentages for AWS and Railway are relative to redu.cloud (the reference run).
| Outcome | redu.cloud | AWS | Vercel | Railway |
|---|---|---|---|---|
| Private Git host and private Supabase fork | pass | pass | platform limit | pass |
| Full self-hosted Supabase from that fork[1] | pass | pass | platform limit | equivalent |
| Live product change, pushed and redeployed | pass | pass | platform limit | pass |
| Data on storage recoverable independently of compute | pass | pass | platform limit | equivalent |
| Real backup of only the data, restore, verify[2] | pass | equivalent | platform limit | equivalent |
| Backup driven via a narrowly scoped credential | pass | pass | platform limit | equivalent |
| Device VPN into the private network | pass | pass | platform limit | equivalent |
| Agent-driven via the platform official MCP[3] | pass | pass | pass | equivalent |
| Ground rule: stayed private, nothing external[4] | pass | pass | platform limit | platform limit |
| Item | redu.cloud | AWS | Railway |
|---|---|---|---|
| Compute, Git host | m1.large · 4 vCPU / 8 GB / 80 GB · ≈ £35/mo (~$45) | t3.large · 2 vCPU / 8 GB · ≈ $61/mo | usage-based |
| Compute, database host | m1.large · ≈ £35/mo (~$45) | t3.large · ≈ $61/mo | usage-based |
| Block storage | 80 GB flavor disk included; 20 GB data volume billed separately | 2 × 30 GB gp3 · $4.80/mo | per-GB in usage |
| Public reachability | DNS-based, no per-instance public IPv4 | 2 × Elastic IP · $7.30/mo | subdomain, no per-instance IPv4 |
| VPN node | m1.small · ≈ £13/mo (~$16) | t3.micro + IP · ≈ $11/mo | Tailscale (free tier), external |
| Billing model | flat, provisioned | flat, provisioned | per-minute of actual usage |
| Total run-rate (24/7) | ≈ £84/mo (≈ $106) | ≈ $146/mo | idle ≈ $90-100, load $150-230 |
Each column is that platform's own published pricing, from the linked transcripts (redu.cloud's flavor table, AWS's itemized breakdown, Railway's per-minute rates). Currency: redu.cloud bills in GBP, USD shown at about 1.27 USD per GBP. The instances are not spec-matched: redu.cloud's m1.large is 4 vCPU / 80 GB, AWS's t3.large is 2 vCPU / 30 GB, a gap that favors redu.cloud, so it is stated rather than hidden. Public reachability differs by design: AWS charges per Elastic IP (a separate line item), while redu.cloud and Railway route by DNS / subdomain with no per-instance IPv4 charge. Railway bills per minute of actual usage, so it is cheaper than AWS at idle and the most expensive under sustained load, while redu.cloud and AWS bill flat for provisioned resources regardless of load; the Railway run itself cost about the $5 Hobby subscription because it ran for hours, not a month. One item runs AWS's way: its t3.micro VPN node was cheaper than redu.cloud's smallest node.
AWS completed the task. With an account root key, the agent deployed GitLab, deployed the full self-hosted Supabase from the private fork, built a custom Studio image, configured point-in-time backups, merged the fork change through a merge request, stood up a WireGuard VPN, and locked the Git host to it. The output is functionally the same as the reference run.
The cost of reaching it was higher, and it was never gated. Across the whole run the agent asked three times (at 12:56, 14:15 and 14:47 in the transcript), each about scope or design, never about cost, then created billable resources with no approval in between: a second EC2 at 13:43, a t3.2xlarge builder at 14:53, and the VPN instance at 15:38. Public IPv4 and block storage were billed as separate line items. The build used four infrastructure stacks, three instances, three custom images, and a temporary builder instance, plus identity and access configuration. The recovery path was a Postgres-specific backup tool writing to object storage (recorded as equivalent, not the same mechanism as a block-level volume backup).
And there is a wall before any of that, in AWS's own words. The agent toolkit refused to configure outside a single US region: its CLI states plainly, "AgentToolkit is only available in us-east-1," and the MCP would not connect until an undocumented dependency was installed. AWS's ordinary services have EU regions; its agent-native tooling is confined to us-east-1, so a European user who wants an agent operating their cloud is routed through the US at the door. This is onboarding rather than the task, and the precise claim is that the agent tooling is US-region-only, not that AWS lacks EU regions. But for an EU user of an agent-native cloud it is a first-order access fact, and it is AWS's own CLI saying it.
Vercel is a hosting platform for static sites and serverless functions. The agent inspected the repository and correctly identified that a Ruby monolith and a multi-container database platform have no persistent server to run on. Vercel can provision a managed database that runs on a separate managed cloud and wire its credentials into a Vercel-hosted frontend; that reaches a working application, but not the self-hosted stack on infrastructure under the operator's control. The stateful outcomes are recorded as platform limits, not failures. Its MCP connected without friction.
This boundary is Vercel's own documented design, not our characterization: Vercel documents its compute as stateless serverless and edge functions with a bounded maximum duration, intended for frontend and API workloads rather than persistent servers or self-hosted databases (Vercel Functions documentation, vercel.com/docs/functions). The same diagnosis is visible verbatim in the published Vercel session.
Railway is the fair fight Vercel is not: it runs long-lived containers and managed databases, it has the cleanest interface of the four, and over about six hours it completed the task, the full stack, the Backups feature merged, a VPN, GitLab locked down, and teardown. The question is not whether it could be done but how, and at what cost to the privacy rule and the agent flow.
It could not stay in-boundary. Railway cannot build from a private Git host, so the six custom images had to be pushed to Docker Hub; and WireGuard cannot run on Railway (no inbound UDP, no TUN device), so the VPN had to be Tailscale. Both are external third parties, so the run did not meet the privacy rule. In parallel, the agent could not do all of it: Railway's MCP cannot trigger a first deploy or a teardown, both need the dashboard, so an agent-driven flow was pulled to the UI.
A security default, stated fairly: self-hosted Studio has no auth, and Railway's one-container-per-service model split it out from behind the gateway, so it was exposed until it was caught and locked. This was the agent's mistake more than Railway's, and Railway could add guardrails. Cost is usage-based and clearly shown, cheaper than AWS at idle and the most expensive under sustained load. For a human working by hand, Railway's interface is the best of the four; redu.cloud's edge is the agent-driven workflow, not the console.
Across identical conditions, the task was completed by redu.cloud, by AWS, and by Railway, and bounded by platform on Vercel (a serverless, frontend-first platform cannot host a stateful self-hosted stack). The difference between the completed runs was not whether the outcome was reachable but the path to it: the number of separate resources and access decisions, whether the work stayed on infrastructure the operator controls, whether the agent could do it all without a dashboard, and whether cost was surfaced before it was incurred. On the reported efficiency measures (agent-active time and output tokens) the reference run was leaner on the same model and task.
The primary evidence is the recordings and the full agent transcripts, linked in Materials. This document is the index to that evidence, not a substitute for it.