You Built an App with AI. Here's the One Part It Can't Do: Run It

The AI gave you a working app, but now it only lives on your laptop, breaks when you close the terminal, and has no real address people can visit.

Short version: how to host an ai-built app means putting its code on a server, connecting a domain, adding HTTPS, keeping the app running, and making sure it can recover when something goes wrong. AI can write a lot of the code, but it usually does not own the boring operational parts: ports, processes, certificates, logs, restarts, backups, and resource limits.

What does AI build, and what is still missing?

AI is good at making the thing in the box: a React front end, a Node.js API, a Python service, a database schema, maybe a Docker file if you asked nicely.

Hosting is everything around the box.

Think of the app as a small shop. AI helped you stock the shelves and paint the sign. Hosting is the street address, the front door, the lock, the lights, the cleaner, and the person who notices when the power goes out.

That missing layer includes DNS, which points your domain to the right place; HTTPS, which gives visitors the padlock; a running process, which keeps the app alive; and logs, which tell you what happened when it did not.

If the app works locally but nobody else can reach it, the code may be fine. The shop just has no open door yet.

Where can you host an AI-built app?

You have three common paths.

A managed app platform is the easiest mental model. You upload the project, set a few values, and the platform hides much of the machinery. It can be a good fit for simple apps, but you may hit limits when you need custom services, background workers, special storage, or predictable long-term control.

Your own server gives you more room. You decide what runs there: the app, database, worker, queue, admin tool, or several small projects side by side. The tradeoff is that you must understand what is on the machine, how traffic reaches it, and how it stays alive.

A self-hosted control panel sits in the middle. It gives you buttons and screens over the same basic server concepts. That can help, but it does not remove the need to know what the app depends on. If you are comparing those paths, our guide to deploying a small web app without DevOps is a useful next read.

Docker may also appear in AI-generated instructions. Docker packages an app with the parts it needs, like putting a meal kit in one labeled box instead of scattering ingredients around the kitchen. If that word is new, start with Docker on a server for beginners.

What usually breaks when the app goes online?

The first failure is often the address. Your domain points to the wrong place, or the app listens on a private port nobody can reach. To a visitor, that looks like a blank page or a browser error. Underneath, it is usually a routing problem: the road does not lead to the shop door.

The second failure is HTTPS. A wrong or expired certificate makes the browser warn people away, even if your app is healthy. The padlock is not decoration; it is how browsers decide whether the connection can be trusted. For the plain version of that setup, see how to get free HTTPS on your server.

The third failure is the classic reverse-proxy problem: 502 Bad Gateway. In plain English, that means the front desk answered the phone, but the person in the back room did not respond. The public web server is alive, but your app process is down, on the wrong port, still starting, or crashing.

Then come the slower problems. The app works on day one, then gets sluggish because the database grew, image uploads filled the disk, or one busy project steals memory from another. AI rarely plans for that unless you ask very specifically.

The last common breakage is memory loss — not the server’s memory, yours. Three months later, you forget which environment variable mattered, where the database lived, or why one folder was named strangely. That is when a working setup becomes a fragile mystery.

FAQ

Can AI deploy my app for me? It can suggest steps, write files, and explain errors. It usually cannot verify your domain, certificate, firewall, database, backups, and long-term setup in the way a real hosting environment needs.

Do I need Docker for an AI-built app? Not always. Docker helps when your app has several moving parts or needs the same setup everywhere, but a small static site or simple script may not need it.

Why does my app work locally but not online? Local means your own machine can reach it. Online means the domain, public port, HTTPS certificate, app process, and database all line up correctly.

**What does 502 Bad Gateway mean?** It usually means the public web layer is running, but it cannot reach your app behind it.

Should I put multiple AI-built apps on one server? You can, but keep them separated enough that one broken app, full disk, or bad setting does not take the others down.

The shortcut

Server Manager helps turn the messy “now run it somewhere” part into something you can still understand later. Instead of ending up with a pile of half-remembered setup notes, you get a clear picture of what belongs to each project: the domain, the running app, the certificate, and the pieces it depends on.

That matters when the real failures arrive. A wrong HTTPS certificate, an app that does not come back cleanly, one project interfering with another, or a forgotten setting from months ago becomes easier to spot and reason about. The real benefit is not avoiding knowledge; it is keeping the setup legible enough that you are not afraid to touch it.

For an AI-built app, that means your energy can stay on the product itself instead of repeatedly rediscovering how it was launched.

What changes when running is handled?

An app is not really finished when the AI stops typing. It is finished when someone can visit it, trust it, use it tomorrow, and still have it work after the next restart.

Once the hosting layer is clear, the project stops feeling like a lucky local demo. It becomes a real service with an address, a lock on the door, and a setup you can understand when you come back to it later.