Add Forgejo self-hosted git service to linux-server

[ulises-c]

Summary

• Adds Forgejo (community Gitea fork) as a Docker service: web UI on port 3300, git-over-SSH on port 2222, SQLite backend
• LAN/Tailscale access only — no public ports, single-user setup
• Data path is configurable via FORGEJO_DATA_PATH in .env for easy migration to an external drive
• Wires up Homepage widget (gitea type) in a new "Dev" section

Details

New files:

• linux-server/forgejo/docker-compose.yml
• linux-server/forgejo/.env.example

Updated files:

• linux-server/README.md — Forgejo added as service Add Forgejo self-hosted git service to linux-server #15
• linux-server/homepage/config/services.yaml — Dev section with Forgejo card
• linux-server/homepage/.env.example — HOMEPAGE_VAR_FORGEJO_DOMAIN and HOMEPAGE_VAR_FORGEJO_TOKEN
• linux-server/post-install.md — first-login checklist, SSH clone instructions, and Obsidian vault migration flow

Migration flow (Obsidian vault)

1. Run + → New Migration → GitHub in Forgejo to import history
2. Point local repo at Forgejo: git remote set-url origin ssh://git@<tailscale-hostname>:2222/<user>/<repo>.git
3. Add GitHub push mirror in Forgejo for validation while transitioning
4. When satisfied, delete the mirror and archive the GitHub repo

Test plan

• cp .env.example .env, set FORGEJO_DOMAIN, run docker compose up -d
• Open http://<server-ip>:3300, complete setup wizard, create admin account
• Add SSH public key, create a test repo, clone via SSH from Mac
• Verify Homepage widget shows repo/user stats after adding token
• (Later) migrate Obsidian vault and validate push mirror to GitHub

🤖 Generated with Claude Code

[ulises-c]

Yes, this looks like a solid and appropriately scoped PR for adding a self-hosted Git service to your homelab. It covers almost all of the important pieces I'd expect for a first-pass Forgejo deployment.

A few things stand out as especially good decisions:

• Using Forgejo instead of full GitLab
• Keeping it LAN/Tailscale only
• SQLite initially (totally fine for single-user)
• Configurable data path for future external storage
• Including migration/documentation steps
• Adding Homepage integration immediately
• Using SSH-first workflows

Things the PR already handles well

Service isolation — using web UI on 3300 and SSH on 2222 avoids collisions with system SSH, common reverse proxies, and other apps.

Tailscale-only access — avoiding public ingress, Cloudflare tunnels, public SSH, and exposed web auth dramatically simplifies security. For a single-user setup, this is the right call.

Configurable data path — FORGEJO_DATA_PATH is excellent foresight for ZFS pools, NAS mounts, SSD migration, and backups.

Push mirroring during migration — the staged approach (import history → repoint remotes → mirror back to GitHub → validate → archive) minimizes risk.

Homepage integration — nice quality-of-life addition; a lot of people forget operational visibility for internal services.

What I would still add before merging

1. Explicit persistent volume backup guidance
2. Confirm restart policy (restart: unless-stopped)
3. Pin image versions instead of latest
4. Consider UID/GID mapping
5. Add note about SSH host keys persistence
6. Optional healthcheck
7. Document Tailscale MagicDNS usage

Thanks for the thorough review. Addressing each point:

Already handled in the original PR:

• restart: unless-stopped — already in the compose file
• USER_UID / USER_GID — already set to 1000/1000 in the compose environment
• SSH host key persistence — Forgejo stores all host keys under /data/gitea/conf/, which maps to the persistent FORGEJO_DATA_PATH volume, so they survive container recreation
• Tailscale MagicDNS — the setup already uses the Tailscale hostname (e.g. <hostname>.<tailnet>.ts.net) throughout all clone URL examples, which requires MagicDNS to be enabled; worth noting explicitly in the Tailscale setup step

Added in a follow-up commit:

• Healthcheck — added wget --spider check on port 3000 with 30s interval
• Image pinning note — added a comment in the compose file pointing to the releases page; latest is left as the placeholder so the user pins to whatever stable tag is current at deploy time rather than a potentially stale hardcoded version in this repo
• Backup guidance — added a table to post-install.md covering what to back up (repositories, SQLite DB, app.ini, SSH host keys) and confirming that hot backups via rsync are safe since Forgejo uses WAL mode

The one point I intentionally left as documentation-only rather than code: image pinning. Hardcoding a specific version here would go stale. The comment + releases link is the right tradeoff for a config repo.