steve
82931684eb
CI / Test (server-http) (pull_request) Successful in 21s
CI / Test (rest) (pull_request) Successful in 23s
CI / Test (store) (pull_request) Successful in 36s
CI / Lint (pull_request) Successful in 27s
CI / Build (windows/amd64) (pull_request) Successful in 26s
CI / Build (linux/arm64) (pull_request) Successful in 23s
CI / Build (linux/amd64) (pull_request) Successful in 1m24s
e2e / Playwright vs docker-compose (pull_request) Failing after 2m52s
P5-01 — Documentation site under docs/book/ rendered with mdBook
(downloaded via Makefile, same static-binary pattern as Tailwind).
Structured chapters: getting started, concepts, operations,
security, reference. `make docs` / `make docs-watch`. Generated
output gitignored.
P5-02 — CONTRIBUTING.md rewritten from placeholder to a full
guide. CODE_OF_CONDUCT.md adapted from Contributor Covenant for a
single-maintainer project. .gitea/issue_template/{bug,feature}.md
and PULL_REQUEST_TEMPLATE.md.
P5-04 — Six README screenshots captured live from a fresh server
bootstrap (login, empty dashboard, add-host, alerts, settings,
audit log). README rewritten to centre the screenshot grid and
link out to the docs site.
P5-05 — SECURITY.md with disclosure policy (3-day ack, 30-day
default window), scope in/out, threat-model summary, operator
hardening checklist. Mirrored as a docs-site chapter.
P5-06 — End-to-end test harness. e2e/compose.e2e.yml brings up
server + sibling Linux agent (alpine + restic) + restic/rest-server.
Agent uses announce-and-approve so Playwright can drive the full
operator flow: bootstrap → login → accept pending → backup →
verify terminal status. Second spec scrapes /metrics to assert
the P6-04 endpoint surface. .gitea/workflows/e2e.yml runs on every
PR; local how-to in docs/e2e.md.
4.1 KiB
4.1 KiB
restic-manager
restic-manager is a self-hosted, browser-based, single-pane-of-glass for managing restic backups across a fleet of Linux and Windows endpoints. It's designed for small fleets — the original target was twelve endpoints — and one operator.
What it does
- Centralised view of every endpoint's last backup, repo size, snapshot count, and recent jobs.
- Trigger any restic operation remotely (
backup,forget,prune,check,unlock,snapshots,stats,diff,restore). - Per-host backup schedules with source groups (named bundles of paths + retention policy).
- Live job log streamed to the browser; downloadable as text or NDJSON.
- Restore wizard with snapshot tree browse + path selection.
- Repo-level health surfacing (size, raw size, last-check, lock state) plus a 30/90-day size trend.
- Alerting over webhook, ntfy, or SMTP.
- Cross-platform agent (Linux + Windows).
- Append-only-credential-friendly with a separate admin credential for forget/prune.
What it isn't
- Not a SaaS. Single-instance, single-tenant, by design.
- Not a replacement for restic — it's a control plane. The agent
shells out to a real
resticbinary. - Not highly available. SQLite, single process; if you need HA backups, you're shopping in the wrong aisle.
- Not a multi-protocol backup tool. restic only.
How it fits together
┌──────────────────────────────────────────────┐
│ Server (control plane, Docker) │
│ - REST + WebSocket API │
│ - SQLite store │
│ - Embedded HTMX UI │
└──────────┬─────────────────────────┬─────────┘
│ outbound WS │ HTTP(S)
│ │
┌──────────▼──────────┐ ┌──────────▼─────────┐
│ Agent (per host) │ │ Browser (operator) │
│ - restic wrapper │ └─────────────────────┘
│ - cron for sched. │
└──────────┬──────────┘
│ restic
┌──────────▼──────────────────────────────────┐
│ rest-server / S3 / SFTP / local repo │
│ (the actual backup data — server never │
│ touches it) │
└─────────────────────────────────────────────┘
The control plane is a Go binary that runs in Docker. Each endpoint runs a small Go agent that holds an outbound WebSocket to the control plane. Backup data flows directly between the agent and the restic repository — the control plane never sees a snapshot byte.
Where to start
- Installing the server walks through the Docker-based reference deployment.
- Enrolling your first host covers the install scripts and the announce-and-approve flow.
- Architecture is the right read if you want to know why something is the way it is before running the install.
Project status
Pre-1.0 but feature-complete for the original use case. Phases
0–4 are landed (MVP, scheduling, restore, RBAC + OIDC); Phase 5
(this docs site, contributor onboarding, end-to-end CI) is in
flight. See tasks.md
for the live roadmap and spec.md
for the canonical design doc.
License
PolyForm Noncommercial 1.0.0. Personal and community deployments welcome; commercial use requires a separate license.