Self-hosted GitHub alternative with control without the ops burden
Teams usually look for a self-hosted GitHub alternative because they want more control over source code, identity, runners, data location, or vendor exposure. The tradeoff is that self-hosting often turns the forge into an operations project: upgrades, backups, runners, storage, monitoring, and incident response become your team’s responsibility.
Fjord is built for the middle ground. You get a managed Forgejo instance that is single-tenant by architecture, operated by Fjord, with managed Linux CI runners and nightly, encrypted, off-site backups with 90-day rolling retention. That gives you standard Forgejo interfaces and repository portability without making your team run the platform.
If you already know you want managed Forgejo hosting, start with Managed Forgejo Hosting. If you are planning a move from GitHub, use the Migrate from GitHub to Forgejo guide.
Comparison
| Dimension | Fjord | GitHub | DIY Forgejo | GitLab |
|---|---|---|---|---|
| Sovereignty | Your own managed Forgejo instance with standard Forgejo interfaces and git remotes | Hosted platform controlled by GitHub | High control if you operate the instance well | Available through self-managed GitLab or hosted GitLab, depending on how you deploy |
| Single-tenant | Single-tenant by architecture | Shared hosted service for github.com | Yes, if you deploy one instance for your team | Yes when self-managed; hosted GitLab depends on plan and deployment |
| Who runs operations | Fjord handles provisioning, upgrades, runner registration, Pages hosting, and backups | GitHub runs the platform | Your team handles upgrades, backups, runners, storage, security, and incidents | Your team if self-managed; GitLab if hosted |
| CI included | Shared Linux runner pool on every tier, with dedicated runners as a paid add-on on Team and Pro, not billed by the CI minute | GitHub Actions is integrated with GitHub’s hosted runner model | Forgejo Actions is available, but your team operates the runners | GitLab CI/CD is integrated; runner operations depend on deployment |
| Lock-in | Standard Forgejo, git remotes, and Forgejo API, with Fjord tooling around the forge | Git is portable, but issues, pull requests, Actions, packages, and APIs are tied to GitHub | Low platform lock-in, but operational scripts and hosting choices become yours | Git is portable; project data, CI, and commercial features can tie teams to GitLab |
| License | Fjord runs standard Forgejo as a managed service | Proprietary hosted platform | Forgejo is open source | GitLab is open core, with both open source and commercial editions |
When Fjord fits
Choose Fjord when your team wants a GitHub alternative that does not put source code and CI into a shared forge, but also does not want to own forge operations. Fjord gives each customer a managed Forgejo instance with its own operational boundary, so repositories, organizations, identities, webhooks, runners, and backups stay scoped to that instance.
Fjord is also a fit when CI cost predictability matters. Every tier runs CI on
the shared runner pool, and Team and Pro can attach unmetered dedicated Linux
runners as a flat monthly add-on rather than paying by the CI minute. Forgejo
Actions uses GitHub Actions compatible workflow syntax, so .github/workflows can run on Forgejo while you migrate.
When GitHub fits
GitHub fits teams that want the largest hosted developer platform and are comfortable with GitHub controlling the service boundary. It gives you a mature hosted forge, marketplace, Actions ecosystem, and broad integration support, but it is not a self-hosted source forge and it does not give each team its own Forgejo-compatible instance.
For teams leaving GitHub, the key question is whether Git portability is enough. Code moves easily, but issues, pull requests, releases, workflow secrets, packages, webhooks, and status integrations need explicit migration planning.
When DIY Forgejo fits
DIY Forgejo fits teams that want maximum control and have the operational staff to run the forge themselves. You choose the infrastructure, network boundary, storage, backup system, runner hosts, upgrade cadence, and monitoring.
That control has value, but it is real work. A production forge needs reliable backups, tested restores, runner capacity, security updates, storage growth planning, and clear incident ownership. If your team wants Forgejo without owning that layer, use managed Forgejo hosting on Fjord.
Already self-hosting Forgejo?
You do not have to move your server to use Fjord’s clients against it. The fj CLI connects to any Forgejo host with a personal access token at no
extra cost, so you can drive your own instance from the terminal today. The Fjord Mobile app can also point at a self-hosted Forgejo
instance that Fjord does not host for you (a custom server); that app connection
is a Pro feature, while the CLI-direct token path stays free.
When GitLab fits
GitLab fits teams that want a broad DevOps suite and are willing to standardize around GitLab’s application model. Self-managed GitLab can satisfy a self-hosting requirement, and GitLab CI/CD is a mature integrated CI system.
The tradeoff is scope. GitLab is a large platform to operate when self-managed, and hosted GitLab moves you back toward a shared service model. Teams that want a smaller Forgejo-based source forge with managed operations may prefer Fjord.
Migration path from GitHub
Forgejo can import GitHub repositories and project metadata, including issues,
pull requests, labels, milestones, releases, and LFS objects when configured.
Forgejo Actions uses GitHub Actions compatible workflow syntax, so workflow
files under .github/workflows can run as-is while you move.
Plan the cutover before you archive GitHub. Import the repositories, recreate secrets and webhooks, run CI on Forgejo, verify LFS files from a fresh clone, and then update developer remotes.
Use the Migrate from GitHub to Forgejo guide for the self-serve migration checklist.
- Stephen Way