How can a solo founder host many small products?
Everything I run — every course platform, every AI tool, every calculator, every dead experiment still technically online — lives on one rented VPS. Eighteen CPU cores, ninety-four gigabytes of RAM, a fat SSD, Ubuntu. It costs about as much per month as a nice dinner for two. On it: roughly fifty Node and Python applications, a handful of Postgres and MariaDB databases, a mail stack, and the process manager that keeps the whole circus upright. There is no Kubernetes. There is no auto-scaling group. There is no staging environment for most properties. There is one machine, and it is enough.
The case for one machine
The standard architecture advice assumes you are building one product that might get big. My situation inverts every assumption: I am building fifty products, each of which is almost certainly going to stay small. A property doing a few thousand visits a month uses a rounding error of this machine's capacity. Fifty rounding errors still round to almost nothing.…
PM2: the fleet manager
Every application runs under PM2, the Node process manager. pm2 status shows me the entire portfolio in one table: name, uptime, memory, restarts. That table is the closest thing this operation has to a company dashboard. An app crashed overnight? The restart counter tells me. Something leaking memory? The RSS column tells me. The whole fleet, one screen.
Cloudflare Tunnel: no open ports
The server exposes no web ports to the internet. No 80, no 443. Instead, a Cloudflare Tunnel runs on the box and dials out to Cloudflare's edge; each domain maps through the tunnel to a local port. The benefits compound nicely for a one-person shop. The server's address is unguessable and unscannable — an entire genre of attack just doesn't apply.…
Standalone projects, not a monorepo
Here is my most heterodox choice: every domain is a fully standalone project. No monorepo, no shared component library, no internal framework, and — engineers, brace yourselves — mostly no git. Each folder under /srv/apps is its own universe with its own dependencies, its own database, its own destiny.
Boring wins
Nothing in this chapter is impressive, and that is the entire point. A VPS, a process manager, a tunnel, a folder convention. Every component is a decade old or older in spirit, learnable in an afternoon, debuggable with tools from 1995. I have watched solo builders spend their first three months on infrastructure that Google would find adequate, for a product with zero users.…