The DNS and Certificate Layer
Every subdomain requires a distinct DNS A record pointing to the server IP. With DNS managed at Spaceship, adding a record is a single click, but the implication is that the server must now recognize and serve that specific host. Caddy terminates TLS for every site, automatically obtaining certificates from Let's Encrypt. While this automation removes the manual renewal headache, each new subdomain triggers a new ACME challenge and a new certificate file. On a single VPS with limited resources, the certificate validation process consumes CPU cycles and file system space. The certificates themselves are small, but the metadata, the renewal logs, and the key storage add to the disk usage. More importantly, the server configuration must be updated to map the new hostname to the correct backend. This is not a one-off task; if the server configuration changes, every subdomain entry must be verified to ensure routing remains intact.
The Application Routing Complexity
The architecture here relies on a single Next.js process serving four sites via host-based routing: pracandy.com, flix.pracandy.com, walls.pracandy.com, and the admin panel. Instalaz runs as a separate Node process on port 3050, proxied by Caddy. GamingCap and Invoiceful are static builds served directly from disk, bypassing the Node process entirely. This split is deliberate. Static sites like Invoiceful have no server process and no database, so they impose almost no runtime cost. However, adding a new dynamic subdomain means it must either join the Next.js host map or spin up a new process. Joining the Next.js process increases the memory footprint of that single instance. If the new site has heavy rendering requirements, it competes for memory with the existing services on the 12GB RAM box. Spinning up a new process adds another entry to the system's process table and another port to manage in Caddy. The decision is rarely about what is easiest to build, but what is easiest to keep running without impacting the other four services.
Content and Compliance Overhead
A subdomain is not just a technical endpoint; it is a legal and operational entity. Each site needs a unique privacy page, a terms of service, and often a dedicated sitemap. For a film publication like
PracandyFlix, the sitemap is dynamic and changes with every new article. For a static tool, it is fixed but still requires generation and submission to search engines. Analytics tracking must be configured for each subdomain to ensure data is not mixed or lost. If the products share a single PostgreSQL 16 database, the new subdomain's tables must be designed to coexist without locking conflicts. A poorly indexed table on a new subdomain can slow down queries for the entire system. The compliance work is repetitive. You write the privacy policy once, but you must host it on every subdomain that collects user data. This is not a task that scales linearly; it scales with the number of distinct user interfaces you are maintaining.
The Deployment and Monitoring Path
Scheduled work runs as systemd oneshot services with timers, not cron. This is a critical distinction for reliability. Adding a new subdomain that requires background jobs means writing a new systemd unit file. It must be tested, enabled, and monitored. If the new service fails, it must not bring down the existing timers. The deployment path must account for the new subdomain. If you use a CI/CD pipeline, the pipeline must know to build and deploy the new static files or restart the specific Node process. The 193GB disk space is finite. Log files from the new service will grow. Without log rotation configured specifically for the new subdomain's output, the disk can fill up, affecting all services on the box. The cost is in the attention. You must remember to check the logs, the disk usage, and the memory consumption of the new addition
