DEV Community: Sigrid Keydana

What makes for an agent-native cloud? Five tests

Sigrid Keydana — Fri, 13 Nov 2026 10:12:03 +0000

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.

What five clouds' own docs tell an AI agent about where to keep app data

Sigrid Keydana — Thu, 05 Nov 2026 10:50:47 +0000

Your agent can put an app online. Will it know how to keep the app's data?

Interestingly, one does not imply the other. In this article, we ask a precise question: when an AI agent wants to figure out where the data goes, what does each host actually tell it — it, the agent: not a human reading the docs, but an agent reading the machine-readable index the host publishes for agents.
We checked five clouds on 5 November 2026. We build one of them, Cloudish, and employed AI in preparing this.

The method

A growing number of hosts publish an llms.txt: a short index a model can fetch, written for agents, not for a browser. It lists the pages that matter and the rules for working with the platform. An agent told "deploy this, and keep its data" starts there.

We read each host's llms.txt (and its agent skill file where one exists) and looked for one thing: what does it say about where app data lives, and what keeps or deletes it. For each host we asked whether the agent-facing text answers that question at all — or leaves the agent to guess.

What each host tells an agent

Cloudish — the only one that answers the data question in the index

Cloudish's llms.txt opens with "Cloudish is a container cloud an AI agent can deploy to on its own." Then, under spending and persistence, it tells the agent the answer directly: "An optional persistent volume per app (SQLite works well on it); not billed." And when the money runs out: "at zero, builds and deploys answer 402 and its running apps stop within a minute, volumes kept."

An agent gets the whole story from the index: the app runs in a container, there is a disk, SQLite works on it, and stopping the app or running out of credit does not delete the disk.

What the index does not say is just as important: there is no managed Postgres or MySQL, and no disk backups. An agent that assumes a managed database gets this wrong. Cloudish's skill file states it plainly elsewhere — "No managed Postgres/MySQL offering" — but the llms.txt itself does not.

Render — names disks and Postgres, skips the catch

Render publishes an agent index with setup guides for Claude Code, Cursor and others. For data it says: "Persistent Disks: Preserve your service's filesystem changes across deploys", and "Render Postgres: Deploy fully managed, enterprise-grade databases."

That is a real answer: attach a persistent disk, or use managed Postgres. But the index never mentions the catch that matters most to a hobby app — Render's free web service has no disk of its own, and its files are lost on every redeploy, restart, or spin-down. That is in the human docs; the agent-facing index is silent on it. An agent that reads only the index could put a SQLite file on a free Render service and lose it on the first restart.

Fly.io — managed Postgres up front, volumes hidden in the fine print

Fly.io's llms.txt has an explicit "AI-agent notice" and lists "Managed Postgres" — "Production PostgreSQL with backups, failover and connection pooling" — alongside "Persistent, hardware-isolated Linux computers for agents." So an agent learns Fly has managed Postgres and persistent machines.

But the word "volume" — Fly's own term for the disk a container attaches — does not appear in the index at all, even though volumes are a core part of Fly's docs. An agent told "use Fly with a volume" has to leave the index and go find it.

Railway — volumes named once, nothing about what survives

Railway's llms.txt has a whole "For AI Agents" section and even "Free VMs, no sign up". Data appears in a single breath: "deploy, databases, volumes, functions, config." The word "volume" is there; what happens to the data on it is not. Nothing in the index says what survives a redeploy, a sleep, or a canceled plan. The agent learns the feature exists, not what it keeps.

Vercel — the index says nothing about data at all

Vercel's llms.txt is the most polished of the five — MCP, a plugin, skills, sandboxes. But search it for where a database or a file goes and you find nothing. The only storage word sits in a template blurb: "Deployable starter projects for frameworks, AI, storage, and more." An agent reading only Vercel's index learns Vercel can deploy web apps, and nothing about where their data lives — which, for a serverless function with no mounted disk, is the first thing it needs to know.

The table

Host	Names a database or disk in its agent index?	What an agent is told about data	What the agent still has to guess
Cloudish	Yes — "persistent volume per app"	Volume, SQLite works, kept at zero balance	No managed DB, no backups
Render	Yes — "Persistent Disks", "Render Postgres"	Disk and managed Postgres exist	Free tier has no disk; files are ephemeral
Fly.io	Partly — "Managed Postgres"	Managed Postgres, persistent machines	Volumes exist but aren't named
Railway	One word — "volumes"	Volumes exist	What survives on them
Vercel	No	Nothing	Everything

