Self-Hosting an App You Built in an AI Builder
Written By
SprintX Team
AI & Product Engineering
July 28, 2026
6 min read
Moving an AI-built app onto infrastructure you control, in the order that keeps it running — plus the operational work the builder was doing for you invisibly.
"Self-hosting" means three different things, and picking the wrong one is how a weekend migration turns into a month of yak-shaving.
Sometimes it means getting off the builder's preview URL onto a normal hosting platform. Sometimes it means a virtual machine you administer. Occasionally it means containers, orchestration, and a private network — because a customer contract says the data cannot leave a particular jurisdiction or a particular account.
The work, the ongoing cost, and the skills required differ by an order of magnitude between those. Start by deciding which one you actually need.
Pick the level that matches the reason
| Level | What it is | Good reason to pick it | Real ongoing cost |
|---|---|---|---|
| Managed platform | Vercel, Netlify, Render, Railway, Fly.io | You want out of the builder, not into sysadmin work | Near zero; you still patch dependencies |
| Single VPS | One Linux box you own, Docker Compose on top | Predictable costs, long-running processes, full control | A few hours a month, plus you own the pager |
| Container platform | ECS, Kubernetes, or a private cloud account | Compliance, data residency, or a customer's account | Meaningful — this is a job, not a task |
Most founders asking about self-hosting want level one and have been talked into imagining level three. If your reason is "I want to own my deployment" rather than a written requirement from a customer or regulator, a managed platform is self-hosted enough: the code is yours, the repo is yours, the database is yours, and you can move again in an afternoon. Our guide to deploying on Vercel covers the common path.
Pick level two when you have long-running work — queues, websockets, scheduled jobs, anything that does not fit a request-response function. Pick level three only when someone external is requiring it.
Find what the builder was doing for you
This is the step that determines whether the move is smooth. AI builders quietly run several services that have no code in your project, and each one becomes yours the moment you leave.
Work through the list and mark which ones you are using:
- Database hosting, including backups you never configured and connection pooling you never thought about.
- Auth, including password resets, email verification, and session storage.
- File storage and whatever CDN was in front of it.
- Transactional email — the platform may have been sending from its own domain, which means your deliverability reputation starts at zero on the new setup.
- Secrets injection, which is why your app has no .env file and no documentation of what it needs.
- TLS certificates and their renewal.
- Scheduled jobs and background workers.
- Logs, which you have never needed to think about because there was a tab for them.
For each one, decide now: self-hosted, managed service, or dropped. My strong recommendation is to keep the database and email as managed services even at level two. A self-managed Postgres with no tested restore path is not ownership, it is exposure. Extraction specifics vary by tool — see getting code off Replit if you are still at that stage.
The move, in order
1. Make the app build from a clean checkout. Clone your repository into an empty directory, install, build, run. Fix whatever breaks. If it only builds inside the builder's workspace, everything after this step is guesswork.
2. Write a Dockerfile, even for a managed platform. It is the most portable statement of "how this app starts" you can have. Multi-stage, non-root user, explicit port, no secrets baked in.
3. Inventory every environment variable and commit an example file. Names and comments, no values. This artifact is worth more than any deployment doc; it is also the fix for the single most common post-migration failure, covered in environment variables that stop working after a move.
4. Stand up the database and restore a real dump into it. Do this before touching the application. Verify row counts per table against the source.
5. Deploy the app pointed at the new database, but not at your domain yet. Exercise signup, login, a write, a file upload, and any scheduled job while watching logs.
6. Cut DNS over with a short TTL. Drop the TTL to five minutes a day in advance so you can reverse the change quickly.
7. Keep the old deployment alive for a week. Read-only if the platform allows it.
The ordering matters because each step is independently reversible. A migration where the database, the app, and the domain all move at once has no safe rollback point.
The parts nobody plans for
Everything above is the project. This is the part that becomes your life afterward, and it is the honest cost of self-hosting.
Backups you have restored. An untested backup is a belief, not a backup. Restore into a scratch database once, write down how long it took, and put a reminder in the calendar to repeat it quarterly.
Certificate renewal. Automated via a reverse proxy that handles it, or you will find out on a Sunday. Set an expiry alert regardless of automation.
Log retention and access. Ship logs somewhere outside the box that generates them. A crashed server with the only copy of the logs explaining the crash is a genuinely miserable afternoon. See monitoring and alerts for a small SaaS for a setup that fits a two-person team.
Patching. Base image updates, dependency updates, and OS security patches are now yours. Budget an hour a month and actually take it.
Secrets management. Environment variables in a hosting dashboard are fine at small scale. Environment variables pasted into a shell history on a shared VPS are not.
A rollback path. Tag releases, keep the last known-good image, and know the command that puts it back. Ideally before you need it.
When self-hosting is the wrong call
If you are a solo founder with fifty users and no compliance requirements, moving to a VPS to save forty dollars a month is a bad trade — you are buying an on-call rotation of one. If your app is failing under real load, hosting is rarely the cause; the cause is usually the database access pattern the AI generated, which follows you to any host. Apps that get slow once real data arrives is the better starting point there.
Self-host when control is the requirement. Use a platform when speed is.
Frequently asked questions
Do I need Kubernetes? Almost certainly not. A single VPS running Docker Compose handles a startup's traffic for a long time, and it is something one person can hold in their head at 3am. Adopt orchestration when you have multiple services and someone whose job includes running them.
Is self-hosting cheaper? On the invoice, usually. In total cost, only if your time is cheap. A managed platform at eighty dollars a month against a twenty-dollar VPS is a sixty-dollar difference; two hours of your month costs more than that.
Can I self-host part of it and leave the rest? Yes, and this is often the right answer. Self-host the piece with the actual requirement — often the database, for residency reasons — and keep the frontend on a CDN-backed platform. Split by requirement, not by ideology.
If you are moving an AI-built app onto your own infrastructure and the list of things the builder was silently handling keeps growing, that is the normal experience, not a sign you missed something. SprintX does these migrations end to end — containerized build, database move, secrets, backups, monitoring, and a rollback path you have tested. Tell us where the app lives now.
