Learn Deployment

A beginner’s map of what changes at every stage of scale, which platforms fit where, and what usually breaks first.

Imagine you spent three months building an app.

It works perfectly on your laptop. You are proud of it. You send your friend a link: localhost:3000.

He opens it and sees nothing. Or worse, he sees an error from his own machine.

That moment is where deployment begins.

Deployment is putting your software on a machine that is always on, reachable by other people, and fast enough for the number of people using it.

The first deployment is the easy part. The hard part is knowing what to change as your user count grows, because the right setup for 100 users is the wrong setup for 100,000.

I build agent systems for a living (ReWoo runs on FastAPI and Docker, among other things), so deployment is something I deal with constantly. This article is a map. It follows a long video conversation between developers that walks through five levels of scale, from zero to over a million users. I have added my own notes, and I checked the facts that go stale quickly, like free tiers and platform limits. A few details in the original were garbled or only roughly right, and I will point those out as we go.

There is no code in this article. The goal is to understand the shape of the problem first. Let’s start with why localhost fails.

1. What deployment actually is

localhost means "this machine." When you type localhost:3000, your browser talks to a program running on your own computer, on port 3000.

So when you send that link to a friend, it points to his computer, not yours. Everyone’s localhost:3000 is different.

The fix is simple to say. Instead of keeping the app on your laptop, you run it on another computer that sits on the internet and has a public address. Then anyone can reach it. Putting your product on such a machine is called deployment or hosting.

Two facts follow from this, and they matter for everything else.

That machine is not free. Someone built a data center and is renting you a slice of it. The more RAM, CPU, and storage you ask for, the more you pay.

Traffic often costs money too. Many providers charge for outbound data, called bandwidth or egress. A small mistake, like serving large files from your server, can turn into a surprise bill. Set a budget alert on any cloud account you create.

A small note for the resume. If your portfolio lists localhost:3000 as the project link, a recruiter cannot open it. A live URL, even for a tiny project, says a lot more than a screenshot.

2. Four ways to get a machine

Before the levels, you need to know where your app can live. There are four common options.

A few notes on each.

Your own computer. In theory, a laptop can be a server. You would need a reliable always-on connection (a normal Wi-Fi router is not ideal), a way to keep it powered, and a way to reach it from outside. It is a fun challenge, and the video suggests posting about it if you try. For a real product, it is not a good idea.

PaaS. You connect a repository and the platform builds and runs it. It is the easiest place to start. The video’s team recommends Render for beginners and DigitalOcean for people who want more control later.

IaaS. AWS, GCP, Azure, and Oracle rent you virtual machines and a large ecosystem around them: databases, queues, caches, and more. Azure is common inside large companies. GCP is popular for data and AI work. AWS is the most widely used.

Bare metal. The video mentions a company that reportedly cut a roughly $2,000 monthly bill to around $500 by running its own servers. I could not verify that story, and the savings only exist if you can afford the people who run the hardware. As the video says, you need someone to manage it.

A reality check on free tiers

Free tiers are great for learning. Just know their limits, because they surprise people.

On Render’s free tier, a web service spins down after 15 minutes without traffic, and the next visitor waits about a minute while it wakes up. A free Postgres database expires 30 days after creation, and it has no backups. Render itself says free instances should not be used for production. The video calls Render free “right now,” which is true with those conditions.

Cloudflare Workers is another option the video mentions. Its free plan allows 100,000 requests per day, not in total, along with 10 milliseconds of CPU time per request. The video says you must use Hono with Workers. A more accurate version: Workers run on their own runtime and not on Node, so frameworks built for that environment, like Hono, fit naturally, while Node-first frameworks may need compatibility layers.

The lesson is simple. A free tier can host a demo for your portfolio. It is the wrong place for anything people depend on.

3. Two numbers you need to understand

The levels in this article are based on user counts, and that can mislead people. A thousand users does not mean a thousand people hit your server every second. Two different numbers matter.

Concurrency is how many users are active at the same time. If you say you have 1,000 daily active users, concurrency asks how many of them are using the app right now.

RPS (requests per second) is how many requests actually reach your server each second.

