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
Top comments (0)