The Home-Origin Production Stack

Archive note, February 20, 2026: This post documents the SoCalNomad production stack as it existed inside the home-origin black box.

The public version of SoCalNomad looked simple enough: a WordPress site, a calendar subdomain, some articles, event pages, ads, and links out to ticket vendors.

The inside was more interesting.

Behind Cloudflare was a small home-origin production stack running on residential fiber with a business account. It was not large infrastructure, but it was layered infrastructure. Each layer had a job, and the system worked because those jobs stayed mostly separate.

This is the stack I mean when I talk about the black box.

The Edge

Cloudflare sat in front of everything public.

It handled DNS, TLS, CDN behavior, cache rules, and purge operations. It gave the site a professional edge without requiring a commercial cloud buildout. That mattered because the origin lived at home.

Cloudflare was not treated as a magic shield. The origin still had to return valid pages, correct headers, working sitemaps, and sane status codes. But Cloudflare made the home-origin model practical by absorbing edge traffic and presenting the public internet with a stable front door.

In the stack, Cloudflare was the boundary between a reader or crawler and the private machinery behind the site.

The Web Origin

The public web VM was the conservative part of the system.

It ran Apache under ISPConfig, PHP-FPM, MariaDB, and WordPress. This was where the main site lived. It also served static frontend assets for the calendar and exposed carefully chosen proxy paths to internal services.

WordPress handled the editorial surface:

• Posts and pages.
• The GeneratePress child theme.
• Custom front-page behavior.
• Review and attraction content.
• REST endpoints and theme-level proxy behavior.
• Cache hooks and purge triggers.

ISPConfig was not glamorous, but it gave the origin a familiar hosting control plane: domains, vhosts, PHP settings, database management, SSL integration, and filesystem conventions.

That mattered because the goal was not to reinvent hosting. The goal was to make a modest origin behave predictably.

The Calendar Application

The calendar was a separate frontend, not a WordPress template.

It used React and Vite because event discovery behaves more like an application than an article archive. Users need to browse dates, search, filter, open event details, and move between artists, venues, and listings.

The calendar started with static JSON exports where that made sense. Static data was fast, cacheable, and easier to reason about while the interface matured. Later, API-backed behavior and PostgreSQL data became more important.

That staged approach was part of the stack philosophy: prove the surface before making the backend more complicated.

Internal APIs

The public site and calendar did not talk directly to every backend service.

Internal APIs handled narrow jobs:

• Calendar data.
• Ticker items.
• Promotional/ad proxy behavior.
• Selected WordPress-to-service bridges.

Some of these were Node services. Some were WordPress proxy endpoints. The important design choice was that public paths were intentional. Internal services did not need to be broadly exposed just because they existed.

That kept the black box black.

A browser could request a route. Apache, WordPress, or the calendar API could answer. The user did not need to know what internal service produced the data.

The Data Mart

PostgreSQL became the operational memory of the platform.

WordPress stored published content. PostgreSQL stored the messy facts behind the platform:

• RSS staging records.
• Filtered articles.
• Story clusters.
• Ticker items.
• Artists.
• Venues.
• Events.
• Provider data.
• Grouping relationships.
• Enrichment outputs.

This separation was important. WordPress was the publication layer. The data mart was the working layer.

The data mart let automation ask structured questions without abusing WordPress tables. It also made the platform loop possible: source material could become articles, ticker items, calendar links, artist references, venue pages, and later newsletter or social material.

Automation After n8n

n8n was part of the early exploration, but it was not the final center of gravity.

The production pipeline moved into Python scripts and cron. That changed the character of the system. The work became version-controlled, testable, greppable, and easier to run in small pieces.

The NewsDesk stack was ordinary code:

• Ingest feeds.
• Filter for Southern California entertainment relevance.
• Cluster related items.
• Synthesize drafts.
• Publish to WordPress as drafts.
• Generate or attach images.
• Enrich with artist, venue, and event context from PostgreSQL.

Cron handled scheduling. Python handled business logic. PostgreSQL handled state.

That was a better production fit than a large visual workflow graph with hidden validation state, awkward item-index behavior, and fragile agent loops.

Monetization Layer

The black box also contained the beginnings of monetization infrastructure.

Affiliate links belonged naturally in the calendar because event discovery creates purchase intent. Revive Adserver handled display advertising because the site needed ad zones that could be managed centrally across WordPress and calendar surfaces.

Ad serving created its own engineering constraints:

• Same-origin delivery to reduce obvious blocking.
• Zone mapping in the WordPress theme.
• Calendar ad components.
• Delivery cache management.
• Avoiding brittle ad-looking paths and CSS names where possible.

This was not just a revenue add-on. Monetization affected routing, caching, templates, and operations.

Operations And Verification

The stack only worked because it had operating habits around it.

The practical tools were ordinary:

• SSH.
• rsync deploys.
• WP-CLI.
• Docker commands.
• cron logs.
• PostgreSQL dumps and restores.
• Cloudflare purge calls.
• Cache-clearing recipes.
• Search Console validation.

None of those are exotic. Together, they made the home-origin system maintainable.

Search Console became the outside referee. It did not care that the origin was a home lab. It cared whether Google could crawl, index, understand, and trust the public surface.

Getting that surface green required the entire stack to cooperate: Cloudflare, Apache, WordPress, sitemaps, cache invalidation, structured data, status codes, and content quality.

Why The Stack Worked

The stack worked because it had boundaries:

• Cloudflare was the edge.
• Apache and ISPConfig were the web origin.
• WordPress was the editorial layer.
• React/Vite was the calendar interface.
• Node and WordPress endpoints exposed narrow APIs.
• PostgreSQL was the data mart.
• Python and cron ran automation.
• Revive and affiliate links handled monetization.
• Search Console judged the public result.

That is the black box.

Not one clever service. Not a single framework. A small set of ordinary tools arranged so that the outside world saw a coherent production site instead of a home network full of experiments.

That is the part worth being proud of.