docs/roadmap.org

Everything in the original plan is built, tested end-to-end against real git/ssh/sshd/gpg, and running in production at gitbay.org: the SSH control plane (usable from bare OpenSSH, enforced by test), git over SSH/HTTPS/git://, signature verification with six states and epoch caching, protected branches and require_signed_commits (push-time and merge-time), issues, merge requests with four merge strategies, orgs with membership-derived access, rename/transfer, repo import, invite and open registration with SMTP verification, ACME TLS, the read-only and accounts web modes, the JSON API fronting the whole command registry, signed webhooks with retries and dead-lettering, restore-tested backups, the gitbay CLI, and docs. The instance hosts 65 repositories including this one, and its own development already runs through its issues and merge requests.

What it is today: an excellent forge for its author and for CLI-native individuals. What it is not yet: a forge a GitHub-habituated team would stay on, or a project outsiders can easily run themselves.

Goal: a second contributor works here for a week and misses nothing they would act on. All five shipped: deploy keys, commit statuses with require-checks gating, email notifications, inline review threads, and required approvals with CODEOWNERS and require-resolved.

• #22 deploy keys — smallest item, unblocks CI checkout; the scope already exists in the policy layer
• #1 commit statuses API and MR check display
• #3 email notifications for issue/MR activity
• #2 inline review comments on MR diffs
• #19 required approvals and CODEOWNERS (builds on #1 and #2)

Goal: the site looks and reads like something you would recommend. Mostly web-layer; descriptions and profiles already landed as the first step.

• #10 design revamp (umbrella: tokens, typography, identity, mobile) — shipped 2026-08-24, open pending visual review
• #6 cross-references (#N) and @mentions — done 2026-08-24 (rendering-side; backlinks and mention notifications later)
• #23 archived repos and topics — done 2026-08-24 (topic filtering rides along with search, #7)
• #24 blame view — done 2026-08-24
• #7 search — done 2026-08-24 (repo search by name/desc/topic, per-repo git grep on web+SSH; cross-repo indexer only if ever needed)
• #20 milestones and issue templates — done 2026-08-24
• #30 activity graph on owner pages (platform-recorded activity signal; events table already covers issues/MRs, extend to commits)
• #31 issue actions from commit messages — done 2026-08-24 (closes/fixes/resolves #N closes on landing; bare #N leaves a comment)

Goal: someone who is not the author runs an instance and moves their work to it.

• #26 release engineering: versioned builds, go-install vanity imports, Homebrew/deb — the adoption gate for everything below
• #27 repository maintenance (admin gc/stats, scheduled repack)
• #8 releases (notes + assets; also hosts gitbay's own binaries)
• #17 issue/PR history import from GitHub
• #18 push/pull mirroring for gradual migration
• #29 account migration between gitbay instances — no lock-in, ever; the export bundle doubles as a user-level backup
• #14 audit logging and multi-user hardening
• #9 web signup for open/invite instances

Bigger bets, each valuable independently; order by appetite.

• #13 CI/CD via external runners (after #1; the forge never executes repository content)
• #16 Git LFS
• #15 static page hosting (needs the separate-origin decision)
• #11 iOS app (hutch-based) and #12 Android
• #21 teams within orgs
• #25 wikis

When #15 (pages) and #25 (wikis) land, docs/ moves out of the blob view and becomes gitbay.org's own published documentation site — the docs dogfooding the features the same way the tracker and MRs already do.

Not a sequential phase: items land alongside whatever phase is active, and the whole set gates flipping gitbay.org to open registration.

• #14 audit logging, rate limiting, quotas, user disable — the multi-user half

• #28 hardening umbrella — the rest, both layers:

  • software: fuzz all attacker-facing parsers (pkt-line, SSHSIG, commit, armor), web security headers (CSP et al.), govulncheck, constant-time comparison audit, a written threat model, signed releases
  • host: unattended OS patching, tighter systemd sandboxing (SystemCallFilter and friends), auth throttling on both SSH surfaces, database file modes and continuous replication, service/disk/cert monitoring

Already true and worth preserving (the threat model will write these down): the forge never executes repository content; no server signing key; repo-authored HTML never renders on the forge origin; tokens and sessions stored as hashes only; SSRF guards at registration and dial time; private repositories indistinguishable from nonexistent.

Recorded so their absence reads as a decision, not an oversight:

• container/package registry — scope creep away from "forge"; external registries integrate via CI
• email patch flow — revisit only if sourcehut-style demand appears
• federation (ForgeFed) and Postgres — no current need at this scale

• gitbay.org will eventually be open to all. (Decided 2026-08-24.) Sequencing consequence: before flipping registration = "open", the instance needs #14 (audit log, rate limiting, quotas), #9 (web signup), an SMTP relay configured for verification mail, and enough of Phase 1 that new users get a credible product. Interim step: invite mode for early collaborators as soon as [mail] is configured.
• Versioning: semver, starting at v0.1.0 on the current state. 0.x signals moving surfaces; protocol_version increments only on breaking envelope/command changes and is otherwise decoupled from release numbers. v1.0.0 when Phase 1 and #26 land. Tags are annotated and signed.
• Second contributors: invite mode is the on-ramp (their keys and verified emails make signed-main enforceable for them too). A CONTRIBUTING file states the workflow: fork on gitbay.org, MR with signed commits, go test ./... green, review required once #19 exists. No CLA — 0BSD needs none; sign-off optional.