oll.am · Grounded in a live VPS audit · 2026-07-06

The Constellation

Platform 2.0, expanded — the maxed-out oll.am empire is mostly already deployed. Maxing it out is reuse and wiring, not new code.
Audit: read-only docker ps on the Hetzner VPS Found: 25 running containers Read: the OS for a one-person company is ~70% already running
Franc-first — read this line before the map. The money path is verified live, and the first stranger franc — CiteBible distribution (one Core env flip + rotate two secrets + post) — comes before any of this. The constellation below sequences behind that franc. This is the classic ship-vs-build risk: a maxed-out platform vision is exactly what stalls a strong builder before revenue. Sam has chosen to plan this deliberately, so — naming the pattern once — we plan it, and then we move on.

What's inside

  1. The empire is already deployed
  2. The reuse inventory
  3. How many more integrations?
  4. The wiring — config, not code
  5. The reuse-first sequence

This is the concrete, deployed companion to Platform 2.0 — where that page argues the spines and the Postiz-playbook vision, this one grounds it in what the VPS actually runs tonight. It also builds on The Agent Seam (the MCP wiring) and The Platform (the architecture of record). No code is shipped here — this is research and a plan.

The empire is already deployed the reveal, from a real audit

Tonight I ran a read-only audit of the Hetzner VPS — docker ps + docker inspect, nothing changed. It returned 25 running containers. The surprising part is not that things are running; it's how much is running. The picture below is not a roadmap — it is a snapshot of production, tiered from the shared infrastructure up to the live agent runtime.

Infra · reuse, don't provisionShared platform plumbing — all healthy ~2 months
Coolify4.0.0-beta.474healthy
Traefikcoolify-proxy · v3.6healthy
Redis 7coolify-redishealthy
Postgres 15coolify-dbhealthy
Sentinelcoolify-sentinelhealthy
Realtimecoolify-realtimehealthy
Spine · frozen infrastructureThe three spines — all live — identity, generation, memory
Corecore.oll.amlive
Modelmodel.oll.amhealthy
Memorymemory.oll.amhealthy
Product · thin clients on the spinesFive products live — plus one scaffolded, one planned
oll-writewrite.oll.amlive
CiteBiblecitebible.oll.amlive
oll.am landingoll.amredeployed tonight
specviewapp.specview.dev · web+api+landinghealthy 4d
trendfyapp.trendfy.me · app+server+ai-models+landinghealthy 5w
foto / ollshotservices/fotoscaffolded
career agentoll.inplanned
Agent · already runningAn agent + automation runtime Sam already has — no new build needed
OpenCLAW gatewayopenclaw-gateway · host :18789 · no Traefikhealthy 5w
Also present · ops itemspringular — Sam's Spring boilerplate (client + docs + server)
springular-clientboilerplateup
springular-docsboilerplateup
springular-serverboilerplaterestarting
A snapshot of production, not a plan. Green = healthy · amber = ops attention · grey = not-yet-deployed. The agent tier is the headline: the runtime is already live.
25
running containers, verified tonight
3
frozen spines, all live & healthy
5
products live on the spines
~70%
of the "one-person-company OS" already running

Say it plainly: three spines + five products + an agent runtime + reusable Redis / Postgres / Traefik, all already deployed on one VPS. The thing that reads on paper like a sprawling "maxed-out empire" to be built is, in fact, mostly already running. trendfy even ships its own ai-models service — an image backend that already exists. The remaining work is not construction. It is reuse and wiring.

The operating system for a one-person company isn't a thing to build. It's a thing that's already ~70% booted and waiting to be wired together. — the reveal in one line

The reuse inventory already-there → reuse, don't build

Once you see the map above as inventory rather than roadmap, the plan writes itself: for almost everything the "maxed-out empire" implies, the asset already exists on the VPS. The reuse-not-rebuild move is to point new outcomes at running assets instead of provisioning new ones.

Asset already on the VPS Reuse it for Instead of building
OpenCLAW gateway live the career agent, background auto-tasks, and the distribution driver — an agent runtime already listening an "agent module" from scratch
trendfy's ai-models service live + foto's Replicate LoRA pipeline ollshot / headshots — an image-generation backend that already runs in production a new image backend
Coolify Redis + Postgres live queues, rate-limits, caches — and any new service's DB as a new Neon database (per the always-Neon rule) provisioning new infra
The three frozen spines live every new product becomes a thin frontend client over HTTP — auth, billing, model, memory all inherited per-product auth / billing / model / memory code
specview + humaniz live proof the reuse pattern works — both already converged onto the spines re-deriving the pattern for each product
The pattern is already proven, not proposed. specview and humaniz are live products that already run on the shared spines. So "point the next product at the spines" isn't a bet — it's the repeat of something that already works in production.