The video offers a planning rule of thumb: RPS is often somewhere around 2% to 5% of your active users. By that rule, 1,000 daily active users means about 20 requests per second. Treat it as a way to get an estimate, not a law. Real traffic depends on the product and, above all, on the peak.

The video gives a good example. For their own platform, peak traffic does not happen when a course launches. It happens during live classes, when everyone shows up at once. A streaming service sees the same thing during a big match. Average numbers hide the moments that break servers.

So when someone gives you a user count, ask three questions. What is the peak? What is the requests-per-second at that peak? And which feature gets hit hardest?

4. The five levels

Here is the whole map before we walk through it. The levels are approximate, and the video says so too. Real scaling depends on concurrency and RPS, not on a headline user number.

Here is a rough sketch of how the architecture grows:

Level 1:  User -> One server (app + database)
Level 2:  User -> One bigger server -> Database
Level 3:  User -> CDN -> Load balancer -> Several servers -> Cache
                                                   -> Primary DB + read replicas
Level 4:  ... plus separate services, a message queue, workers, sharded data
Level 5:  ... plus multiple regions, failover, and constant monitoring

This is a teaching sketch, not a blueprint. Now each level.

Level 1: zero to 1,000 users

At this size, the video estimates around 1 to 20 requests per second. That is not a lot. Almost any modest server can handle it.

The main goal is speed and low cost. Most products at this level are an MVP, a first version that exists to learn whether anyone wants it. A startup that has just raised a small amount of money does not need a perfect architecture. It needs something live quickly, and every dollar spent on idle machines is a dollar not spent on finding customers.

One warning from the video, and it is a good one: do not buy for the future you imagine. It compares this to needing five kilos of flour and buying a 500-kilo sack. Over-provisioning wastes money, and in a company it can cost you your credibility.

What is the bottleneck? At this scale, usually not traffic. The risk is the single point of failure. Everything runs on one machine. If it goes down, everything goes down.

The other risk is your own code. If a single API call hits the database three or four times, or one request triggers a pile of hidden queries, any machine will struggle. A bigger server does not fix badly written code. And if your code gets stuck in an infinite loop, it will hurt even one user.

Level 2: 1,000 to 10,000 users

The video estimates peaks somewhere between 20 and 400 requests per second here. You will likely see higher CPU use, so you may need a machine with more CPU or more memory. That costs more, but it is still the simple setup.

The new problem is the database. With one database and no replicas, it is a single point of failure. And when the database is slow or down, your app looks slow even though the server is fine. Watch your database connections, because every database has a limit on how many it accepts at once.

Here is a useful way to think about it. The video notes that a basic Express route returning “hello world” can handle many thousands of requests per second, but once you attach a real database, that number can fall to the hundreds. The exact figures depend on hardware and code, so measure your own. The principle is what matters: your database usually sets the ceiling, not your web framework.

This is also the level where deployment stops being just about code. You start handling images, video, audio, fonts, and caching of files. At this point it helps to store large files in object storage and serve them through a CDN, not from your app server.

On testing, the video prefers concurrency testing: simulate many users at once and watch what happens. I would do two kinds. A load test checks that you can handle the traffic you expect. A stress test pushes until something breaks, so you know where the limit is before your users do.

Level 3: 10,000 to 100,000 users

This is where the architecture visibly changes.

You put a load balancer in front of several servers. Users hit the load balancer, and it decides which server gets each request. To make that work, your servers need to be stateless, meaning no server keeps important user data in its own memory, so any server can handle any request. (If this term is new, the twelve-factor app is a good place to read about it.)

Now the database becomes the wall. You can add as many servers as you like, but they all talk to the same database, and its connection pool is limited. More servers can actually make the problem worse.

The standard answer has two parts.

Database replicas. One database, the primary, handles writes. Other copies, the replicas, handle reads. Most apps read far more than they write, so this takes a lot of load off the primary.

Caching. Store frequently needed data in fast memory so you do not hit the database each time. In-memory caching on one server is fine at first, but with several servers you want a shared cache like Redis, so every server sees the same data. At this size, many teams use a managed Redis service from their cloud provider instead of running it themselves. A CDN also helps by serving static files from locations close to the user.

