The cost of a process
A static site costs nothing to run because it contains no running code. It is a collection of files. A server-rendered application costs money because it requires a process that stays awake, waiting for requests. On a single VPS with 12GB of RAM, that distinction defines the entire operational burden. You are not just paying for disk space; you are paying for the memory and CPU cycles that a Node.js or Next.js process consumes while it sits idle. If a site can be built once and served from disk, it cannot crash at 3am. There is no process to hang, no memory leak to accumulate, and no dependency to update. The file is there, or it is not.
When you need the database
Personalisation and state require a backend. A static site cannot know who is visiting. It cannot store a user’s preferences, validate a login, or query a database for the latest content. This is why
Instalaz runs as its own separate Node process on port 3050. It needs to manage user accounts and schedule jobs. It talks to a shared PostgreSQL 16 database. This architecture buys you functionality that static files simply cannot provide. The trade-off is complexity. You must manage the process lifecycle, handle errors, and ensure the database connection remains stable. Every feature that requires state adds weight to the system.
How the systems compete
On a single box, resources are finite. Processes on one machine compete for memory and CPU. A static build served by Caddy has zero overhead. It does not allocate memory for a runtime. It does not hold open sockets. It is effectively invisible to the operating system until a request arrives. In contrast, the Next.js process that serves four sites by host-based routing must maintain its context. It holds the compiled code in memory. It manages connections. When a server-rendered app and a static site share the same hardware, the static site is the free rider. It consumes bandwidth, but nothing else. The server-rendered app consumes everything: RAM, CPU, and your attention.
Choosing the right tool
Decide based on the data, not the hype. If your product is a portfolio, a documentation site, or a marketing page, use a static build. Build it, commit it, and let Caddy serve it straight from disk. There is no server process to monitor. There is no database to back up. If your product requires users to log in, store data, or perform actions that change state, you need a server. Keep that server as small as possible. Isolate it if it is heavy. Use systemd oneshot services with timers for scheduled work, not cron, to keep the main process clean. The goal is to minimise the surface area that can fail. If a site does not need a database, do not give it one. If a feature does not need a server, do not build one. The simplest system that works is the one you will actually maintain.