← All articles
January 2, 20247 min read

Why Hosting for Millions is Easier than Hosting for Thousands

EngineeringPerformance
Illustration of a person standing on a laptop above a grid of user profile icons
A businessman in a suit holding a glowing cloud icon beside a data screen

Hosting scalable 3D web applications requires a carefully designed infrastructure. In this article, we explain how containerization, Kubernetes, reverse proxy solutions and Infrastructure as Code enable reliable, secure and cost-efficient hosting at scale. Using real estate 3D web applications as an example, we show how these technologies ensure performance, availability and seamless growth without downtime.

Introduction

Web hosting in the cloud is a complex subject. So why is it easier to host for millions of users than for thousands?

Our last article covered the more technical side of how our applications work. Here we explain a few issues related to hosting, laying out the effectiveness of our solutions in detail. Showing this behind-the-scenes side of our work makes the mechanisms behind our applications' success easier to understand.

We will cover containerization, reverse proxy, and IaC - Infrastructure as a Code - the pieces that shed light on managing an application's environment.

Containerization, briefly

Containerization means packaging a single application into a secure so-called 'container' so that whoever enters it cannot change the system. The application is isolated. The field divides into containers and virtual machines.

A virtual machine is an identical copy of an operating system running on a virtual layer, but it runs from scratch: if we picture the system as a pyramid of interdependencies, every floor of that pyramid must run in the virtual machine for it to operate at all.

A container, by contrast, isolates only the highest level of the pyramid - the least burdensome. The operating system remains its foundation, and it stays secure because no one inside the container has access to protected methods, which makes it far more efficient. That efficiency matters: putting only what you need into a container ensures good performance. Anything a particular application requires can go into a container - data volumes, additional applications, virtual environments, programming languages, system tools, libraries, and more. Encapsulate all of it, and you can hand the container to anyone; whatever operating system they run, it holds everything needed to run the app.

Infographic listing six benefits of containerization with icon labels

What is Docker

Docker is an open-source platform that automates the deployment, scaling, and management of applications - in short, a container platform.

Docker logo: a blue whale carrying stacked containers, next to the wordmark
Source: Docker logo, Docker, Inc.

A container packaged with Docker can run on a single machine, launching seamlessly on any individual device that has Docker installed. This is efficient and convenient, and we prefer it because it reduces server costs and simplifies system administration.

How can we quickly scale

Cloud services can be cheap, but a single machine running a single container might scale to only 1,000 users at a time. When traffic spikes - say a new post or a promotion of a service - the container becomes overloaded. The operating system reports that the container is not responding, so either no one can connect to the page, or it loads so slowly that most people give up.

Kubernetes logo: a blue hexagon with a white helm icon and wordmark
Source: Kubernetes logo, The Linux Foundation

To manage a growing number of Docker containers efficiently, we need a tool called Kubernetes. For hosting at the scale of "millions," it is the best solution. Its equivalent is Docker-Swarm, which we do not use. Kubernetes manages multiple images across multiple machines at once, so we run more than one machine. Between the internet and the containers sits a load balancer (or load-balancing technology) that distributes traffic across them. With one application and three containers, for example, you can handle three times the traffic. We can also spin up additional machines manually and configure Kubernetes to deploy a container on them automatically.

Then there is updating a container. A container serving client traffic has to be switched off and on to update, and that causes downtime - you lose customers and traffic to the site. The downtime might be a few seconds or a few minutes, either way detrimental to the application. With three machines, we can turn one off and on in a moment while the other two keep running, updating them sequentially. As a result, there is no downtime.

We could build such a container for our customers to host themselves. But to keep the quality of our solution as high as possible, it is far easier to host it ourselves, which gives customers the peace of mind and security that come with hosting.

Example of the situation

Say three machines serve ten customers whose traffic could run much higher. Three machines for ten customers, versus one machine per customer, is already the more cost-effective arrangement. And if one of those customers suddenly gets increased traffic, we can scale up easily and quickly, because we keep more computing power in reserve.

Reverse proxy

A reverse proxy secures the aforementioned container against unauthorized access. It protects the container so no one can enter it except as planned - for example, we allow access only via a specific port or the DNS address, i.e., HTTP. This secures the container from being reached over the SSH protocol (Secure Shell), which would let someone log on to the machine and modify its content in developer mode.

On reverse proxies, we should mention Nginx - the open-source web server software we used, which acts as both a reverse proxy and a load balancer. Its operation leads to boosting performance.

NGINX logo: a green hexagon with a white N, next to the wordmark
Source: NGINX logo, F5, Inc.

