Build from source (go build ./cmd/gitbayd), install via the vanity module path (go install gitbay.org/gitbay/cmd/gitbayd@latest), or use a release build: deploy/release.sh <tag> cross-compiles reproducible linux/amd64, linux/arm64, and darwin/arm64 binaries with a SHA256SUMS manifest (CGO off, trimpath, stripped — byte-identical per commit and toolchain).

install -m 755 gitbayd /usr/local/bin/
adduser --system --group --home /var/lib/gitbay --shell /usr/sbin/nologin gitbay
install -d -o gitbay -g gitbay -m 750 /var/lib/gitbay
gitbayd --config /etc/gitbay/config.toml check-config

deploy/ in the source tree has a cloud-init file, a hardened systemd unit, and a nightly backup timer. Run as the unprivileged gitbay user; the unit's AmbientCapabilities=CAP_NET_BIND_SERVICE covers ports 22/80/443 without root.

/etc/gitbay/config.toml. check-config validates and names every contradiction; --no-host-checks skips port/path probes.

gitbayd admin user create alice --key alice.pub --email a@example.org --verified [--admin]
gitbayd admin email verify alice a@example.org   # admin assertion, no SMTP needed
gitbayd admin invite --email b@example.org       # mails a code; prints it if no SMTP

"Verified" means SMTP-confirmed or host-admin-asserted; the database records which. Verified emails are what make commit signatures meaningful — an unverified address never produces a verified badge.

The audit log is the security feed (events are the product feed): every successful mutating command with its argv and source credential (SSH key fingerprint or API), registrations, admin actions, force-pushes, and auth failures/throttling. Secrets never appear — they travel on stdin, never in argv.

gitbayd admin audit [--limit n]      # host-local
ssh git@<host> audit [--limit n]     # instance admins, SSH only
gitbayd admin user disable <name>    # suspend: SSH, web, API all refused;
gitbayd admin user enable <name>     #   sessions dropped, nothing deleted
gitbayd admin user delete <name> --yes  # only for accounts anchoring nothing:
                                     #   refused (with each blocker named) while
                                     #   the account owns repos, authored
                                     #   issues/MRs/comments/reviews, or is an
                                     #   org's only admin

limits.ssh_auth_rate (10) throttles per-IP authentication failures per minute — successful auths never count and clear the slate. limits.max_pack_bytes is enforced as receive.maxInputSize on every push.

gitbayd admin stats [--json]         # counts, database size, per-repo disk
gitbayd admin gc [--repo owner/name] # git gc: repack and prune; per-repo sizes
gitbayd admin gc --aggressive        # thorough repack; slow, rarely needed

deploy/cloud-init.yaml ships a gitbay-gc.timer that runs admin gc weekly (Sunday 07:00 UTC). Imported repositories keep whatever pack layout the source sent, so a first manual admin gc after a bulk import is worthwhile.

gitbayd admin backup --out /var/backups/gitbay/backup.tar.gz

One archive: a consistent SQLite snapshot (taken before the repositories are read, so the database never references objects the archive missed), every repository, and the SSH host keys. Excluded: hook socket, regenerated hook scripts, WAL files. Safe to run against a live daemon.

Restore: extract into an empty directory, point server.root at it, start gitbayd. Host keys are preserved, so clients keep their known_hosts entries; hooks regenerate at startup.

Replace the binary, restart the unit. Migrations apply automatically and are transactional; hook scripts under <root>/hooks are rewritten at startup to point at the current binary path.

gitbay-runner executes builds queued by pushes. It polls over SSH as an admin account (runner commands are admin-only: a runner executes arbitrary repo code), clones, runs the steps, streams the log back, and resolves the commit status. Run it as a dedicated unprivileged user:

useradd --system --create-home --home-dir /var/lib/gitbay-runner ci-runner
sudo -u ci-runner ssh-keygen -t ed25519 -N "" -f /var/lib/gitbay-runner/.ssh/id_ed25519
gitbayd --config /etc/gitbay/config.toml admin user create ci --admin \
  --key /var/lib/gitbay-runner/.ssh/id_ed25519.pub
gitbay-runner -remote git@127.0.0.1 -workdir /var/lib/gitbay-runner/work

v1 runs steps directly on the host — no containers — so treat the runner machine as executing whatever your users push. Install the toolchains your builds need on it.

Instance admin on the runner account only authorizes the claim/report protocol; it grants no repo access. A build that pushes back — a pages deploy, an archive publish, an automated MR branch — needs an explicit grant on that repo: repo access grant <owner/name> ci write. Private repos likewise need at least read for the clone.

Objects live content-addressed under [lfs] root (default <server.root>/lfs); [lfs] max_object_bytes caps a single object (512MB default). Storage sits behind a small interface — an S3-compatible backend is a drop-in with the server proxying, and presigned URLs a later optimization. LFS objects do not travel with push mirrors (mirrors move git refs only), and gc does not yet collect orphaned objects.

[pages] domain = "example.site" serves public repos' pages branches on <owner>.<domain>. DNS needs a wildcard record *.<domain> to the server; ACME issues per-subdomain certificates on demand (only for owners that exist). The domain must not be the site host or a parent of it — pages content runs its own scripts and must stay off the forge's origin.

Users with repo admin claim custom domains with repo domain add. Claims activate only after a DNS TXT challenge proves control of the domain (repo domain verify, audit-logged); pending claims serve nothing, get no certificates, and expire after 7 days. ACME issues certificates only for verified hosts, so stray DNS pointed at the server gets nothing.

The Threat-Model file is the reference for what the forge trusts and refuses to do. Operational checklist:

• Software checks. deploy/audit.sh runs go vet, govulncheck (the module list is deliberately short — review it on each release), and a short fuzz pass over every attacker-facing parser (pkt-line, commit, SSHSIG armor, OpenPGP key, SSH tokenizer). Run it before tagging a release.
• Web responses carry a scripts-forbidden CSP, X-Frame-Options: DENY, nosniff, no-referrer, and HSTS when TLS is on — no configuration needed.
• Host sandboxing. The systemd unit in deploy/cloud-init.yaml runs gitbayd unprivileged with ProtectSystem=strict, PrivateDevices, LockPersonality, MemoryDenyWriteExecute, SystemCallFilter=@system-service, and RestrictAddressFamilies to INET/INET6/UNIX. It keeps CAP_NET_BIND_SERVICE only, to bind 22/80/443.
• OS patches apply via unattended-upgrades (security origins, auto-reboot 04:30 if required).
• Admin sshd (2222) is throttled by MaxStartups=/=MaxAuthTries and watched by fail2ban; gitbayd's own port 22 is throttled by limits.ssh_auth_rate (auth failures per IP per minute).
• Monitoring. gitbay-monitor.timer posts disk/service/cert status hourly to the webhook URL in /etc/gitbay/monitor.url (create the file to enable; absent = silent). Alerts fire on a stopped service or disk ≥ 85%.
• Database. gitbay.db and its WAL live under /var/lib/gitbay (mode 0750, owned by gitbay). The nightly archive plus provider snapshots are the recovery path; for tighter RPO, add continuous replication (litestream) against the same file — it coexists with the WAL.

• deleting a fork marks MRs sourced from it source_gone; their diffs remain viewable and mergeable because the target repo owns the objects.
• refs/merge-requests/* is server-owned and unpushable by clients.
• audit-relevant activity (issue/MR lifecycle, imports, pushes) lands in the events table, which also feeds webhooks.
• the daemon idles under 10MB RSS; the smallest VPS tier is adequate.