#+title: gitbay roadmap Status and direction as of 2026-08-24. Issue numbers reference this repository's tracker; this file is the narrative, the tracker is the truth. * Where things stand 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. * Phase 1 — collaboration credibility [COMPLETE 2026-08-24] 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. - [[https://gitbay.org/krz/gitbay/issues/22][#22]] deploy keys — smallest item, unblocks CI checkout; the scope already exists in the policy layer - [[https://gitbay.org/krz/gitbay/issues/1][#1]] commit statuses API and MR check display - [[https://gitbay.org/krz/gitbay/issues/3][#3]] email notifications for issue/MR activity - [[https://gitbay.org/krz/gitbay/issues/2][#2]] inline review comments on MR diffs - [[https://gitbay.org/krz/gitbay/issues/19][#19]] required approvals and CODEOWNERS (builds on #1 and #2) * Phase 2 — a product, not a debug view Goal: the site looks and reads like something you would recommend. Mostly web-layer; descriptions and profiles already landed as the first step. - [[https://gitbay.org/krz/gitbay/issues/10][#10]] design revamp (umbrella: tokens, typography, identity, mobile) — shipped 2026-08-24, open pending visual review - [[https://gitbay.org/krz/gitbay/issues/6][#6]] cross-references (#N) and @mentions — done 2026-08-24 (rendering-side; backlinks and mention notifications later) - [[https://gitbay.org/krz/gitbay/issues/23][#23]] archived repos and topics — done 2026-08-24 (topic filtering rides along with search, #7) - [[https://gitbay.org/krz/gitbay/issues/24][#24]] blame view — done 2026-08-24 - [[https://gitbay.org/krz/gitbay/issues/7][#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) - [[https://gitbay.org/krz/gitbay/issues/20][#20]] milestones and issue templates — done 2026-08-24 - [[https://gitbay.org/krz/gitbay/issues/30][#30]] activity graph on owner pages (platform-recorded activity signal; events table already covers issues/MRs, extend to commits) - [[https://gitbay.org/krz/gitbay/issues/31][#31]] issue actions from commit messages — done 2026-08-24 (closes/fixes/resolves #N closes on landing; bare #N leaves a comment) * Phase 3 — other people's forges Goal: someone who is not the author runs an instance and moves their work to it. - [[https://gitbay.org/krz/gitbay/issues/26][#26]] release engineering: versioned builds, go-install vanity imports, Homebrew/deb — the adoption gate for everything below - [[https://gitbay.org/krz/gitbay/issues/27][#27]] repository maintenance (admin gc/stats, scheduled repack) - [[https://gitbay.org/krz/gitbay/issues/8][#8]] releases (notes + assets; also hosts gitbay's own binaries) - [[https://gitbay.org/krz/gitbay/issues/17][#17]] issue/PR history import from GitHub - [[https://gitbay.org/krz/gitbay/issues/18][#18]] push/pull mirroring for gradual migration - [[https://gitbay.org/krz/gitbay/issues/29][#29]] account migration between gitbay instances — no lock-in, ever; the export bundle doubles as a user-level backup - [[https://gitbay.org/krz/gitbay/issues/14][#14]] audit logging and multi-user hardening - [[https://gitbay.org/krz/gitbay/issues/9][#9]] web signup for open/invite instances * Phase 4 — reach Bigger bets, each valuable independently; order by appetite. - [[https://gitbay.org/krz/gitbay/issues/13][#13]] CI/CD via external runners (after #1; the forge never executes repository content) - [[https://gitbay.org/krz/gitbay/issues/16][#16]] Git LFS - [[https://gitbay.org/krz/gitbay/issues/15][#15]] static page hosting (needs the separate-origin decision) - [[https://gitbay.org/krz/gitbay/issues/11][#11]] iOS app (hutch-based) and [[https://gitbay.org/krz/gitbay/issues/12][#12]] Android - [[https://gitbay.org/krz/gitbay/issues/21][#21]] teams within orgs - [[https://gitbay.org/krz/gitbay/issues/25][#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. * Phase S — security (cross-cutting) Not a sequential phase: items land alongside whatever phase is active, and the whole set gates flipping gitbay.org to open registration. - [[https://gitbay.org/krz/gitbay/issues/14][#14]] audit logging, rate limiting, quotas, user disable — the multi-user half - [[https://gitbay.org/krz/gitbay/issues/28][#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. * Explicitly not planned 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 * Decisions - **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.