A URL like URL.google.com is DNS; x.google.com is a subdomain, and a reverse proxy can reroute across subdomains, which means one reverse proxy can act as a load balancer at the same time. It also lets us run clientA.vinode.io and clientB.vinode.io, handling each. We still have three machines, but a set of different DNS addresses for each client separately. The key, then, is keeping our reverse proxy properly configured to route traffic correctly based on addresses.

Infrastructure as a code

A final point answering why it is easier to host at scale is IaC (infrastructure as a code). We use Terraform - an open-source infrastructure as a code software tool.

Terraform logo: a blue parallelogram mark beside the wordmark
Source: Terraform logo, HashiCorp

Take the previous example again: we have three machines and don't know exactly what the traffic will be, but we want to be prepared for any circumstances. If we expect a certain load, we can do a so-called hot start - preparing a machine that waits for the traffic and takes it once it arrives. There is also a cold start: traffic comes in and we reach a threshold, meaning we are about to hit the limit (e.g., there is 30% capacity left on our servers), so we cold-start a new server. Because this is programmed into Terraform, once we reach a certain threshold it communicates with our cloud provider and requests starting a new machine. Terraform will configure this new machine to add it to the set of machines and automatically start it in Kubernetes as a new one. It runs for some time, and if more are needed, they are added as required. When traffic grows quickly like this, we can scale in response to requests.

Terraform also allows you to program for peak traffic: we anticipate no traffic between x and y hours, while other hours carry the heaviest traffic. Then we need a minimum of 5 containers.

Conclusions

We have worked through several critical interlocking issues around hosting. Proper hosting clearly needs a specific infrastructure whose elements build on one another.

When we build a 3D web application for your real estate business, you can rest assured that hosting on our side is carefully looked after, and it plays one of the critical roles in the success of such applications.

You don't have to worry about server management or technical matters like auto-scaling. With Terraform, we can scale whether the traffic is there or not, so we are prepared for any eventuality, and you don't need an entire IT department to manage this infrastructure.

Contact us to discuss opportunities for cooperation, and check out our other articles to get familiar with what we do and how!

FAQ

Why is hosting for millions of users easier than for smaller numbers at scale? Because modern cloud infrastructure is designed to scale horizontally. Adding more containers or machines allows traffic to be distributed efficiently without overloading individual servers.

What is containerization and why is it important? Containerization isolates applications and their dependencies into secure units, ensuring consistency, portability and efficient resource usage across different environments.

How does Kubernetes improve application availability? Kubernetes manages multiple containers across multiple machines, distributes traffic through load balancing and allows updates without downtime by rotating containers sequentially.

What role does a reverse proxy play in hosting? A reverse proxy secures applications by controlling access points, routing traffic based on domains or subdomains and acting as a load balancer to improve performance and reliability.

What is Infrastructure as Code (IaC)? Infrastructure as Code allows infrastructure to be defined and managed through code, enabling automatic scaling, faster deployments and consistent environments.

How does IaC help handle traffic spikes? Tools like Terraform automatically provision new servers when predefined thresholds are reached, ensuring applications remain responsive even during sudden increases in traffic.

Related articles
Core Web Vitals dashboard with INP, CLS metrics and load-time charts
July 14, 2026By Tomasz Juszczak

Core Web Vitals for property sites: how to actually measure a 3D tour's impact

One green desktop Lighthouse run on the tour page is not proof the tour is fine. Lab tools and field data answer different questions, and the metric a 3D tour is most likely to fail — INP — is one Lighthouse cannot score at all. Here is how to read the field data at the 75th percentile, and why a freshly launched development page shows "No Field Data" for weeks.

Performance3D7 min read
Aerial 3D render of a large residential development with palm trees and roads
July 7, 2026By Grzegorz Bukowski

The asset budget is what breaks 3D at 500 units, not your polygon count

Grinding on the model has a hard ceiling at masterplan scale. LOD tiers, a texture memory budget, draw-call limits, and streaming order decide whether a 528-unit scene loads on a buyer's phone. Here is what that budget looks like at 25 buildings, and why no amount of tuning upgrades the device in their hand.

3DPerformance10 min read
A desktop monitor showing a rising blue chart beside a server rack with cooling fans
May 1, 2026By Tomasz Juszczak

The real cost of streaming 3D per viewer: a worked GPU-and-CDN cost study

Two ways to serve an interactive 3D tour, two cost curves that point in opposite directions. This is the arithmetic worked out at dated public rates: what 100, 1,000 and 10,000 concurrent viewers actually cost on a GPU fleet versus a CDN, and the two numbers that decide where the lines cross.

Engineering3D10 min read