What this costs a builder

The gap shows up as a specific failure. An agent asked to "put my to-do app online and keep the to-dos" reads the index, finds a way to deploy, and picks a host that either has no disk (Vercel's serverless functions, Render's free tier) or keeps the disk secret (Fly's volumes). The app works on day one. The data vanishes on the first redeploy. The builder, who is not a programmer, has no idea why.

This is not a bug in any one host. It is what happens when the index an agent reads is written to sell a platform, not to answer "where does my data go?" Only one of the five wrote that answer into the index.

What to paste to your agent

Don't let the agent stop at "deployed." Add one sentence:

Before you deploy, tell me where this app's data will be stored, and what will delete it — a redeploy, a restart, sleep, an expiry date, or only me deleting it. If it needs a disk or a database, name the one you'll use.

If the agent answers "it's deployed, it's fine," ask again. A good agent names the host, the disk or database, and what wipes it.

Where Cloudish fits

Cloudish is the one we build, but the reason this study flatters it is real: of the five, it is the only host whose agent-facing index answers the data question directly. But the same index shows where Cloudish loses — no managed Postgres or MySQL, and no backups on the disk. If you need a managed database with failover and backups, the agent index points to Fly.io or Render, not to us. That is the honest version, and it is the one we'd rather you quote.

Written by the team behind Cloudish, at Hal9. The five llms.txt files were read on 5 November 2026; links below.

Sources (checked 2026-11-05)

Cloudish — https://cloudish.ai/llms.txt (and https://cloudish.ai/skill.md)
Render — https://render.com/llms.txt
Fly.io — https://fly.io/llms.txt
Railway — https://railway.com/llms.txt
Vercel — https://vercel.com/llms.txt

Your agent put the app online. Will your data still be there next week?

Sigrid Keydana — Fri, 23 Oct 2026 18:16:03 +0000

You asked your coding agent to "just put it online." It did. You got a link, the app works, and you've already added your first five to-dos.

Here's the question nobody asked: where did those five to-dos go, and what will delete them?

It depends on the route your agent picked. One keeps nothing on a server. One keeps your database for 72 hours. One wipes your SQLite file (a whole database in a single file) every time the app falls asleep. We looked at seven routes, starting with the ones where nobody signs up. We build Cloudish, one of the seven, and used AI in preparing this post.

How long does your data last?

Route	Who signs up first	Where the data lives	What deletes it
Netlify, no account	Nobody, for static sites	Nowhere on a server	Nothing to lose; claim the site within an hour to keep it
Claimable Neon	Nobody	A Postgres database, up to 100 MB	The whole project, after 72 hours, unless a person claims it
Cloudish with a volume	Nobody	A disk of 1, 5 or 20 GB	Only deleting the project
Render Free web service	A person	The app's own disk	Every redeploy, restart or nap
Render Free Postgres	A person	A 1 GB Postgres database	Expires after 30 days; deleted 14 days later unless upgraded
Railway with a volume	A person, on the $5 Hobby plan	A disk	Removed 60 days after you cancel
Fly.io with a volume	A person, with a card	A disk on one machine	A drive failure, if it's your only copy

Netlify: online in seconds, but nothing saved

Netlify's command line has a flag that, in its own words, "is useful for AI agents": netlify deploy --allow-anonymous. It "creates a project with a live URL. You have one hour to claim ownership by logging in or creating a Netlify account."

The catch for data comes right after: "sites or apps that use serverless functions or edge functions will require an account."

So this route is for pages. A portfolio, a landing page or a demo is perfect. A to-do list that saves to a server needs an account, or another route.

Claimable Neon: a real database, on a 72-hour clock

Claimable Neon lets your agent create a Postgres database with no account at all. Neon is upfront about the limits: "Unclaimed projects expire in 72 hours (project.expires_at) and are capped at 100 MB storage and 1 GB transfer. Claim codes expire in 15 minutes (expires_in). Those are two clocks."

Two things catch people out:

The claim code goes stale fast. It lasts 15 minutes. Your agent can ask for a fresh one, but only while the project itself is still alive.
Claiming changes the password. When you claim, Neon "revokes the project key, access tokens, and database password," and tells you to "Fetch a new DATABASE_URL there." Your live app keeps using the old one until someone updates it.

Great for a database you'll claim today. Not for data you want to keep without anyone ever logging in.

Cloudish: a disk nobody has to sign up for

Cloudish is the one we build. Here's how it keeps your data, and where it falls short.

Your agent creates its own key with one call. In Cloudish's words, there's "No signup, browser, card, OAuth or approval step." The app runs as a container, and the agent can give it a disk, which Cloudish calls a volume, of 1, 5 or 20 GB.

What deletes it? According to the FAQ, the volume "survives restarts, redeploys, idle scale-downs and running out of credits," and "only goes away when the project is deleted." If the prepaid balance runs out, the app stops within a minute, but the data on the disk stays.

What to know before you pick it:

One app copy per disk. "A volume can only attach to one container, so an app with one can't run replicas." If you need several copies sharing a disk, look elsewhere.
No managed database. "Cloudish has no managed Postgres/MySQL offering." SQLite on the disk is the simple path; you can also run Postgres inside the container.
It isn't free. Disks aren't billed, but the app is, per second while it runs. The smallest size costs $0.0107 an hour, and by default the app sleeps after 15 quiet minutes, for free. Used an hour a day, that's about $4.90 a year; always on, $94.03.
The smallest size can restart. An app on it that uses more than its 0.2 GB of memory "can be restarted" when its machine runs short. The disk survives that. For Postgres inside the container, Cloudish suggests a bigger size, about $13.53 a year at an hour a day.

Great for an app your agent deploys with SQLite or a small Postgres, when nobody wants to sign up. Not for apps that need several copies on one disk, or a managed database with backups.

Render Free: free, but your SQLite file won't last

Render Free needs a person: step one in Render's docs is "Sign up for Render." It's free, though, so it's worth knowing what happens to your files there.

Render "spins down a Free web service that goes 15 minutes without receiving any inbound traffic." The next visitor wakes it up, which "takes about one minute."

Then the part that matters: "any changes to your web service's filesystem (uploaded images, local SQLite databases, etc.) are lost every time the service redeploys, restarts, or spins down." Render also "might restart a Free web service at any time," and a free service can't get a disk of its own.

For data, Render's free option is Free Postgres, with "a fixed storage capacity of 1 GB." But "Free Render Postgres databases expire 30 days after creation." You then get 14 days to upgrade before "Render deletes the database (along with all of its data)."

Great for an API that stores nothing. Not for SQLite, uploads, or anything you want next month.

Railway, Fly.io and Render: disks with backups

If losing the data would really hurt, the safest bet is still a person with an account on a host that backs up its disks. Even Cloudish's FAQ points people to Railway, Render or Fly "if a human wants a long-running container with a volume and is happy to sign up in a browser and put a card on file."

Railway: the Hobby plan is $5 a month and "includes a resource usage credit of $5." Disk space costs "$0.15 / GB / month", and services with volumes "support manual and automated backups." Cancel Hobby, and Railway deletes the disk's data 60 days later.
Fly.io: a volume costs "$0.15/GB/month". Fly takes daily snapshots and keeps them "for five days by default." It also warns: "Always provision at least two volumes per app," because volumes don't copy data to each other. And after you sign up, "At some point, you'll be prompted for credit card payment information."
Render, paid: attach a persistent disk to a paid service. Render "automatically creates a snapshot of your persistent disk once every 24 hours," and "Snapshots are available for seven days after they're created."

These disks share one limit with Cloudish's: a disk belongs to one running copy of your app. A Render disk "is accessible by only a single service instance," a Fly volume "can be attached to only one Machine," and on Railway, "Replicas cannot be used with volumes."

Which route for which app?

A demo that saves nothing: Netlify, no account, if it's only pages.
A database for today: Claimable Neon. Claim it within 72 hours, then give the app its new DATABASE_URL.
A free API that stores nothing: Render Free.
An app with SQLite, deployed by your agent, with nobody to sign up: Cloudish with a volume.
Data you can't lose: a person signs up for Railway, Fly.io, or a paid Render service with a disk.

One question to ask your agent

Next time you say "put it online," paste this in too:

Before you deploy, tell me: does this app save anything? If yes, where will it be stored, and what will delete it (a redeploy, a restart, sleeping, an expiry date, or only me)? If I need to claim something to keep it, tell me how long I have.

A good agent answers in a line per question. If yours can't, it picked the route before checking.

And whatever you choose, keep your own copy of anything you can't lose. Have the app export it somewhere else every so often.

Did your data ever vanish after a deploy? Tell us what happened in the comments.

Written by the team behind Cloudish, at Hal9. Limits and prices as of October 23, 2026.