Archive note, October 17, 2025: This post is based on SoCalNomad infrastructure documentation from late 2025.
The production architecture I am proudest of was not large.
It was disciplined.
SoCalNomad ran from a home Proxmox environment on a residential fiber connection with a business account. The public side looked like an ordinary HTTPS site. Behind it was a small two-VM architecture that separated page serving from automation and data processing.
That separation mattered more than the hardware.
The Public VM
The first VM handled the web-facing work:
- Apache under ISPConfig.
- WordPress for the main site.
- PHP-FPM.
- Static hosting for the calendar frontend.
- Reverse-proxy rules for selected internal APIs.
This VM was the origin server Cloudflare talked to. It had to be conservative because it was closest to the public internet. It served pages, accepted WordPress requests, and exposed only the paths that needed to be public.
The main design goal was simple: keep the public surface understandable.
The Automation VM
The second VM handled the machinery:
- n8n workflows, at first.
- PostgreSQL data mart.
- Calendar API.
- Ticker API.
- Docker containers on a shared internal network.
This was where automation could be messy without becoming directly public. Feed ingestion, AI filtering, event data, and ticker items could live there. Public requests reached those services only through intentional proxy paths.
That gave the system a useful posture: WordPress was the public publication layer; the automation VM was the engine room.
The important phrase is “at first.” n8n was useful for exploring the shape of the automation, but it was not where the system ultimately wanted most of its business logic to live. The production design that lasted moved more of the work into version-controlled code, scripts, direct database operations, and cron.
Why Not Put Everything In WordPress?
Because WordPress is good at being WordPress.
It is less good as a workflow orchestrator, API gateway, event data mart, queue processor, AI pipeline, and frontend application server all at once.
SoCalNomad still used WordPress heavily. It handled editorial publishing, theme rendering, admin workflows, and post metadata. But automation workloads belonged elsewhere. They needed their own database, schedules, logs, and failure modes.
The two-VM design kept those concerns separate without requiring cloud-managed services.
Cloudflare Was The Edge
Cloudflare made the home-hosted origin plausible.
It provided:
- DNS.
- TLS termination behavior.
- CDN caching.
- A public edge between crawlers and the home network.
- Cache tools that became part of the deployment workflow.
Cloudflare did not make the origin irrelevant. Slow origin responses, bad headers, broken sitemaps, and stale caches still mattered. But it let the small home system present itself like a production site.
That was the practical win. The project did not need hyperscale infrastructure. It needed a reliable edge, a sane origin, and clear internal boundaries.
The Black Box Standard
The outside world did not need to know that WordPress, a React calendar, Node APIs, PostgreSQL, cron jobs, and ad-serving pieces lived behind the same project.
It needed pages to load.
It needed Googlebot to crawl.
It needed SSL to work.
It needed redirects, sitemaps, structured data, caching, and APIs to behave consistently.
That became the standard: the internal system could be scrappy, but the external behavior could not look improvised.
What Made It Production Worthy
The production-worthiness did not come from any one tool. It came from accumulated constraints:
- Public and internal workloads were separated.
- Only necessary paths were proxied.
- Databases stayed internal.
- Automation could fail without taking the site offline.
- Cloudflare absorbed edge concerns.
- ISPConfig gave the web VM a manageable hosting model.
- Documentation recorded how to restore, deploy, and clear caches.
It was not cloud-native. It was not enterprise. It was a careful home-production system built from ordinary parts.
That is worth documenting because the lesson is portable:
small infrastructure can behave professionally if its boundaries are explicit.