This is also the level where cloud providers make sense. You need caches, queues, and different types of servers, and AWS or GCP gives you that ecosystem in one place. For cheaper compute, there are spot instances, but they can be taken away at short notice, so they suit work that can be interrupted.

A note on auto scaling. When traffic spikes, an auto scaling group adds servers. That helps with web servers. It does not help your database, which still has a limited number of connections. This is one of the most common surprises at this level.

And indexes. The video makes a point I want to repeat: if a query has to scan thousands of rows to find one, every request will be slow. Make sure your database has proper indexes before you look for bigger servers.

Level 4: 100,000 to 1 million users

The video says this is where real engineering begins, and I agree.

Get Adil Shamim’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

At this size, one part of your app may start to cost far more than the rest. The video’s example is a payment service that eats a lot of CPU. Instead of scaling everything to serve one hungry feature, you split it out into its own service, with its own database and its own load balancer, and have the main app call it. The video calls this a distributed monolith: you pull out one or two services but do not break everything into dozens of microservices.

Two terms come up here.

Vertical scaling means making one machine bigger: more RAM, more CPU. Horizontal scaling means adding more machines.

And the database changes shape again.

Replication vs. sharding. Replication makes copies of the same data. Sharding splits one database into parts, so half the data lives in one place and half in another. Sharding lets you handle more data and more writes, but it makes queries harder, because you now have to bring pieces back together.

That brings in the CAP theorem. It says that when a network partition happens in a distributed system, you have to choose between consistency (every reader sees the same, latest data) and availability (the system keeps answering). The right choice depends on the product. In a banking app, showing the wrong balance is unacceptable, so you favor consistency. In a social feed, a slightly stale post is fine.

Two more tools show up at this level.

• Message brokers carry messages between services.
• Workers pick up those messages and do slow work in the background.

The benefit is that a user does not wait for slow tasks. A request can add a job to a queue and return right away. That is the move from synchronous to asynchronous. There is no fixed moment when you must switch. You watch where requests are blocking and move those parts to the background.

The video also describes separating the write path from the read path, like a service that handles posting and a different one that handles fetching. That can help when reads and writes have very different loads.

What is the bottleneck here? Keeping data consistent while the system is split up. Even a small sync error can leave you with wrong data, and the extra hops add latency. The cost is also in people: more services means more things to monitor, deploy, and debug.

Level 5: over 1 million users

Now traffic is global and unpredictable.

The video gives a clear example of latency. If your app is hosted in India and a user opens it in Japan, every request has to travel across the world, and a round trip can add roughly 150 to 200 milliseconds. Routing can also take indirect paths you do not expect. The fix is to bring the content closer to users with a CDN, edge locations, or deployments in multiple regions.

A correction on terminology, because the video mixes this up. AWS regions are separate geographic areas, such as Mumbai (ap-south-1) and Hyderabad (ap-south-2). Each region has several availability zones, which are isolated data centers inside it. Spreading across zones protects you from one data center failing. Spreading across regions protects you from a whole area going down. You can read how this works on AWS's infrastructure page.

The video says tools like Kubernetes and Kafka become a must at this level. I would soften that. They are very common at this scale, and for good reasons: Kubernetes for running many services, Kafka for streaming data. But they are not mandatory, and many teams use other tools. The point is that you need some way to orchestrate services and move events reliably.

The video also mentions CockroachDB, a distributed SQL database built to survive failures of nodes and even whole data centers. That is true when you configure replication to match the failures you want to survive. Do not read it as a guarantee that nothing can ever happen to your data.

The most important idea at this level is how you think about failure.

At very large scale, something is always failing. Design so the system keeps serving users when parts of it break.

The video describes the daily reality: a queue fills up, a machine runs out of space, a cloud provider has an outage. Your job is to build patterns so a failed service does not take down the rest. Teams use ideas like timeouts, retries with backoff, and falling back to a simpler experience when a dependency is down. And you need monitoring that tells you what broke before your users do.

