Key takeaways

When the AI stops generating, what you have is a set of files. Files are not a website. Hosting is the name for everything that turns those files into something other people can open.
Four things happen in order: a build turns your files into what a browser can actually run, a deploy puts that output somewhere public, a domain gives it an address people can type, and then it has to keep running.
A modern app is not just pages. It needs somewhere to do work, somewhere to keep data, and somewhere to store files, and those are part of hosting now even though the word does not suggest it.
The property to care about most is what happens when a change is wrong. Deploys that fully land or do not happen at all, with the previous version kept intact, are what make changing an app safe.
You do not need to understand any of this to ship. You need it to know what you are being asked when someone says “where is it hosted?”

The AI finished. There is a working thing on your screen, and then either it lives at a URL that looks temporary, or you are being asked about deploying, and somewhere in the conversation words like build, server, and domain are being used as though you already know which is which.

Nobody explains this part, because to the people writing the tools it is too obvious to mention. So here is the plain version: what exists the moment generation stops, and each thing that has to happen between there and a colleague opening your app on their phone.

What you actually have when the AI stops

You have files. Text files, mostly, sitting in a folder either on your computer or on a machine belonging to whatever tool you used.

Those files are instructions. They describe what should appear on screen, what should happen when someone clicks, and what to do with the information people type in. They are not themselves a website, in the same way a recipe is not dinner.

Two things have to be true before anyone else can use them. The instructions have to be turned into a form a web browser can follow, and the result has to be sitting on a computer that is switched on, connected to the internet, and willing to hand it to anyone who asks. That second computer is what people mean by a server, and the whole business of arranging it is what people mean by hosting.

If that already sounds like a lot to arrange, that is the correct reaction, and it is exactly why this got turned into a product.

Step one: the build

A build is a translation step. It takes the files you have and turns them into the smaller, faster, browser-ready version that actually gets served.

It exists because the form that is convenient to write is not the form that is efficient to deliver. The build collapses many files into few, strips out anything only useful while writing, and converts newer conveniences into something older browsers still understand.

You will mostly encounter builds when one fails, which is worth being ready for. A failed build means the translation could not complete, the deploy does not happen, and the previous version of your app stays up untouched. That last part is the good news: a broken build cannot break your live app, because the new version never gets that far.

This is also the first place an AI agent earns its keep. Build failures produce specific error messages, and reading an error and fixing what it names is something agents are genuinely reliable at.

Step two: the deploy

A deploy is moving the built output onto the public internet.

The word covers something that used to be genuinely laborious, involving copying files onto a server by hand while hoping nobody visited halfway through. That method had an obvious flaw: for a few seconds your site was half old and half new, and whoever loaded it during that window got something broken.

The modern version fixes this by being atomic. The deploy either completes entirely or does not happen at all, so there is no moment where half of each version is live. On Netlify deploys are also immutable, meaning the previous deploy is not overwritten. It is still sitting there, complete, which is why going back to it is a single click rather than a repair job.

Hold onto that property. It is the difference between changing your app freely and being afraid to touch it.

Step three: the domain

A domain is the address people type. Without one, your app still exists, but at a machine-generated URL that is fine for testing and looks untrustworthy on a business card.

Connecting a domain means telling the internet’s address book that your name should point at your app. That is what DNS does, and it is one of the older and more fiddly corners of the internet, which is why having it managed for you is worth something.

There is a second piece bundled in here. The padlock in the browser bar means traffic between your visitor and your app is encrypted, which requires a certificate, which expires and must be renewed. Automatic TLS means that renewal happens without anyone remembering to do it. It is a small thing that becomes a large thing on the morning it lapses.

Step four: the parts that keep running

Here is where the word “hosting” undersells the job, and where most explanations stop too early.

If your app is only pages, everything above is the whole story. Almost no useful app is only pages. The moment it remembers something, checks something, or does something on behalf of a user, it needs more than delivery.

It needs somewhere to run code that is not a page. Netlify Functions handle that: small pieces of code that run when something calls them, without you operating a server that sits waiting.

It needs somewhere to keep data that survives. Netlify Database is managed Postgres, provisioned when you deploy. Postgres is the boring, standard choice, which is a compliment, and it means your data is in a format anything else can read.

It needs somewhere to put files people upload, which is Netlify Blobs. It needs a way to know who someone is, which is Netlify Identity. And if it calls an AI model, it needs access to one, which AI Gateway provides without you managing keys for three different providers.

On Netlify these arrive as first-party primitives, meaning they are part of the platform and already understand each other rather than being separate services you sign up for and wire together. That distinction matters more than it sounds: it is the difference between adding a database being a decision and being a procurement exercise.

