Forgejo on bismigelhttps://bismigel.dev/tags/forgejo/Recent content in Forgejo on bismigelHugoen-usbismigelMon, 19 Oct 2026 20:30:00 -0400Why I am considering Forgejo, and why I have not switchedhttps://bismigel.dev/posts/2026-10-19-why-forgejo/Mon, 19 Oct 2026 20:30:00 -0400https://bismigel.dev/posts/2026-10-19-why-forgejo/I added CI to the GitOps repo. The workflow validates YAML, Kubernetes schemas and Prometheus rules. It runs on every pull request.

It still does not block a bad merge.

That is the problem. `bakuran-gitops` is private on GitHub Free. Required status checks and branch protection are paid features for private repositories. The workflow can be red, and the merge button still works. For a one-person lab that is a discipline problem; for a hiring signal it is worse, because the repo advertises guardrails it cannot enforce.

What I actually want

  • a private Git remote I control;
  • pull requests;
  • required checks that actually block;
  • no per-seat or per-private-repo paywall;
  • a path to CI and an OCI registry that I understand.

Forgejo is the obvious candidate. It is lightweight, self-hostable, and has branch protection and Actions without GitHub’s private-repo plan gate.

What Forgejo does not solve for free

Running the server is the easy part. The migration is the work:

  • GitHub Actions are not guaranteed to run unchanged;
  • a self-hosted runner is another privileged workload to secure;
  • GHCR has to be replaced or kept external;
  • repository imports do not guarantee perfect PR and issue history;
  • SMTP, OAuth, TLS, backups and upgrades become mine;
  • public Git access needs a different auth story from a browser app behind Cloudflare Access.

Forgejo gives control. It also gives me another service to patch.

Why I am deferring it

I do not want to migrate the platform and the Git host at the same time. The honest sequence is:

  1. finish the current platform work;
  2. run Forgejo internally, with no public edge;
  3. mirror two repos and read them from ArgoCD;
  4. port one CI workflow, not all of them;
  5. restore Forgejo from backup once;
  6. migrate only after the mirror and restore are boring.

The current CI stays. It is useful even when it is advisory. The difference between “a check ran” and “a check blocked the merge” is exactly the gap Forgejo would close.

What would make me switch

  • required checks available without a plan upgrade;
  • a runner that can validate the GitOps repo reliably;
  • an ArgoCD repo credential that works from inside the cluster;
  • a tested backup and restore;
  • a clean way to keep GitHub as a mirror during the transition.

Until then, Forgejo is a planned experiment, not a migration.

Links

]]>