What makes for an agent-native cloud? Five tests
An agent-native cloud is a cloud an AI agent can sign up for, pay for, and deploy to with no person in the loop. That is not a standard term yet — it is new, and we are one of the people trying to define it, so the rest
An agent-native cloud is a cloud an AI agent can sign up for, pay for, and deploy to with no person in the loop.
That is not a standard term yet — it is new, and we are one of the people trying to define it, so the rest of this article is the definition made checkable: five tests, each one answered against the hosts' own docs, so you can verify or argue with it instead of taking our word. AI assistance was used in preparing this article.
The five tests
For each test, the useful form is the question an agent actually runs into mid-deploy:
1. Can the agent get its own credential? If a human has to create the account, add a card, and mint a token first, the agent is not deploying alone — it is deploying after a person. The test: can the agent mint its own key with one call, no browser?
2. Is there a ceiling the agent can't spend past? An agent told "deploy this" can loop, retry, and spawn resources. The test: is there a hard, prepaid limit, or just an alert that a person might see too late?
3. Can the agent check the build and app logs itself? "Done" is not a deployment status; it is a judgment the agent should be able to reach from logs. The test: can the agent read build and runtime output with the same key it deploys with?
4. Can the agent hand the project to a person later? An agent-built app eventually needs an owner with a browser. The test: is there a claim link or handoff that does not require the agent to share its own key?
5. Can it give a sub-agent its own smaller budget? The real deployments are nested — an orchestrator hands a slice to a sub-agent. The test: can you mint a child key with its own cap?
The table, checked against the docs
Marks are Yes, Partly or No, each backed by the host's own docs, pricing or CLI pages, checked 13 November 2026.
| Test | Cloudish | Fly.io | Railway | Render | DigitalOcean | Vercel |
|---|---|---|---|---|---|---|
| Agent gets its own credential |
Yes — POST /api/v1/keys returns a key, no login, no card |
No — a person creates the account, card and token first | No — a person creates the account and token | No — a person creates the API key in the dashboard | No — a person creates the API key in the dashboard | No — a person's account and token come first |
| Hard spend ceiling | Yes — prepaid balance, stops at zero | Partly — alerts on a card on file | Partly — an opt-in hard usage limit (stops workloads when hit), not a prepaid cap | Partly — alerts on a card on file | Partly — alerts on a card on file | Partly — spend management, not a prepaid cap |
| Agent reads build and app logs | Yes — same key reads logs |
Yes — fly logs
|
Yes — railway logs
|
Yes — Render API |
Yes — doctl
|
Yes — vercel logs
|
| Hand the project to a person | Yes — claim link | Partly — manual account/team handoff | Partly — manual team handoff | Partly — manual team handoff | Partly — manual team handoff | Partly — manual team handoff |
| Sub-agent with its own budget | Yes — child keys | Partly — scoped deploy tokens, not budgeted | No | No | No | No |
The two tests that separate the field are the first two. Every host lets an agent read logs once it has a key (test 3), so that one is a table of equals. The claim-link and child-key rows (tests 4 and 5) are where the conventional hosts still expect a person to be the account owner.
Who's strong where
From this table, we can directly see each host's strengths:
- Render's free tier is the best price for a light app a person is willing to babysit — $0, as long as you accept that the filesystem is ephemeral.
- Railway's opt-in hard usage limit is the cleanest "can't overspend" answer for a human-owned hobby app.
-
Fly.io has the strongest agent story among the conventional hosts: a real CLI (
fly deploy), afly.tomlthe agent can edit, and scoped deploy tokens — a person just has to be there first. - Vercel is the obvious pick when a person iterates on a Next.js-style site and wants a preview on every change.
Conclusions
- Vercel when a person is iterating on a frontend and wants PR previews.
- Railway, Render or Fly.io when a person is around to sign up — they are more battle-tested for always-on, heavy workloads.
- AWS or GCP for platform teams that need IAM, compliance and regions.
- Cloudish when the branch is really "no person is around": an agent told to deploy at 2 a.m., a CI step that ships a preview, a tutorial that ends with "and put it online."
Hopefully, you've found some useful guidance in this article!
As always, if you read this as a later time, please keep in mind that docs can also drift from the product — the table above is what the docs say as of this writing, not a promise.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.