"Unlimited domains on one server" sounds like the kind of thing a hosting company says right before the fine print explains the seventeen ways it isn't true. In this specific case, though, it's an accurate description of a mechanism that's been sitting in the TLS spec for over a decade and costs nothing to use. One VPS, one IP address, one reverse proxy, and genuinely any number of domains, each with its own valid certificate. The part that isn't unlimited is a different resource entirely, and it's worth being upfront about which one before getting into how the domain side works.
How does one IP address serve certificates for multiple domains?
Before SNI existed, a server had exactly one problem: TLS encrypts everything, including the hostname the client is asking for, so a server with one IP and multiple domains had no way to know which certificate to present until after the encrypted handshake was already underway — by which point it was too late to pick correctly. The old workaround was one IP address per HTTPS domain, which is exactly as expensive and unscalable as it sounds. Server Name Indication fixes this by having the client state the hostname it wants in plain text, before encryption starts. The server reads that name, picks the matching certificate, and the rest of the handshake proceeds normally. Every browser and every server built in roughly the last decade supports it without any configuration on your part — it's just how TLS connections work now. Where let's encrypt meets a revenue team, the practical guidance lives with XenGrowth's operator guides.
Once SNI has told the reverse proxy which certificate to present, the same proxy uses the plain old HTTP Host header to decide which app on the box should actually handle the request — the identical mechanism that's routed shared hosting since long before HTTPS was universal. SNI solves the certificate-selection problem; the Host header solves the routing problem. Together, they're the entire mechanism. No exotic networking, no one-IP-per-site requirement, no compromise on security.
What does the actual setup look like?
Point every domain's DNS A record at the same VPS IP address — that's the entire DNS-side setup, repeated once per domain.
Run one reverse proxy on the box — see the comparison of which one actually fits this job — with one routing rule per domain, each rule pointing at a different app or container.
Let the proxy's ACME client (or a companion process) request a Let's Encrypt certificate the first time it sees a domain it doesn't have one for yet, using HTTP-01 validation for ordinary subdomains.
Let the same client handle renewal on its own schedule — Let's Encrypt certificates are valid for 90 days, and any competent ACME client renews well before that window closes.
Add a new domain later by repeating steps one through three for just that domain — nothing about the existing domains or their certificates needs to change.
What are Let's Encrypt's actual rate limits, and do they matter here?
They're real, they're published, and almost nobody running a handful of personal domains will ever come close to them — but "unlimited" is a strong word, so it's worth stating the actual numbers rather than gesturing at "it's basically unlimited." The XenGrowth resource library works through the operations side of this in more operational detail.
Limit | What it governs | Refill rate |
|---|---|---|
50 certificates per registered domain per 7 days | How many certs can be issued for subdomains of one registered domain (example.com and everything under it) | 1 certificate every 202 minutes |
5 certificates per exact identifier set per 7 days | Reissuing a certificate for the exact same set of domain names repeatedly | 1 certificate every 34 hours |
5 authorization failures per identifier per hour | Failed domain-validation attempts, usually from misconfigured DNS or a firewall blocking the challenge | 1 per identifier every 12 minutes |
300 new orders per account per 3 hours | Total certificate requests across every domain on one Let's Encrypt account | 1 order every 36 seconds |
The one that actually bites people isn't the domain limit — it's the failed-validation limit, and it bites specifically because it's the easiest one to hit by accident. A misconfigured DNS record, a firewall blocking port 80 during the HTTP-01 challenge, or a reverse proxy not yet listening on the right port when the ACME client fires will each burn through the 5-per-hour failure allowance fast, and then the fix has to wait an hour whether or not the underlying problem got fixed in the first five minutes. Debugging DNS or firewall issues by repeatedly retrying certificate issuance is the single most common way someone locks themselves out of their own domain for an hour over something trivial.
What actually goes wrong with automated renewal?
The quiet failure mode, not the loud one. A certificate expiring doesn't take an app offline the way a crashed process does — the server keeps running, keeps accepting connections, and keeps responding with a certificate that's now invalid. Nothing in the app's logs looks wrong, because nothing about the app is wrong. The first sign is usually a visitor hitting a full-page browser security warning, or a monitoring check failing on a TLS handshake it wasn't watching closely enough to catch until the expiry actually happened. A renewal failing silently for weeks before anyone notices is a genuinely common outage story, and it's entirely preventable with one thing most setups skip: an alert on certificate expiry date, separate from an alert on whether the app itself is responding, because those two checks catch completely different failures.
Renewal fails silently when the ACME client's cron job stops running and nobody's watching for that specifically
Renewal fails when DNS changes (a domain moves providers, or off Cloudflare's proxy) and the HTTP-01 challenge can no longer reach the box the way it used to
Renewal fails when a firewall rule tightens and accidentally blocks port 80, which HTTP-01 validation depends on even though the site serves everything over 443
None of these show up as "the site is down" — they show up as "the site is up and the certificate is wrong," which most uptime monitors don't check for by default
So where does "unlimited" actually stop?
Not at domain count, and not at Let's Encrypt's rate limits either, for any realistic personal or small-business use. It stops at RAM. Every additional app running on the box — whether it's a Next.js container, a small API, or a static site with its own build process — holds its own share of memory the moment it's running, and a VPS has a fixed amount of it. Domains are essentially free: a DNS record and a routing rule cost nothing measurable. Apps are not free: each one is a real process taking real memory, and that's the ceiling that arrives long before any certificate limit does. If AI agents and marketing automation is the part you are stuck on, XenGrowth on governed AI marketing workflows is the better reference.
Resource | Realistic ceiling on a small VPS | What actually limits it |
|---|---|---|
Domains pointed at the box | Effectively unlimited | DNS record count and reverse proxy rule count — both trivial at any normal scale |
Certificates issued | Governed by Let's Encrypt's published rate limits | 50 per registered domain per week; 300 new orders per account per 3 hours |
Apps actually running | A handful, depending on the box's RAM | Each running process or container holds memory whether or not it's receiving traffic |
Concurrent traffic handled well | Depends on CPU cores and how many processes use them | Single-process apps leave cores idle; see the sizing guide for what actually runs out first |
This is the useful reframe: "how many domains can I host" is close to the wrong question. The right one is "how many separate running applications can this box's RAM support," because that's the number that actually determines how far one VPS goes — the domains riding on top of those apps are close to free either way.
A worked example: adding the fifth domain to the box
Domains one through four are already running: a personal site, a small API, a side project, and a status page, each with its own DNS record pointed at the same VPS IP and its own routing rule in the reverse proxy. Adding a fifth costs exactly one A record and one more rule — the proxy config gets a few more lines, the ACME client requests one more certificate the first time it sees the new hostname, and nothing about the first four domains is touched at all. That request counts against the same Let's Encrypt account's 300-orders-per-3-hours allowance, and it's the only one of these four fifths of the setup anywhere near a real limit, and it's nowhere close — four domains a day for weeks wouldn't dent it.
What actually changes is memory. If the fifth domain is a static site with no server-side process, it costs almost nothing — the reverse proxy is already running, and serving one more set of static files is not a meaningful new load. If it's a fifth Next.js app with its own Node process, that's genuinely another chunk of RAM held for as long as that process runs, whether or not it's receiving traffic right now. This is the one place where "just add another domain" and "just add another app" stop being the same sentence, and it's worth pausing on that distinction every time, not just the first time. XenGrowth on building one SEO and GEO content system covers the AI search, GEO and discovery side of this.
Does DNS propagation time affect any of this?
Only at the very start, and it's a common source of a false "the certificate failed" panic. A freshly created A record can take anywhere from a few minutes to a few hours to propagate globally, depending on the DNS provider and whatever TTL was set on the previous record if one existed. If Let's Encrypt's validation server tries to reach the domain over HTTP-01 before that record has propagated to the resolvers it happens to check, validation fails — not because anything about the certificate setup is wrong, but because the domain genuinely didn't resolve to the right server yet at that exact moment. Retrying five minutes later, once propagation has actually finished, usually just works. Retrying five times in the same minute is how that authorization-failure allowance gets burned for no reason, since the underlying cause hadn't changed between attempts.
Set a short TTL on a domain's DNS record before moving it to a new server, so the old record expires from resolver caches quickly
Wait for propagation to actually finish before triggering certificate issuance — checking a DNS propagation tool is faster than burning a validation-failure retry
If a domain was recently at a different registrar or behind a different proxy, expect propagation to take longer than a domain that's never moved
None of this is specific to any one reverse proxy or ACME client — it's a property of DNS itself, and every setup on this list is equally exposed to it
The domain count was never the limit. It's the one thing on this list that actually is close to free.
Is this actually a good idea, or just a cheap one?
Both, for the specific case of a handful of personal or small-project domains that don't each need dedicated resources or isolation from each other. It's a worse idea the moment one app on the box needs guaranteed resources that another app's traffic spike could otherwise steal — that's a real risk of putting everything on one box, and it's a fair reason to eventually split high-traffic apps onto their own VPS rather than a reason to distrust the SNI-plus-Let's-Encrypt mechanism itself. The mechanism is sound. What's actually being decided, every time another domain gets added to the same box, is whether this app's RAM footprint still leaves enough headroom for everything already running next to it — and that's a much more interesting question than whether the domain count itself is allowed to grow.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.
XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.
Where this work meets go-to-market
The operational playbooks that sit alongside let's encrypt live with XenGrowth's operator guides.
Four questions on virtual hosting and automatic certificates. The mechanism is simpler than it looks, and knowing it tells you exactly what will break at scale.
