How to Host Multiple Websites on One Server

Putting several websites on one Linux server is one of the few decisions in hosting that is nearly always correct. A small brochure site uses a few megabytes of RAM while it is idle, which is most of the time, and paying for a dedicated machine per site means paying for idle capacity over and over. The mechanism has been standard for twenty five years, it is well supported, and the failure modes are predictable once you know what they are.

What follows is the practical version: how the routing works, how to size the box, how to keep the sites from interfering with each other, and the point at which consolidating further stops being a good idea.

How name based virtual hosting works

Every domain you host points its DNS A record at the same server IP address. When a browser asks for one of those sites, the request carries a Host header naming the domain it wants. The web server reads that header, matches it against its configured sites, and serves the matching document root. HTTP/1.1 made the Host header mandatory in 1997, which is what made this possible at all.

In Nginx, each site is a server block with its own server_name and root:

server {
    listen 443 ssl;
    server_name clientone.com www.clientone.com;
    root /var/www/clientone/current/public;
    ssl_certificate     /etc/letsencrypt/live/clientone.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/clientone.com/privkey.pem;
}

server {
    listen 443 ssl;
    server_name clienttwo.org;
    root /var/www/clienttwo/current/public;
    ssl_certificate     /etc/letsencrypt/live/clienttwo.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/clienttwo.org/privkey.pem;
}

Apache does the same thing with <VirtualHost> blocks and a ServerName directive. Either way, the number of sites you can define is unbounded. Adding the fiftieth site is the same operation as adding the second.

One detail catches people out: define a default server block that returns a 444 or a 404 for hostnames you do not recognize. Without one, the first block in the configuration answers every unmatched request, so a stranger who points their domain at your IP gets one of your client sites served under their name.

Do I need a separate IP address for each website?

No. One IP address serves every site on the box. This used to be different for HTTPS, because the server had to choose a certificate before it could read the encrypted Host header. Server Name Indication solved that by sending the hostname in the clear during the TLS handshake, and every browser in use today supports it. Dedicated IPs per site are now a legacy requirement, not a technical one.

You still need a certificate covering each hostname. Two approaches both work:

Whichever you choose, automate renewal and alert on failure. On a single site server an expired certificate is an incident. On a server hosting fifteen sites it is fifteen incidents in the same hour, and it is the most common way a consolidated server has a genuinely bad day.

How many websites can one server handle?

Domain count is not the constraint. Memory is, and after memory it is CPU during traffic spikes and disk during backups.

The dominant cost on a PHP stack is the FPM worker pool. Each worker is a full PHP process holding the application in memory, typically 30 to 80 MB for a WordPress or Laravel site, more if the application is heavy. Ten sites with five workers each is fifty processes, and at 60 MB apiece that is 3 GB before you have counted MySQL, Redis or the operating system.

Treat those as starting points, not promises. One site doing real traffic will use more than twenty sites doing none. The number that actually matters is your steady state memory use with a margin left for deploys, because a build step is often the largest single memory consumer on the machine and it runs at the worst moment.

Keeping one site from taking down the rest

This is the real objection to consolidation and it is a fair one. A single busy or broken site can starve the others. Four measures remove most of that risk.

Give every site its own PHP FPM pool. A shared pool means one slow site can occupy every worker while the others queue behind it. Separate pools with per pool pm.max_children caps the damage to the site causing it. This is the single highest value change on a multi site server.

Run each site as its own system user. Separate users and document roots stop a compromised WordPress plugin on one site from reading configuration files, and database credentials, belonging to another. Give each application its own database and a database user scoped to it alone.

Rotate logs and cap disk use. A full disk takes down every site simultaneously and is entirely preventable. Configure logrotate for each site's access and error logs, and keep backups on object storage rather than on the server.

Deploy atomically. Uploading files into a live document root means a half deployed site is a broken site, and on a shared server that broken site is still consuming workers. Building each release in a new directory, health checking it, and only then switching a symlink means a failed build never reaches visitors, and rollback is a symlink flip rather than a restore. That pattern is the reason zero downtime deployment matters more, not less, once several sites share a machine.

