Key takeaways

Free tiers are sized for the month-one shape of an app, which is not the shape any app that matters keeps. Comparing free tiers tells you almost nothing about what you will pay.
Four drivers: delivery, compute, data, and AI usage. Delivery is usually the smallest and gets the most attention. AI usage is the one that surprises people and the one that can dominate everything else.
The pricing shape matters more than the rate. Per-seat pricing penalizes exactly the thing you want, which is colleagues getting involved. Netlify ended seat-based pricing in April 2026 and runs metered credit-based pricing instead.
Check prices rather than trusting any article, including this one. Rates and allotments change; this piece deliberately describes structure and sends you to the pricing page for numbers.
The costs that are not on the bill, your time and the rebuild you take on by choosing badly, are usually larger than the bill.

Somebody asked what this will cost to run. You looked at a pricing page, found a free tier that appears to cover you, and are now reasonably suspicious that this is not the whole answer.

It is not, though the reason is not that hosting is secretly expensive. It is that “hosting” is one of four things you are paying for, it is usually the smallest, and the biggest is not on most people’s mental model at all. Here is the structure, so you can work out your own number rather than trusting anyone’s example.

Why free tiers mislead

Free tiers are real and generous and they are sized for a particular shape of application: low traffic, little data, not much computation, and nobody depending on it.

That shape describes your app in month one. It does not describe the app in month twelve, after it has accumulated records, picked up users who open it every morning, and grown a feature that calls a model on every submission. The free tier did not get worse. Your app stopped being the thing the free tier was sized for.

So the useful exercise is not comparing free tiers. It is working out which of the four drivers below will dominate for your app at realistic scale, then checking what that costs. Most of the time one driver accounts for the large majority and the others are rounding.

Driver one: delivery

Serving pages and files to the people using the app. Bandwidth and requests.

This is the one everyone thinks about and it is usually the smallest line for an internal tool. A few dozen people loading an app several times a day moves an amount of data that is, by modern standards, nothing. Delivery becomes significant when you are serving large media or have genuinely public traffic, and for the tools most people build it never does.

Worth knowing what it includes, though: delivery from locations near your users rather than one machine is a cost you are paying for whether or not the line is itemized, and it is the reason the app feels fast to someone in another country.

Driver two: compute

Code that runs when something calls it. The pricing unit is usually invocations plus how long each one takes.

The thing to understand about compute is that it scales with use rather than with users. An app where ten people each trigger a hundred operations a day costs the same as one where a hundred people trigger ten. That is good news for internal tools, which typically have few users and modest activity.

Where it bites is anything that runs on a timer regardless of use, or anything doing heavy work per request. A scheduled job that runs every minute costs the same whether or not anybody needed it that minute, which is worth checking when you wonder why a quiet app is not free.

Netlify Functions is the compute primitive here, and the practical advice is to know which of your operations are expensive rather than assuming they are uniform.

Driver three: data

Two different things that get bundled under one word, and they behave differently.

Storage is what it costs to keep records. It accumulates, it is usually cheap per unit, and it rarely surprises anyone because it grows predictably.

Database compute is what it costs to answer queries, and it behaves like driver two. A database that is idle most of the day costs very little; one that is being queried constantly costs more. Netlify Database is managed Postgres with configurable auto-scale and sleep-on-inactivity settings, which exist precisely because most apps have a usage shape with long quiet periods.

The line people forget is non-production data. Every preview environment with its own database branch is real infrastructure. That is a feature worth paying for, and it is also a reason your bill is not purely a function of production traffic.

Driver four: AI usage, which is the one that surprises people

Here is the line that breaks people’s models, and it is new enough that most cost intuition has not caught up.

If your app calls a model, that call costs money, and it is priced on a completely different scale from everything above. Delivery and compute are fractions of a cent at the volumes most internal tools operate at. A model call is not. An app that does something clever with AI on every submission can easily spend more on model calls than on everything else combined, by a wide margin.

Two things follow. First, if your app has an AI feature, model this driver first, because it probably dominates and the others are noise. Second, the thing to measure is calls per use multiplied by realistic uses, which is a number you can estimate well before you build.

