DevOps Project Control Environment

Run twenty projects in parallel and the bookkeeping eats the day. Which port did that container claim last week? Which folder hasn't been backed up since Tuesday? Which of those eight write-ups is actually ready to publish? Project Control is a single self-hosted cockpit that turns all of that bookkeeping into a glance — one Docker container, one URL on the laptop, every project on the operator's machine in a single view.

The problem it solves

A solo operator running 20+ parallel codebases pays a tax that compounds week over week: roughly 15-25 hours a month spent not building, but reconciling. Which port did the new docker-compose claim? Was that NAS backup actually finished or did it time out at 80%? Which write-up is on basic-edits, which is published, which is waiting on a PDF attachment? Each individual question costs five minutes. Across thirty projects and four workflows, the five-minute checks add up to two full operator-days a month.

Worse, the standard remedy is three separate tools — a port scanner, a kanban app, and a sync script — which don't share state and don't auto-discover the project folders. A new project lands on disk and the operator has to register it in three places before anything tracks it. The friction is invisible until the operator counts it: a project that exists on the filesystem but doesn't yet appear in the kanban has effectively been forgotten until the next manual sweep. And when a port collision corrupts a container at the wrong moment, recovery is 30-90 minutes and a stalled meeting.

Who needs this most

• Solo founders running 15-50 simultaneous codebases — operators whose unique advantage is breadth (cross-pollinating between projects) but whose unique liability is losing the thread on any one of them by Wednesday.
• Multi-project consultancies juggling 10+ active client repositories at once — every project has its own port, its own backup cadence, its own deploy posture, and the team has to know all of it without context-switching cost.
• Indie operators running a personal publishing pipeline alongside their main work — a portfolio site, a content engine, a research feed — anyone who needs to know which of the dozen things they've built is actually shipped and which is still half-edited in a folder.

The moment this hurts most: a Tuesday morning where the operator has to decide which three projects to push forward this week, and can't remember which ones are even backed up, let alone which are ready to publish.

The solution — in plain terms

Project Control is the operator's factory cockpit. One Docker container runs on the laptop or workstation, mounts the operator's ~/Projects folder, and exposes a five-tab web dashboard.

Every project on disk appears automatically — the system walks the filesystem at boot and rescans on demand, grouping projects by stage folder (concept, dev, stage, test, prod, archive). No registration step, no spreadsheet to maintain, no risk of a project existing on disk and going invisible to the operator's tooling. The Dashboard shows system-wide health and lets the operator launch a full backup of everything to the NAS with one click. The Port Monitor scans every project for ports it has claimed in .env, Dockerfile, docker-compose.yml, and shell scripts; it flags collisions and writes a machine-readable ports.json that other tools (including a Claude Code agent running on the same box) can read. The Kanban tab gives the operator a board view of every project with notes, git status, and one-click sync or version-backup buttons. The Table tab is a progress-tracking grid where the operator runs multi-step pipelines (currently the rist.sh publishing pipeline) and marks each project's state through a workflow. Settings holds NAS credentials, excluded projects, and allowed ports.

The whole thing lives on the operator's own machine, talks to a NAS over SMB for backups, and never reaches out to a third-party SaaS for anything.

Value delivered — what you get

• Replaces three standalone tools (port scanner, kanban, sync utility) with one cockpit — and surfaces their state in the same auto-discovered list, so a new project never falls between them.
• Catches port collisions before they cost a meeting — the scanner reads .env, Dockerfile, docker-compose, and shell scripts; conflicting host ports are flagged with the projects claiming them, and an allowlist excuses shared services like Ollama or Postgres.
• Backs up 22,000-file projects in minutes instead of hours — tar over SMB replaces rsync, which crawls when the file count climbs; smart mode skips derivatives (node_modules, .venv, __pycache__, dist, .git), and mirror mode copies everything when an exact replica is needed.
• Detects backup drift without manual audits — the hygiene checker compares the NAS tree against local disk and flags orphan projects (on NAS, deleted locally), missing loose files, and stale stage-level archives, with one-click cleanup.
• Tracks the publishing pipeline that turns project folders into portfolio posts — the Table tab models multi-step workflows (description, basic edits, image, SEO, published, PDF added, ready) with a Status column that auto-completes when the workflow trips, plus a manual Skip pin that takes projects out of the pipeline entirely.
• Generates per-project port reports for the operator's Claude Code agent — a markdown report per project, ready to drop into a coding-agent session, so port assignments and conflicts are first-class context, not buried in scattered config files.
• Runs entirely on the operator's own hardware — no SaaS dependency, no third-party data sharing, no per-seat pricing surprise.

Where it delivers outsized value