The practical setup, in order

The sequence below is what a working multi site server looks like from a clean VPS. A web hosting control panel does all of it through a form, but the underlying steps are the same either way and it helps to know what is being done on your behalf.

1. Size and provision the server. Pick RAM from the table above with headroom for builds. Ubuntu LTS is the safe default.
2. Harden the basics first. Key only SSH, a firewall that allows 22, 80 and 443 and nothing else, unattended security upgrades, and a non root user. The production server setup checklist covers the full list.
3. Install the stack once. Nginx, PHP with the extensions your applications need, MySQL or PostgreSQL, and Redis if you use it. All sites share these.
4. Create a user, directory and FPM pool per site. This is the part people skip and later regret.
5. Point DNS, then issue certificates. Let's Encrypt validates over HTTP, so the A record has to resolve first. Certificates issued before DNS propagates simply fail.
6. Create one database and one scoped database user per application.
7. Wire up deploys from Git. One repository per site, an atomic release directory, a health check before the switch.
8. Add monitoring and backups before you add the second site, not after the tenth.

Does hosting several sites together affect SEO?

Sharing an IP address with your own other websites does not carry a ranking penalty. Google has been explicit that shared hosting is normal and that IP address is not a ranking factor in itself. The genuine risk is indirect: an undersized server makes every site on it slower, and server response time feeds into Core Web Vitals and into how much of your site gets crawled in a given window.

So the SEO question is really a capacity question. Measure time to first byte before and after you add sites. If it climbs, the fix is more RAM or a second server, not a change in hosting philosophy. It is worth tracking that alongside the on page work, since site speed is one of the few ranking factors you can measure and fix directly rather than argue about.

One caveat that does apply: if you are hosting sites you do not control, on a cheap shared IP with unknown neighbours, reputation problems are real for email deliverability even though they are not for rankings. That is a mail concern rather than a search one, and it is solved with correct SPF, DKIM and DMARC records plus a clean PTR.

When to stop consolidating

Consolidation is not free, and there are four situations where a second server is the right answer.

Notice that raw capacity is only one of the four. The other three are about risk, and they arrive earlier than most people expect. The usual mature setup is not one giant server, and not one server per site, but a small number of servers grouped by blast radius: production apps that earn money on one, client brochure sites on another, staging and internal tools on a third.

What this costs

Hardware maths favours consolidation heavily. Ten small sites on a single 4 GB DigitalOcean droplet is $24 a month. Ten separate 1 GB droplets is $60 a month, and each one still needs patching, certificates and monitoring.

Licensing can reverse that. If your control panel charges by hosting account or by domain, the licence grows with exactly the thing you were consolidating to save on. cPanel Solo is $29.99 a month for one account and Premier is $69.99 for up to a hundred, then $0.49 for each additional account. Plesk meters domains, with tiers at 10 and 30 before the unlimited plan. DirectAdmin Standard is $29 a month for unlimited accounts, which makes it the cheapest of the three once you pass a handful of sites. Those figures were read off the vendors' own pricing pages in August 2026.

So the honest sum is server cost plus licence cost, compared across the site count you expect to reach rather than the one you have. On a ten site server the panel licence is frequently larger than the machine, which is worth knowing before you assume it is a rounding error. The full breakdown sits on our cPanel pricing and license cost page, and the broader comparison of what each panel meters is on the web hosting control panel page.

The short version

Point every domain at one IP, write one virtual host per site, issue a certificate per hostname, and give each site its own system user, database and PHP FPM pool. Size the server by memory with headroom for builds. Deploy atomically so a broken release never reaches the document root. Split onto a second server when blast radius, compliance or conflicting stacks demand it, not when the domain count reaches an arbitrary number. Done that way, one modest VPS will happily run more websites than most agencies have clients.