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 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), a fly.toml the 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.

---

Written by the team behind Cloudish, at Hal9.