SuperPortia has grown to 29 projects. Without a map, even the builder gets lost. This post is that map — a complete registry with three classification dimensions that make the landscape legible at a glance.
The Three Dimensions
Every project is classified along three axes:
1. Port (Where to find it)
The local port number is the project’s address on SS1. Command Center monitors health via these ports. No port = either cloud-only or no running process.
Port ranges follow a convention:
| Range | Purpose |
|---|---|
| 3000–3999 | Frontend dev servers |
| 4000–4999 | Backend services + APIs |
| 6000–6999 | Databases + Docker infra |
| 8000–8999 | API servers + MCP |
2. Deploy Type (How it gets updated)
This is the most confusing dimension because there are nine distinct patterns. Knowing which pattern a project uses determines what you do when code changes.
cloud-serverless — Push code, wrangler deploy, done. No local build step. The code runs directly on Cloudflare Workers. Serverless = no server to manage.
- Examples: Cloud UB Worker, Email Intake, Scout Worker
local-build-cloud — Must build locally first (e.g., npm run deploy which runs opennext/astro build), then deploy the build artifact to Cloudflare Workers. Skipping the local build = deploying stale code.
- Examples: Bridge (OpenNext → CF Workers), Reading (Astro → CF Workers)
cloud-static — Push to GitHub, Cloudflare Pages automatically builds and deploys. Zero manual steps after git push.
- Examples: Docs Site, Catmints Cafe, Blog
factory-storefront — The most complex pattern. A local pipeline (Python/LangGraph) runs daily to produce content (JSON, MDX). Then Astro builds a site from that content and deploys to Cloudflare Pages. The code rarely changes; the content changes daily.
- Examples: NQIO (KOL pipeline → weekly report → Astro → CF Pages)
local-only — Runs on SS1 via launchd. No cloud deployment. Access via localhost only (or Cloudflare Access for remote).
- Examples: Command Center, SPM, Agentic
local-tunnel — Runs locally via Docker or launchd, exposed to the internet through Cloudflare Tunnel (cloudflared). The service itself stays on SS1.
- Examples: SiYuan Notes (Docker + tunnel → note.superportia.dev)
local-daemon — Runs on SS1 as a background process (launchd or cron). No web UI. Does work silently — monitoring, polling, classifying.
- Examples: SRE, KOL Narratives, MCP Server, MTAAA Pipeline
docker — Runs in a Docker container on SS1. May or may not have a web UI. Started with docker start or Docker Compose.
- Examples: Open WebUI, LiteLLM, Qdrant
config-only — Not a running service. Contains configuration files, rules, scripts, or documentation that other projects consume.
- Examples: Ops (.claude/ config), Vault (Obsidian knowledge), SuperPortia Monorepo
3. Role (What it does in the ecosystem)
platform-hub — A project that is itself an app AND manages sub-projects or modules. Has its own registry/index page.
- Command Center → manages all 29 projects at
/projects - SPM → manages 62 modules at
/modules - NQIO → manages KOL channels + pipeline runs
- Agentic → manages learning boards + reading sources
standalone — A single-purpose application. Does one thing well.
- Bridge → CEO daily dashboard + agent chat
- Reading → RSS reading + AI Q&A
- SiYuan → note-taking
infrastructure — Other projects depend on it. If it goes down, multiple things break.
- Cloud UB Worker → the brain, everything queries it
- MCP Server → Claude Code’s bridge to UB
- Qdrant → vector search for local embeddings
- SRE → monitoring + alerting
pipeline — Processes data on a schedule. No interactive UI. Input → transform → output.
- Email Intake → Gmail → classify → email_intel table
- Scout Worker → RSS → parse → UB entries
- KOL Narratives → YouTube → NotebookLM → trading intel
static-site — Pure HTML/CSS/JS, no server-side logic. Content changes via git push.
- Docs Site, Catmints Cafe, Blog
config-ops — Not a service. Provides rules, scripts, and config consumed by others.
- Ops, Vault, SuperPortia Monorepo
The Complete Registry
| # | Port | Project | URL | Deploy | Role | Status |
|---|---|---|---|---|---|---|
| 1 | 3000 | NQ 2026 Alpha | — | local-only | standalone | dev |
| 2 | 3000 | Weekly Ops | week.nqio.dev | local-only | standalone | dev |
| 3 | 3001 | Open WebUI | — | docker | standalone | standby |
| 4 | 3002 | Bridge | bridge.superportia.dev | local-build-cloud | standalone | active |
| 5 | 3333 | Docs Site | docs.superportia.dev | cloud-static | static-site | active |
| 6 | 3900 | Command Center | — | local-only | platform-hub | active |
| 7 | 3991 | SPM | spm.superportia.dev | local-only | platform-hub | dev |
| 8 | 3994 | NQIO | nqio.dev | factory-storefront | platform-hub | dev |
| 9 | 4000 | LiteLLM | — | docker | infrastructure | standby |
| 10 | 4010 | Agentic | agentic.superportia.dev | local-only | platform-hub | dev |
| 11 | 4321 | Reading | read.superportia.dev | local-build-cloud | standalone | active |
| 12 | 6333 | Qdrant | — | docker | infrastructure | active |
| 13 | 6806 | SiYuan | note.superportia.dev | local-tunnel | standalone | active |
| 14 | 8787 | MCP Server | — | local-daemon | infrastructure | active |
| 15 | — | Cloud UB | ub.superportia.dev | cloud-serverless | infrastructure | active |
| 16 | — | Email Intake | — | cloud-serverless | pipeline | active |
| 17 | — | Scout Worker | scout.superportia.dev | cloud-serverless | pipeline | active |
| 18 | — | KOL Narratives | — | local-daemon | pipeline | active |
| 19 | — | MTAAA Pipeline | — | local-daemon | pipeline | dev |
| 20 | — | NQ ICT Scout | — | local-daemon | pipeline | dev |
| 21 | — | Ops | — | config-only | config-ops | active |
| 22 | — | SRE | — | local-daemon | infrastructure | active |
| 23 | — | Vault | — | config-only | config-ops | active |
| 24 | — | Catmints Cafe | cafe.superportia.dev | cloud-static | static-site | active |
| 25 | — | Blog | blog.superportia.dev | cloud-static | static-site | dev |
| 26 | — | SuperPortia | — | config-only | config-ops | active |
| 27 | — | UB Dashboard | ub.superportia.dev | cloud-serverless | standalone | planned |
| 28 | — | Nyam | nyam.superportia.dev | planned | standalone | planned |
| 29 | — | Prop Firms | propfirms.superportia.dev | planned | standalone | planned |
Reading the Table
By deploy type — When you need to update something:
- cloud-serverless / cloud-static →
git pushorwrangler deploy - local-build-cloud → build locally first, then deploy
- factory-storefront → run pipeline first, then build + deploy
- local-only / local-daemon →
launchctl kickstart - docker →
docker restart
By role — When something breaks:
- infrastructure down → multiple projects affected, fix first
- platform-hub down → management visibility lost, but apps still work
- pipeline down → data stops flowing, but existing data still serves
- standalone down → only that app is affected
By status — What needs attention:
- active (17) → running in production
- development (7) → being built, may be unstable
- standby (2) → installed but not running
- planned (3) → registry placeholder only
Port Conflicts
Two conflicts exist as of 2026-03-15:
- 3000: NQ 2026 Alpha + Weekly Ops (Weekly Ops is a sub-project, will merge into NQIO)
- 3001: Open WebUI (standby) — Bridge moved to 3002 to resolve
What This Map Enables
With three dimensions in the registry, Command Center can:
- Filter by role — show only infrastructure, only pipelines
- Group by deploy type — “what needs manual deploy” vs “auto-deploy on push”
- Monitor by port — health check every project with a port
- Audit compliance — which projects pass
/createscaffold verification
The registry lives at command-center/src/data/registry.json and is the single source of truth for all project metadata.