Fjord

Move to Forgejo.

Your history, issues, and pull requests come with you. Plan the import, move CI deliberately, and keep an exit door open.

  1. Create your account and instance

    Create a Fjord Account, then deploy a Forgejo instance: name it, pick a region, pick a plan. It comes up on a subdomain with TLS in a few minutes. Most migrating teams pick Team for private repos, backups, and dedicated runners.

  2. Import your repositories

    Forgejo's built-in migrator can pull from GitHub and GitLab over their APIs, not just git history but the metadata around it: issues, pull or merge requests, labels, milestones, releases, and wiki where the source supports it. Generate a source token with read access to the repositories you are importing, point the migration at the source URL, and let it run.

  3. Repoint your remotes

    Update each clone's origin to the new instance, then push to confirm. Branches, tags, and full history are already there from the import, so this just tells your local clone where home is now.

    git remote set-url origin https://<yourname>.fjord.host/<org>/<repo>.git

  4. Move CI

    Forgejo Actions uses a workflow format close to GitHub Actions. GitLab CI usually needs a more explicit rewrite from stages, rules, caches, and protected variables into Forgejo workflows and secrets. Team and Pro can add dedicated, unmetered runners, so CI runs on capacity that is yours. Confirm a green run before you cut over.

  5. Cut over

    Update anything that points at the old remote: deploy keys, webhooks, badge URLs, bookmarks. Keep the old repositories read-only for a grace period if you like; nothing forces a hard switch. When you are confident, archive them.

Source paths

A source-specific walkthrough for what moves, what needs manual steps, and why teams make the move.

GitHub to Forgejo

  • Pick the repo or organization subset to import.
  • Use a GitHub token that can read source repositories and metadata. Private repos need classic `repo` scope or a fine-grained token with equivalent read access.
  • Validate history, branches, tags, issues, pull requests, labels, milestones, releases, and wiki pages.
  • Recreate GitHub-only items such as project boards, Discussions, code scanning, Dependabot, environment rules, and required checks.
Read the GitHub path →

GitLab to Forgejo

  • Confirm whether the source is GitLab.com or self-managed GitLab.
  • Use a GitLab access token with repository and API read access for the projects being imported.
  • Validate history, branches, tags, issues, merge requests, labels, milestones, releases, and wiki pages where available.
  • Review GitLab-only items such as epics, boards, snippets, approval rules, protected variables, registries, and group-level settings.
Read the GitLab path →

Moving your CI

  • GitHub Actions ports to Forgejo Actions with small edits; GitLab CI is a deliberate rewrite.
  • Secret values never migrate from any source. Re-enter repository and org secrets on the new forge.
  • Team and Pro add dedicated, unmetered runners, so CI runs on capacity that is yours.
  • Port one representative pipeline, confirm a green run, then move the rest before cutover.
Read the CI path →

Import expectations

Usually imported

Git history, branches, tags, repository metadata, issues, pull or merge requests, labels, milestones, releases, and wiki content where the source API exposes it.

Plan manually

CI secrets, runner labels, branch protection, required checks, deploy keys, webhooks, OAuth apps, package registries, project boards, Discussions, GitLab epics, snippets, and static-site publishing.

Migration checklist

The repositories are often the easy part. The risk usually lives in CI, identity, packages, permissions, and the final cutover.

  1. 01 Inventory repositories, LFS, packages, release assets, wikis, issues, pull requests, labels, milestones, webhooks, deploy keys, and branch rules.
  2. 02 List CI dependencies: hosted runner OS, self-hosted runner labels, Actions, caches, artifacts, OIDC, secrets, deployment environments, and package registries.
  3. 03 Plan identity separately: users, teams, SSO or OIDC, bot accounts, PATs, SSH keys, GPG keys, and offboarding rules.
  4. 04 Pick a validation set with one small repo, one large repo, one active service, and one workflow-heavy project.
  5. 05 Write the cutover and rollback plan before the final sync: freeze window, source read-only mode, DNS or remote updates, validation checks, and source retention.

Done-with-you migration help

Starter is self-serve. Team and Pro migration assistance is a pilot, handled case by case while we finalize scope, credential handling, and pricing. Team can request a planning call, source inventory review, checklist review, and CI cutover advice. Pro can request the same plus a written migration runbook and deeper CI review. Hands-on import execution is deferred until the support process and access controls are formalized.

PlanScopeCutover expectation
StarterSelf-serve docs and community support paths.No done-with-you migration guarantee.
TeamPlanning call, source inventory review, checklist review, and CI cutover advice while the pilot is active.We identify blockers before production cutover and recommend a rollback-safe path.
ProTeam scope plus a written migration runbook and deeper CI review while the pilot is active.We identify blockers before production cutover and document validation and rollback steps.
Request migration help

And if you ever leave us

The same openness that lets you come in lets you go out. Your data exports in the upstream Forgejo format any time, per-repository or as a full forgejo dump. No lock-in is the point, not a footnote.