An AI agent wrote your app. Now it needs somewhere to live, and this decision is less about brand names than about what shape of app the AI actually built, because that determines which hosts can run it at all. We host AI-built apps in production, so this is the operator's version of the answer, including the export failure everyone hits.
First: which shape is your app?
Look at what the agent produced (or ask it: "does this app have a server?").
- Static: HTML, CSS, and browser JavaScript only. All logic runs in the visitor's browser; data, if any, lives in their browser too.
- Server-backed: there is a
server.js, an API, a database. Logins, saved bookings, orders, anything shared between users means you are in this category.
Most apps that do something for more than one person are server-backed, and most "host anything free" advice quietly assumes static. That mismatch is the number one source of "my app works in preview and dies when I move it."
The four real options
1. Static hosts (Netlify, GitHub Pages, Cloudflare Pages). Free, fast, superb for static shapes: landing pages, portfolios, browser games with local saves. They cannot run your server; deploying a server-backed app here silently serves the frontend with every API call failing.
2. Serverless platforms (Vercel and friends). Run server code as functions. Excellent for apps written in the frameworks they expect (Next.js especially). AI-built apps are often plain Node/Express, which needs adaptation to fit the function model, and long-lived things (websockets, background jobs, an agent that keeps working) fight the platform's timeouts.
3. A VPS. A rented Linux box runs anything, including the always-on shapes serverless dislikes. The cost is that you are now the ops team: TLS, restarts, disk, security patches. Fine if you enjoy it; a tax if you do not. Related: what it takes to keep an agent itself running 24/7.
4. The builder's own hosting. If a platform's agent built the app, its hosting already knows the app's shape: the server runs in a managed container, the database is attached, the domain is wired, and, critically, the agent that built the app can still reach it to fix and evolve it. This last property is the one the other three options give up: exported code is frozen the moment it leaves unless you bring your own developer workflow.
What actually breaks when you export
We watch exports and migrations, and one failure dominates everything else: secrets do not travel with code.
A working app reads its configuration (database URL, Stripe secret key, API tokens) from environment variables that the original host injected at runtime. The repository you export deliberately does not contain them; committing secrets to a repo is how keys end up leaked and abused. So the exported app boots on the new host, renders its pages, and every feature that needed a secret fails, usually as a vague 500.
The fix is mechanical once you know it: list every process.env.X the code reads, and set each one in the new host's environment settings before first deploy. While you are at it, confirm three more classics: the app must listen on the port the host assigns (process.env.PORT), the database needs to be migrated, not just linked (a connection string to an empty database is not your data), and any file uploads stored on local disk will not survive on hosts with ephemeral filesystems.
A 60-second checklist
- Server or static? (Ask the agent.)
- Does anything need to run continuously: webhooks, schedules, background jobs? That rules out static and strains serverless.
- List the env vars. Every one must exist on the new host before you deploy.
- Where is the data, and how does it move?
- Who fixes the app next month, and can they still reach it where it lives?
On VibeKit, apps deploy to managed containers with the environment, database, and domain handled, the agent that built your app stays attached to it, and the code exports to your own GitHub whenever you want the portable path anyway. The free tier hosts your first version at a real URL, which is the cheapest way to learn your app's actual shape.