The One-Mac-Three-Domains Pattern
A single Next.js codebase serves multiple independent public websites from one Mac, routed by HTTP host header and exposed through one Cloudflare tunnel. Each domain is a tenant; the machine is the whole datacenter.
The pattern
One-Mac-Three-Domains is a multi-tenant hosting pattern in which several unrelated public websites are served from a single physical Mac, sharing one codebase, and distinguished only by the HTTP `Host` header of the incoming request. There is no VPS, no cloud hosting account, and no per-site server. The Mac is the entire production environment.
In the reference deployment, three domains — dajai.io, hellcatblondie.io, and sovereignagiasi.com — are all the same Next.js application. Each renders a completely different brand and content set, decided at request time by reading which host the visitor asked for.
How routing works
The mechanism is deliberately simple, which is what makes it durable. Three layers cooperate:
- Cloudflare tunnel receives traffic for all three apex domains plus their subdomains and forwards each to a local port on the Mac (the routing rules live in the tunnel's
config.yml). - A process per tenant, each a separate launchd job binding a distinct local port — for example
dajai.io → :3002,hellcatblondie.io → :3001,sovereignagiasi.com → :3003. - The application reads the `Host` header and selects the brand: theme, content, navigation, and SEO metadata all branch on the hostname.
A visitor to any of the three sees a fully independent website; under the hood it is one program answering on three ports, behind one tunnel, on one machine.
Why one codebase, many tenants
The payoff is operational leverage. A single git push and rebuild ships fixes to all three brands at once. Shared infrastructure — the blog engine, the search index, the asset pipeline, the SEO and sitemap logic — is written once and inherited by every tenant. Brand-routing heuristics can even classify shared content (by tag or topic) so a single article surfaces on whichever domain it is most relevant to.
This is the inverse of running three separate sites: instead of triplicating effort and infrastructure, you triplicate output from one well-maintained base. The cost of adding a fourth domain is mostly a port, a launchd job, a tunnel rule, and a branch in the host switch.
Process supervision and limits
On macOS the supervisor of choice is launchd: each tenant runs as a labeled launchd job (e.g. io.dajai.nextjs, io.hellcatblondie.nextjs, io.sovereignagiasi.nextjs) that starts on boot and is restarted if it dies. A separate monitoring job can periodically probe each public URL and alert on unreachable hosts, HTTP 4xx/5xx, or expiring TLS.
The honest limits of the pattern: everything shares one machine's CPU, memory, and uplink, so a traffic spike or a runaway build on one tenant can affect the others, and the Mac is a single point of failure with no automatic failover. It is the right pattern for a portfolio of small-to-moderate-traffic sites under one operator — and the wrong one for anything that needs independent scaling or a hard blast-radius boundary between sites.