A reality check from the video itself: most developers will never build level five. As the speakers say, you may spend your whole career at level two or three. They suggest learning about the higher levels anyway, and reading case studies once you have worked at scale for a year or two. I agree. Knowing what exists makes you better at the level you are on.

5. Five questions to ask at every level

The levels are a way to teach. The questions are what you use at work.

1. How many users, and what is the peak requests per second? Estimate, then measure.
2. What does this cost, including bandwidth? Set a budget and an alert.
3. What is the single point of failure? If one thing dies, what happens?
4. Where is the bottleneck? It is often the database, but check, do not guess.
5. How will I know when something breaks? Logs, metrics, health checks, and alerts.

6. Common beginner mistakes

• Listing localhost as a project link.
• Buying a large machine on day one because you are “planning to scale.”
• Leaving a cloud account with no budget alert.
• Using a free database for something you cannot afford to lose, with no backups.
• Looking for a bigger server when the real problem is a missing database index or a query that runs many times per request.
• Choosing tools because they are popular, not because you have the problem they solve.
• Deploying with no way to see errors.

7. A note on AI and deployment

The speakers in the video make a point I find fair. AI tools make it much easier to write code, and this is a great time to learn. But if you build something without knowing the basics, you will struggle when it comes to deploying it, and you will waste a lot of effort asking an AI to fix problems you cannot describe.

My own view is that AI is excellent at the typing and the setup, and weaker at knowing what your situation needs. If you can tell it your expected users, your budget, and your constraints, you will get far better answers. Deployment is where precise questions pay off most.

8. How I would learn this, step by step

Here is a sequence I would follow, from first deployment to a real setup. Each step is small enough to finish in a weekend.

Step 1: Run your app in a container locally

Package your app with Docker so it runs the same way on any machine. This removes the “works on my laptop” problem before you even deploy.

Step 2: Deploy to a PaaS with a managed database

Use Render, Railway, Vercel, or similar. Connect a repository, add environment variables, and get a live URL. Remember the free-tier limits above, and do not treat a free database as permanent.

Step 3: Add a domain, HTTPS, and secrets

Point a domain at your app, make sure it uses HTTPS, and keep passwords and API keys out of your code. This is the difference between a demo and something you can share.

Step 4: Add visibility

Add logging, a health-check endpoint, and an uptime monitor. If you cannot see a failure, you cannot fix it.

Step 5: Load test it

Use a load testing tool such as k6 or Locust to simulate traffic. Watch CPU, memory, and database connections. Find the point where it starts to slow down.

Step 6: Move to a VPS and set it up yourself

Rent a small virtual server and deploy the same app with Docker and a reverse proxy like Nginx. You will learn more in one weekend here than from a month of reading.

Step 7: Automate deployment

Use GitHub Actions to run your tests and deploy when you push code. Once this works, deploying becomes boring, which is exactly what you want.

Step 8: Try a major cloud

Deploy the same app on AWS or GCP using their free credits. Add a managed database and a cache, and set a budget alert before you do anything else.

The final mental model

Deployment is not one step. It is a series of choices, and the right choice depends on your level.

At a small scale, pick the simplest thing that works, keep costs low, and ship. As traffic grows, find the next bottleneck before it finds you. Usually that is the database, then the single point of failure, then the complexity of keeping everything consistent.

Do not build for level five on day one. Build for the level you are on, and know what the next one looks like.

So here is my question for you. What is the one project you have only ever run on localhost? Tell me what it is. I would like to know what is stopping you from putting it online.

Sources and references

1. Render. Free tier documentation. Spin-down behavior, free Postgres expiry, and the note against production use.
2. Cloudflare. Workers pricing and limits. Free plan request and CPU limits.
3. Amazon Web Services. Regions and availability zones. How regions and zones differ.
4. Adam Wiggins. The twelve-factor app. Background on stateless processes.
5. CAP theorem. Overview of the consistency and availability trade-off.
6. The video conversation this article is based on: a developer walkthrough of deployment at five levels of scale. Its user ranges, rules of thumb, and company anecdotes are the speakers’ own estimates and I could not verify them.