• Solo product builders running 15-50 parallel projects — the operator whose biggest risk is silently losing track of one of them. Project Control's auto-discovery and uniform surface make that loss almost impossible.
• Multi-project consultancies and small studios with 5+ active client repositories — each engagement has its own port, its own backup cadence, its own state in a private workflow; the multi-funnel Table lets each client get its own progress board without forking the tool.
• Operators running a personal publishing pipeline alongside development work — the rist.sh portfolio funnel is the canonical example; the same Table mechanic adapts to a research feed, a content engine, or a per-client delivery workflow without code changes.
• Air-gapped or LAN-first environments where SaaS project trackers are off the table — the entire stack runs offline, talks only to the operator's own NAS, and stores everything in plain JSON files on disk.

Distinctive features — why this over the alternatives

• Filesystem-driven auto-discovery — there is no "create a project" step. Drop a folder under ~/Projects/02dev/your_new_thing/ and it appears in the Kanban, the Port Monitor's scan target, the Table grid, and the backup engine the next time the page reloads. Tooling that requires manual registration loses the war within a month.
• Tar-pipe sync over SMB instead of rsync — file-by-file rsync over SMB collapses at high file counts; a single tar -chf stream through the SMB mount finishes the same backup in a fraction of the time. Symlinks are dereferenced because SMB doesn't carry them, and the exclude file is rebuilt from the operator's config on every smart sync.
• Multi-funnel progress tracker — the same project list can run through several independent pipelines side by side, each with its own column schema. The first funnel ships the operator's portfolio; the next can ship a client deliverable workflow without renaming a single project.
• Status column with sticky manual overrides — automatic state derived from the workflow columns, plus a manually-pinned Skip or Done that takes a project out of the auto-loop entirely. The operator can wave a project off the pipeline without deleting the row.
• Per-project Claude Code port reports — the Port Monitor doesn't just show conflicts in the UI; it emits a markdown report and a machine-readable ports.json that an agent can read before suggesting a port for a new container, removing a recurring class of bug at the source.
• Hygiene checker that compares NAS state to local state — orphans, stale files, and missing loose files surface as a worklist instead of leaving the operator to diff two folder trees by hand.

Under the hood — built to last

Boring infrastructure on purpose. Python 3.12 standard-library http.server, embedded HTML/CSS/JS with no front-end framework, Docker for the runtime, and tar over the kernel's CIFS mount for NAS transport. No SaaS, no cloud API, no database server — state lives in plain JSON files alongside the operator's projects. The whole system runs in a single privileged Docker container on a single port, mounts the host's Projects folder, and recovers cleanly from any restart. The aesthetic is JetBrains Mono on a green-on-black scanline terminal — fast to read, never modal. Nothing here will require a migration in five years.

Current maturity

Active and used daily as of 2026-05-25. The codebase is 7,605 lines of Python and shell across five backend modules and five page templates; the system has been in continuous development since mid-March 2026, with the multi-funnel Table tab and built-in Status column landing in the last week. The current operating run covers roughly 17 active projects through the rist.sh publishing funnel, with the kanban auto-discovering everything else on disk. NAS sync is wired against the operator's ZimaBoard over SMB and has handled the full project tree end-to-end. No external users yet — this is the operator's own tool, hardened by daily use rather than by a test suite, with cleanup and start/stop scripts (start.sh, down.sh, cleanup.sh, monitor.sh) that make the container easy to rebuild and reset.

Roadmap — what's next

The next two milestones extend the Table tab from "the operator's own pipeline" to a generalisable workflow engine. First, additional named funnels for client-specific delivery workflows — each client engagement gets its own column schema (intake → discovery → build → review → handover) over the same auto-discovered project list, so a multi-client consultancy can run the same cockpit without forking it. Second, exportable per-funnel reports as PDF or markdown attachments, so a status snapshot can be sent to a stakeholder without screen-sharing the operator's local machine. Beyond that: a thin team mode that lets a second operator (junior, partner, or auditor) see a read-only view of the same state without sharing a Docker socket.

Working with the architect

Project Control was built by and for one operator, but the methodology behind it — filesystem-as-source-of-truth, tar-over-SMB transport, multi-funnel progress tracking, auto-discovery instead of registration — generalises. Two engagement modes apply directly. Commission a similar cockpit for a multi-project operator or small studio whose tooling has fragmented into half a dozen disconnected scripts. Or engage in strategic advisory on the architecture pattern (single-container Python + plain JSON state + tar-pipe transport) for a team building its own internal operator tooling. Reach out via sintegrium.io or LinkedIn for a 30-minute scoping call.

---

Built by Yurii Staryk · Solution Ecosystem Architect