How many more integrations? the direct answer

Here is the honest, grounded count. I checked: none of Postiz, n8n, Listmonk, Plausible, or Uptime-Kuma is deployed. So the entire "maxed-out" delta is small and knowable. The maxed-out set is ~4 self-hosted open-source deploys (each is zero new code — a Coolify app plus a domain) plus exactly one thin new-code piece: the MCP seam that wires the already-live OpenCLAW to oll-am.

Integration What it gives New code? Effort
Postiz self-hosted distribution to 30+ platforms — the dark-factory megaphone. Franc-adjacent: it automates the distribution bottleneck. No code Deploy (Coolify)
n8n self-hosted automation glue between everything — webhook → workflow No code Deploy
Listmonk self-hosted own the audience — email lists, newsletters, sequences No code Deploy
Plausible or Umami self-hosted privacy analytics — measure what actually converts No code Deploy
Uptime Kuma optional status page / uptime monitoring No code Deploy
MCP seam thin lets the already-live OpenCLAW drive the products — and makes oll.am callable from Claude Desktop / Cursor. See The Agent Seam. ~1 small service — the ONLY new code Build once
To "max out," Sam writes ONE thin service and clicks deploy ~4 times. Everything else already exists. — the bottom line, stated plainly

The wiring the constellation lines = config + webhooks, not code

If the assets already exist, the value is in the lines between them — and the lines are configuration, not code. Coolify env vars, webhook URLs, and n8n nodes. Below is what "wired together" actually looks like.

OpenCLAW⇄oll-am (MCP seam)→reads Memory · calls write / foto = "knows you AND acts for you"
Core Stripe webhook→n8n→
Postiz — announce the sale
Listmonk — start a sequence
delivery email
= the paid-event automation
Product ships → build-log→n8n→Postiz = the auto-distribution "factory megaphone"
Products→Model + Memory over HTTP = already wired, live today
Plausible / Umami tag on every frontend→one analytics view = measure what converts
Every line above is a Coolify env var, a webhook URL, or an n8n node — configuration, not new code.
The point of this diagram: the "constellation" isn't more stars — it's the lines drawn between stars that already shine. Wiring OpenCLAW to Memory, Stripe to Postiz, ships to distribution — none of it is a backend rewrite. It's config.

The reuse-first sequence franc-gated, ordered

One ordered path, franc-gated. Nothing here is a rebuild; almost nothing here is even new code. The sequence keeps both truths: the first stranger franc leads, and the maxed-out platform follows behind it cheaply.

Ordered by proximity to the first franc

  1. Now · no buildCiteBible's first franc — distribution, Sam-gated. The money path is verified; this is one console flip and a post. Everything below waits behind this line.
  2. Step 1 · 0 codeDeploy Postiz on Coolify → automate distribution. This directly attacks the franc bottleneck — no code, just a Coolify app + a domain.
  3. Step 2 · thin codeShip the MCP seam → wire the already-live OpenCLAW to the products. The career agent becomes real over endpoints that already exist. This is the one new-code piece.
  4. Step 3 · 0 codeDeploy n8n + Listmonk + Plausible → glue, own-the-audience, and measure. Three Coolify clicks.
  5. Housekeeping · opsFix the restarting springular-server; reconcile the diverged local checkout (164 / 36); and verify OpenCLAW's :18789 — it binds to 0.0.0.0, so confirm it's authenticated, since it's publicly reachable and not behind Traefik.
The grounded close. The operating system for a one-person company — identity, billing, memory, generation, an agent runtime, and reusable Redis / Postgres / Traefik — is already ~70% deployed. Maxing it out is 1 thin service + 4 Coolify clicks + wiring, not a rebuild. And the through-line to the pitch holds: your knowledge, your corpus, "Ollways private" — pay once, it's yours.

This companion doesn't restate the vision — for the spines and the Postiz playbook, see Platform 2.0; for the MCP surface, The Agent Seam; for the architecture of record, The Platform. What it adds is the ground truth: the empire is mostly already deployed, and the last mile is wiring.