The words people use, translated

Most of the confusion here is vocabulary rather than concept, so here is the short glossary in the order you will meet the terms.

Repository, or repo, is the folder your code lives in, with a history of every change. Having one matters because it is what makes your app a normal piece of software somebody can pick up later.

Build is the translation step. Deploy is putting the result live. Those two get used interchangeably and are not the same: you can have a successful build and a deploy that never happens.

Environment means a running copy of your app. Production is the one real people use. A preview is a separate copy for checking a change before it reaches production.

Rollback is going back to the previous version. Ask how long it takes wherever you are hosting, because the answers vary enormously.

Server is any computer that answers requests. Serverless does not mean there is no server; it means you never think about one, because the platform starts and stops them for you.

None of these are difficult ideas. They are just words that got used around you before anyone defined them.

Where the app physically runs

One more piece, because it explains a thing people notice without understanding.

Your app does not run on one computer in one city. It is copied to many machines in many places, and whichever is nearest to a given visitor is the one that answers them. That is what a CDN is, and what Netlify Edge refers to.

The reason is distance. Data moves fast but not instantly, and a request crossing an ocean and back adds delay a person can feel. Serving from nearby is the single largest thing you can do about speed, and it happens without you arranging it.

It also absorbs surges. When the whole team opens your tool at nine on Monday, that load spreads across many machines rather than landing on one.

Why nobody patches your app unless someone does

The last thing to understand about hosting is that it is not finished when the deploy is.

Software sits on other software: a runtime, libraries, a certificate, an operating system. All of that ages. Vulnerabilities are discovered, versions stop being supported, certificates expire. None of it is visible from outside, and none of it announces itself until the day it does.

Somebody has to attend to that. When people say a platform is managed, this is the part they mean: the maintenance underneath is somebody’s job, and not yours. For an app built by a person whose actual job is something else entirely, this is probably the single biggest factor in whether it is still working in a year.

Netlify has been doing this for over a decade, across more than 60 million apps deployed and over 17 million users, at 99.99% uptime, with SOC 2 compliance underneath. Those numbers are not interesting in themselves. They matter because they describe a thing that has been someone’s full attention for ten years, which is the only way that particular problem gets solved.

”Hosting” is an old word for a bigger job

The word comes from a time when it meant keeping files on a machine that was switched on. That is still in there, and it is now the smallest part.

What you are actually choosing, when you choose where your app lives, is who handles the build, where it runs, what it can do beyond showing pages, how you change it safely, and who is responsible when something ages badly. Which is why the honest answer to “where should I host this?” is rarely about storage and almost always about everything around it.

You do not need to hold all of this in your head. It is worth knowing the shape, though, so that when someone asks where your app is hosted, you know they are asking a bigger question than where the files are.

FAQs

What is AI app hosting? It is the set of services that take the code an AI generated and turn it into an app other people can use: building the code into a browser-ready form, putting that result on the public internet, giving it an address, and then running the parts that are not pages, such as data storage, user login, and code that executes on request. The AI writes the app; hosting is everything that makes it reachable and keeps it working.

What happens after an AI finishes generating my code? Four things, in order. A build translates your files into what a browser can run. A deploy puts that output somewhere public. A domain gives it a readable address, with encryption attached. Then it keeps running, which means data has to persist, code has to execute when called, and somebody has to patch the layer underneath.

Do I need hosting if the AI tool already gives me a URL? That URL is hosting, so in the narrow sense you already have some. The question is what it includes. A generated preview URL is usually fine for showing someone your work, and tends to fall short once you want a custom domain, a real database, user login, or a guarantee that it will still be there in six months.

What is the difference between a build and a deploy? A build turns your source files into the optimized version a browser actually runs. A deploy puts that built output onto the internet. They are separate steps, which is why a build can fail without affecting your live app: the deploy simply never happens and the previous version stays up.

What does it mean that a deploy is atomic? It means the deploy either fully completes or does not happen, so your app is never half old and half new while someone is looking at it. On Netlify deploys are also immutable, so the previous version is kept rather than overwritten, and rolling back to it is one click with no rebuild.

Is hosting just storing files on a server? That is where the word came from and it is now the smallest part of the job. A modern app also needs code that runs on request, a database, file storage, user authentication, encryption, delivery from locations near your users, and ongoing patching of everything underneath. On Netlify those are first-party parts of the platform rather than separate services you assemble.

The shortest way to understand this is to watch it happen once. Point an agent at netlify.new and follow the sequence: files become a build, the build becomes a deploy, the deploy becomes a URL.