How to estimate what a Laravel app costs on serverless

"What will it cost?" is the first question about serverless, and the hardest to answer up front. A server has a price per month. A serverless app has a price per second of use, and nobody knows the use of an app before it runs.

This post explains how the bill of a serverless Laravel app on Scaleway and bunny.net is put together, which line usually decides it, and how to estimate it from your own figures. It uses no example invoices and no "our app costs X". The only prices in it are the Scaleway database list prices Brewless's own estimates use, and those change: check Scaleway's pricing before you rely on them.

How is a serverless Laravel app billed?#

A serverless Laravel app is billed for what runs, while it runs: the vCPU and memory of each container instance for the time it is up, plus storage, data transfer and the services around it. When the web container is scaled to zero, it costs nothing for that time. The database is the exception that often decides the total: a managed node is billed all month, a serverless one only while it is awake.

With Brewless, all of this is billed to you directly by Scaleway and bunny.net, at their list prices, on your own accounts. Brewless's own plan is a separate, fixed amount and adds nothing on top of the cloud bill.

The lines of the bill#

The containers scale by themselves between the min and max you set. Several instances at once each cost their own time, so a busy hour with three replicas costs three times one.

The database decides most bills#

Scaleway has two kinds of PostgreSQL database, priced in opposite ways:

The list prices Brewless's estimates use, before tax:

A serverless database never has less than one vCPU while it is awake. Over a month of 730 hours, that gives:

• db-dev-s running all month: 730 × €0.0156 ≈ €11.39, plus storage.
• A serverless database awake all month at one vCPU: 730 × €0.13752 ≈ €100.39, plus storage.

So, leaving storage aside, the serverless database is the cheaper one only while it is awake less than about 11% of the month, roughly 83 hours. Above that, the smallest managed node wins. A serverless database that scales above one vCPU moves that point further down.

Warning

A serverless database falls asleep five minutes after its last query. A scheduler or queue worker that runs every minute keeps it awake all month, also when there are no visitors. For such an environment a managed node is almost always the cheaper choice.

That is why where your jobs wait matters. With jobs in the database, a trigger calls the worker every minute to look for them, and the database never sleeps. With jobs on Scaleway Queues, the queue calls the worker when a job arrives, and crons call it only when a scheduled task is due. See Queues and schedule.

How to estimate it#

You need hours, not guesses. Work through it per environment.

1. The web container. Take the hours it runs in a month. With web.min: 1, that is at least 730 hours for one replica. With web.min: 0, it is the hours with traffic, plus the time an instance stays up after the last request. Multiply by your container's vCPU and memory, and by Scaleway's prices for those.

2. The worker. With Scaleway Queues it runs when jobs arrive and when tasks are due; with jobs in the database it is called every minute. Estimate how long each run takes.

3. The database. Pick the kind. For a managed node, it is the node price times 730, plus storage. For a serverless database, it is the hours awake times the vCPUs times the vCPU hour price, plus storage. The hours awake are at least the hours any container that uses it ran, plus five minutes after each.

4. Storage and delivery. GB in Object Storage, GB delivered by bunny.net, and the images in the registry. For most apps these are small next to the database, but a site with large downloads is the exception.

5. Brewless. A fixed plan amount, the same whatever the use.

Tip

Estimate staging separately. With web.min: 0, a serverless database and nothing that runs every minute, an environment nobody uses costs little more than its storage.

What Brewless records for you#

An estimate made before launch is a guess. After launch, Brewless gives you the hours from your own app, counted from Scaleway's figures. It never sends a request to your app to measure it, because a health check would keep the container awake.

Per container. Once an hour Brewless reads from Scaleway, per minute, whether the web container had an instance, and keeps the hourly totals: how long it ran, how long it was scaled to zero, and how often it went from zero to running. The page of an environment shows these for 24 hours up to 12 months. Several instances at the same time count as one minute of runtime, so this figure tells you how much of the time anything ran, not the total instance time. See Scaling.

Per serverless database. Per hour: how long it was up and asleep, the vCPU time it was given, the most vCPUs it had, how often it woke, and its size. The Databases page shows the cost of each database at list price, and Download the hours as CSV gives a line per hour, with the cost in euro cents, for your own spreadsheet. See Databases.

The database advice. For every database, the console shows what it costs as it is and what the other kind would cost, the share of the month above which the managed node wins, and which is cheaper. You can move the share to see what a change would do, such as running the scheduler less often. Brewless only advises; it never moves a database from one kind to the other. See Database costs.

Note

These are estimates from list prices, before tax. Your bill can differ by Scaleway's own metering and rounding. Scaleway keeps its own figures for about a month; Brewless keeps the hourly totals, so you can look back further.

Summary#

1. Containers cost vCPU and memory while they run, and nothing while scaled to zero.
2. The database usually decides the bill: a managed node all month, or serverless compute while awake.
3. Anything that runs every minute keeps a serverless database awake; use Scaleway Queues or a managed node.
4. Estimate from hours: container hours, database hours, then storage and delivery.
5. After launch, replace the estimate with the hours Brewless recorded from your own app.

Keeping one replica running removes cold starts and adds a full month of container time. Laravel cold starts on serverless helps you decide whether that is worth it.