Netlify runs credit-based metered pricing, and the honest caveat that belongs in any discussion of it is that heavy AI usage consumes credits faster than people expect. AI Gateway makes model access simpler by removing key management, and it does not make the underlying calls free. Nothing does.

The shape matters more than the rate

Before comparing numbers, compare structures, because structure determines how the bill behaves as you grow.

Per-seat pricing charges by how many people have access. The problem is not the rate, it is the incentive: it makes you think twice about adding the colleague who should obviously be able to see the tool, which is the opposite of what you want from something built to help a team. Netlify ended seat-based pricing in April 2026, so collaborators do not carry a per-head cost.

Metered pricing charges for what you use. It scales smoothly and the risk is the opposite one: a usage spike becomes a bill spike, so you want visibility and ideally a cap.

Watch for cliffs in either model. A tier structure where crossing a threshold multiplies the bill rather than nudging it is the thing that produces unpleasant surprises, and it is worth knowing where your nearest cliff is.

Check the numbers yourself

This article deliberately contains no prices.

That is not evasion. Rates, tiers, and included allotments change, and an article quoting them is wrong the moment they do, which is worse than one that does not try. The structure above is stable; the numbers are not.

So take your estimate of the four drivers at realistic year-two volume and check it against the current pricing page. If AI usage is one of your drivers, price that separately and first, because it will likely set the total.

The costs that are not on the bill

Three, and together they usually exceed the invoice.

Your time, which is the largest and the least tracked. Hours spent configuring infrastructure, debugging a deploy, or working out why something is slow are real costs, and they are the main thing a managed platform is sold on. Whether that trade is worth it depends on what your hour is worth and how many of them the alternative consumes.

Maintenance. Somebody patches the runtime and renews the certificate, and if that somebody is you, it is a recurring cost that never appears anywhere. If it is nobody, it is a deferred cost with interest.

The rebuild. The expensive outcome is not an overspend, it is choosing somewhere cheap that boxes you in and paying for the migration eighteen months later. Measured against a quarter of rebuilding, the difference between hosting options is usually a rounding error, which is a useful thing to remember while optimizing it.

A sane way to decide

Estimate the four drivers at year-two volume rather than month one. Identify which dominates, because one usually does. If AI usage is in your app, assume it is the dominant one until the arithmetic says otherwise.

Then check that one driver’s cost on the current pricing page, confirm the shape is metered rather than per-seat, find your nearest cliff, and stop optimizing. The remaining difference between credible options is smaller than the cost of getting the structural decisions wrong.

FAQs

What does it cost to host an AI-generated app? It depends on four drivers: delivery, compute, data, and model usage. For a typical internal tool with no AI features, the total is small and often inside a free tier for a long time. Once the app calls a model on each use, that line usually dominates everything else and should be estimated first.

Why isn’t the free tier enough? Free tiers are sized for the month-one shape of an app: low traffic, little data, nobody depending on it. Applications that matter accumulate records, pick up daily users, and grow features that do real work. The tier did not change; the app stopped matching it.

What drives hosting cost the most? For apps without AI features, usually compute, particularly anything running on a schedule regardless of use. For apps with AI features, model calls, which are priced on a completely different scale from delivery or compute and can exceed everything else combined.

Does Netlify charge per user? No. Netlify ended seat-based pricing in April 2026 and runs credit-based metered pricing, so adding colleagues does not carry a per-head cost. The thing to watch under metered pricing is usage spikes, particularly from AI features consuming credits faster than expected.

How do I estimate my costs before building? Work out the shape rather than the number: how many times a day the app gets used, whether anything runs on a timer, how much data accumulates, and critically how many model calls happen per use. Multiply by realistic year-two volume, identify which driver dominates, and check that one against the current pricing page.

Are preview environments charged separately? They are real infrastructure, so a preview with its own database branch does consume resources. That is worth knowing when your bill does not track production traffic exactly, and it is generally a feature worth paying for, since the alternative is testing against real records.

Estimate your four drivers at year-two volume, check the dominant one against current pricing, and stop optimizing there. If you want a baseline to measure against, start something at netlify.new.