How to size a server before a launch
Picking a server before a launch usually means guessing, then either overpaying for months or watching the app fall over on the one day it matters. You can replace the guess with a short test. Here is the order to do it in.
Start from the question, not the server
Pricing pages list vCPUs and gigabytes. Your launch question is different: will the pages people hit stay fast enough when the most people are on them at once?
Write that down as something you can check, for example "sign up stays fast at p95, with no errors, at our expected peak". Everything below turns that sentence into something you have measured instead of hoped for.
Step 1: estimate your peak concurrent users
Daily visitors are the wrong number. What loads a server is how many people are making requests at the same moment.
A rough way to get there: take the visitors you expect in your busiest hour, divide by 3,600 to get arrivals per second, and multiply by how long an average visit lasts in seconds. That gives roughly how many people are on the site at once. It is a first estimate, not a promise.
Not all of those people are loading something at the same instant, because people read between clicks. A simulated user that keeps sending requests is heavier than a real visitor, so a test at your estimate is on the safe side.
Launch traffic is spiky. Most of it arrives in the hours right after a post goes up, so plan for the busiest hour, not the average day.
Step 2: list the pages launch visitors hit
Most launch visitors see the landing page, maybe pricing, then the sign up form. Some try a demo. Very few go deep into the app on day one.
Test those paths, including anything that writes to the database. A landing page that loads fast does not help if creating the account times out.
Step 3: test on the server you plan to buy
Pick a candidate size, run your real container on it with production settings, and point it at a database you are allowed to load. Results do not transfer between machines: a test on your laptop, or on a much bigger box, says little about the one you will deploy on.
Ramp from zero to past your estimated peak, and generate the load from a separate machine in the same region, so you measure the server and not the network in between.
Step 4: read what ran out first
As the users go up, watch p95 latency, the error rate, CPU per core and memory. Find the moment p95 bends upward or errors appear, and look at what was full right then.
One core pinned and the rest idle: the app is single threaded. Run one worker per core before you pay for more cores.
Every core busy: the CPU really is the limit. A bigger server, or less work per request, will help.
Memory near the top: more RAM, fewer workers, or a leak to fix.
Nothing on the server full but latency rising anyway: the limit is outside the app server, usually the database, its connection pool, or an external API you call.
Step 5: fix the cheap things, then test again
Many launch problems are config, not hardware: too few workers, a missing index, a pool that is too small, a page that could be cached. Fix the one the test pointed at and run it again.
One fix often moves the limit far enough that the size you already have is fine. That is worth knowing before you upgrade.
Step 6: pick the size, with headroom
Once a test holds your estimated peak with p95 and errors where you want them, that is your size. Leave some headroom, because your peak is an estimate and launches surprise people in both directions.
If it held easily, consider testing the next size down. Paying every month for a spike that lasts a day is also a cost.
When to do this
A few days before launch, not the night before. You want time to fix what the test finds and run it again.
Doing it with Stresix
Stresix does steps 3 and 4 for you. Point it at a repository or a Docker image, list the requests to send, and it starts your app on a fresh server, ramps simulated users from a second server in the same datacenter, and ends with a report: what ran out first, p95, error rate and a verdict on the server size.
Your first run is free with a GitHub account at least a week old (Lite: 500 users in a 4 minute window on 2 vCPU / 4 GB). The sample reports on the home page show what the report looks like for three real stacks. For which pages to test, see the guide on surviving a launch.
Frequently asked questions
How many concurrent users should I plan for at launch?
Work it out from your own expected traffic: visitors in the busiest hour, divided by 3,600, times the average visit length in seconds. Then test past that number, because the estimate is rough.
Is it cheaper to just buy a big server for launch week?
Sometimes. But if the real limit is a single threaded app or the database, a bigger server does not help, and you only find that out by testing.
Do I need to test every page?
No. Test the few pages launch visitors actually hit, plus anything they write to, like sign up.
Related guides
Stop guessing your specs. Start knowing them.
Point Stresix at a repo or Docker image and get a number you can deploy on, in one run.
Start a load test