You built an app with AI. Now what?
The code is written, it runs on your laptop, and it is sitting on GitHub. Then the instructions start saying “configure a reverse proxy” and it has been three weeks. This is what the missing step actually involves, what you can skip, and how to deploy by sending a message.
There is a particular kind of stuck that has become very common this year. You described what you wanted, an AI wrote most of it, and it works. It is on GitHub. You bought a server because somebody said you needed one. And then the next instruction was “point an A record at your droplet and configure nginx as a reverse proxy”, and it has been sitting there ever since.
The gap between a thing that runs on your laptop and a thing other people can use is not more code. It is a separate discipline with its own vocabulary, and nobody taught you any of it because until recently you would not have got this far without learning it on the way.
What the missing step actually is
Stripped of jargon, putting an app live means five things. It is worth seeing the list, because it is shorter than it feels and because most of it only has to be done once.
| The step | What it means | How often |
|---|---|---|
| Get the code onto the server | Copy it from GitHub to the machine you rented | Every change |
| Install what it needs | The language, the libraries, maybe a database | Once, then rarely |
| Keep it running | Start it again if it crashes or the server reboots | Once |
| Put it on your domain | So people reach it by name, over https, not by an IP address | Once |
| Know when it breaks | Because it will, and nobody will tell you | Forever |
The fifth is the one people skip, and it is the one that matters most. A site that goes down on a Saturday and comes back on Monday because you happened to look is not really live.
Three ways across, honestly
A platform that does it for you
Vercel, Railway, Render, Fly. You connect your repository and they handle everything above. For a lot of projects this is simply the right answer, and if your app is a straightforward web app you should try this first.
Where it stops working is cost and shape. Platform pricing is generous until the moment it is not, and some things — a long-running worker, a database you want on the same machine, software that expects a real filesystem — either cost a lot there or do not fit at all.
Learn it
A weekend with a good tutorial will get you a working server, and you will understand your own stack better for it. The honest caveat is that you are not learning a thing, you are learning a field, and the half-learned version is worse than either end: a server configured by somebody following instructions they did not understand is one that fails in ways they cannot diagnose.
Have something do it and explain as it goes
This is the third option and the one we built, so read it with that in mind. You rent a server, connect it once, and then operate it by sending messages — and the answers come back in sentences rather than in output you have to interpret.
What that looks like in practice
You paste one line into your server, which every hosting provider lets you do from a web page without a terminal. After that it is a conversation on WhatsApp.
- “Is my site up?” — it fetches it and tells you the status and how long it took.
- “Deploy” — it names the commit and its message so you recognise your own work, asks you to confirm, puts it live, then checks the site still answers.
- “Undo” — the previous version is still on disk, so going back is instant.
- “Why is it slow?” — it checks memory, disk and services in a fixed order and tells you which one it is.
The part worth insisting on: if a deploy breaks the site, the old version is already back before you are told anything went wrong. A deploy you cannot reverse is the single most expensive thing a beginner can do to a live site, so it is reversed automatically rather than offered as an option you have to think of.
The objection you should have
An AI with a shell on your production server sounds like a terrible idea, and it is. That is not what this is, and the difference is worth being specific about, because “we have guardrails” is what everybody says.
The agent cannot run commands. It picks from a fixed list of specific operations — restart this service, deploy this commit, show me this log — and that list is compiled into software running on your own machine. Nothing it says can add to the list, and neither can we. An attacker who sent instructions from our side would still only be able to ask for things you had already ticked.
The things that cannot be undone — deleting a database, changing the firewall, editing who can log in — are not on the list at any setting. They are done from a console, signed in, with the action typed out to confirm. That rule exists because of who this is for: asking somebody to approve dropping a table only helps if they could tell it was the wrong answer.
What you should still learn
Not nothing. An agent that runs your server and teaches you nothing leaves you more stuck than before, so the two things worth understanding are the two that cost real money when they are wrong.
- Backups. Know what is backed up, where it goes, and — the part everybody skips — that restoring it actually works. Test it once while nothing is wrong.
- What your app depends on. A database, a file directory, an API key in an environment variable. Losing the code is recoverable because it is on GitHub; losing the data is not.
Common questions
Common questions
Do I need to pick a specific hosting provider?
Any Linux server with systemd that you can run one command on: Hetzner, DigitalOcean, Contabo, Vultr, Linode, AWS Lightsail. It is not for managed hosting where you cannot install anything.
How much server do I need?
Far less than you think. Most apps built this way run comfortably on the smallest instance a provider sells, and an agent watching it will tell you when that stops being true rather than leaving you to guess upward.
What if I outgrow this?
Then you hire somebody, and they find an ordinary Linux server with releases in dated directories and a service file — a normal setup they can take over, not a proprietary arrangement they have to unpick.
Is my code sent anywhere?
It is cloned from GitHub to your own server. The agent reads your repository to tell you what a commit contains; the code never passes through us.
More about server agents · The documentation