Where a back end runs

The music shop's back end is written. Now it has to run somewhere, on a computer that stays online day and night. There are four common ways to do that, and the useful question for each one is: what's left for us to manage?

On a server of your own, everything above the machine is yours. On a platform, the provider runs your code, and can look after the database and its backups too. With serverless functions, small pieces of code run only when something calls them, and the database is another service you choose. A back end as a service gives you a ready-made database, logins and file storage.

Whatever you choose, your own code and your rules stay yours to look after. And the trade is always the same: the less you manage, the faster you can start, and the more you depend on the provider. The lesson What keeps running lists everything that must keep working once the site is live.

The first way is to rent a server of your own. Usually it's a virtual server, or VPS: a share of a powerful machine in a provider's data centre, such as OVHcloud, Hetzner or Scaleway. OVHcloud's smallest one costs about €5 a month in 2026. Some companies use their own servers, in their own building.

You install everything on it: the system, the language, the database and the back end. Then the work starts, and it never stops. Every month, someone installs the security updates, makes backups, keeps them somewhere else and checks that they can be restored. Someone watches that the back end is running, restarts it when it stops, at 3 a.m. too, and makes the machine bigger when the shop grows.

In exchange, you control everything: any language, any tool, any setting. And the same setup can move to any other server, so you depend on no one. It fits a team with someone whose job includes this work, or a maintenance contract that covers it. A server that nobody updates becomes a security hole.

The second way is a platform, such as Render or Heroku, or in France Scalingo and Clever Cloud. You send it your code, and the platform installs it, runs it and restarts it when it crashes. It keeps the system updated and can add machines when traffic grows. Most platforms also offer a database as an option, often with its backups. You still look after your own code and the tools it uses.

You pay for each running piece, every month, according to its size. On Render and on Heroku, a small piece that never sleeps starts at $7 a month in 2026. Free plans exist, with limits: Render's free service goes to sleep after 15 minutes without visitors and takes about a minute to wake up. The lesson Free plans and pay-per-use explains what those limits mean.

A platform costs more than a server of the same size. It costs far less than the hours of work it saves. And if your back end uses a standard language and a standard database, moving to another platform later is usually not hard.

The third way is serverless functions, such as AWS Lambda, Google Cloud Functions, or the functions that Vercel and Netlify offer. There is still a server, but you never see it. You write a small piece of code for one job, and the provider starts it each time something calls it, then stops it. If a thousand calls arrive at once, a thousand copies run.

For the music shop, a function could resize each product photo when a member of staff uploads it. Nothing runs, and nothing is paid, for the rest of the day.

You pay for each call and for each second of work. At AWS Lambda in 2026, the first million calls each month are free, then each million costs $0.20, plus the time each call takes. When nobody calls, the bill is zero.

Functions have limits. Each run stops after a time limit: 15 minutes at AWS Lambda. After a quiet period, the first call waits a moment while the code starts. And a function keeps nothing between two calls, so the data lives in another service, such as a database.

The fourth way is a back end as a service, such as Firebase, run by Google, or Supabase. You rent a ready-made back end: a database, logins, file storage, and often functions too. For the music shop, a small loyalty app with accounts and points could be online in days.

There is a catch. The app talks to the database directly, with no route of yours in between, so the access rules you write are the only protection. The lesson Public and secret shows what happens when they're left open.

The price starts at zero, up to a limit, then grows with each read, write and stored file. In 2026, Firestore, Firebase's database, gives 50,000 free reads a day, then charges $0.03 for each 100,000 reads in its US region. Supabase is free up to a 500 MB database, and its Pro plan starts at $25 a month.

It's the quickest start, and often the hardest to leave. Firebase's database is Google's own, so moving away means rewriting much of the app. Supabase is built on PostgreSQL, a standard database, which is easier to take elsewhere.

Each way of running a back end has its own kind of bill, and the bills grow differently as the shop gets more customers.

A server of your own has the lowest bill, and it grows in steps when you need a bigger machine. But all the work stays yours, every month, so count those hours too. A platform costs more, also in steps, and does most of that work for you.

Functions cost almost nothing at first, then a little more with each call. For work that runs rarely or in bursts, that's very cheap. For steady, heavy traffic all day, it adds up. A back end as a service is free up to a limit, then charges for each read and write. Each one costs almost nothing, but a busy app makes millions of them.

So the lines cross: the cheapest option for a hundred customers isn't always the cheapest for a hundred thousand. Estimate the cost at the scale you hope for, as the lesson Free plans and pay-per-use shows, and count people's time as well as the bill.

Whoever proposes a way to run your back end should be able to answer these questions.

Ask who installs the updates, who watches that it runs, and who restarts it at night. Expect a name or a contract, never "it runs by itself".

Ask what the bill will be with ten times today's users, and with a hundred times. Does it grow in steps or in a line? Is there a spending limit, with an alert?

Ask what it would take to move to another provider: which parts are standard, and which are the provider's own? Ask in which country the servers and the backups are, since the personal data of people in Europe comes with GDPR duties. And check whose name is on the account: it should be the company's, not the freelancer's.