Skip to main content
Private preview. fremforge is in private preview — invited customers only. Content is still subject to change. Request access →
Org admin
Repo mirroring

Repository mirroring

fremforge supports both pull mirroring (an external repository → fremforge, kept in sync on a schedule) and push mirroring (a fremforge repository → an external destination, mirrored on every push). Both directions use the underlying Forgejo mirror feature and run as scheduled background jobs.

Setting up a mirror

Pull mirror (external → fremforge)

When creating a new repository:

  1. Go to frem.sh/repo/migrate (or click “+” → “New Migration” in the topbar).
  2. Pick the source service: GitHub, GitLab, Gitea, Forgejo, Bitbucket, or Plain Git.
  3. Paste the source URL (HTTPS).
  4. Check “This repository will be a mirror” before clicking Migrate. Without this checkbox the import is a one-time copy, not an ongoing sync.
  5. Mirror interval defaults to 8 hours. You can change it on the repo’s Settings → Mirror Settings page after creation. Minimum interval is 10 minutes.

Push mirror (fremforge → external)

On an existing repository:

  1. Repo Settings → Mirror Settings → “Push Mirrors” section.
  2. Add the destination URL (HTTPS) and credentials (username + access token for the destination service).
  3. The mirror runs on every push to the fremforge repo’s default branch plus on the configured interval (8h default).

Supported source/destination hosts

The Git-protocol egress from fremforge’s Forgejo pod is gated through an allowlist (defense-in-depth against SSRF and data-exfiltration via mirror URLs). The following hosts are allowed today:

HostPull mirrorPush mirrorNotes
github.com (+ *.githubusercontent.com)✅✅Including GitHub Enterprise Cloud (*.github.com); GHES instances on customer-owned domains require an allowlist addition (see below).
*.gitlab.com✅✅GitLab.com SaaS. Self-hosted GitLab instances on customer domains require an allowlist addition.
*.bitbucket.org✅✅Atlassian Bitbucket Cloud. Bitbucket Data Center on customer domains requires an allowlist addition.
codeberg.org✅✅Forgejo-based community hosting.
dev.azure.com (+ *.visualstudio.com)✅✅Azure DevOps (modern + legacy hostnames).
code.forgejo.org✅✅Forgejo project’s own hosting.
gitea.com✅✅Gitea SaaS.
git.sr.ht✅✅SourceHut.

HTTPS only. SSH-based mirror URLs (git@<host>:owner/repo.git) are not supported today — fremforge’s Forgejo pod routes Git traffic through the HTTPS proxy, not direct port-22 egress. Use the HTTPS form of your source URL with a Personal Access Token if the source requires authentication.

Private network targets are blocked. RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local are rejected at the Forgejo layer regardless of allowlist. Mirroring from an internal corporate Git server requires that server to be reachable on the public internet via a stable hostname.

Adding a host to the allowlist

For mirror sources or destinations not on the list above (typically self-hosted GitLab / GitHub Enterprise Server / Bitbucket Data Center on a customer-owned domain):

  1. Email support@frem.sh with the hostname and a short note on the use case.
  2. We add it to the global allowlist within one business day (no per-customer scoping today — the host becomes reachable to mirror operations from all fremforge tenants).
  3. You can then configure the mirror as above.

Why we ask rather than letting you self-serve: the allowlist gate is shared across the cluster’s egress proxy. Per-tenant policy enforcement that would let each org admin manage their own allowlist is on our roadmap (Phase 2); until then, additions are operator-reviewed for the reason above.

Limits and characteristics

  • Pull mirror interval: 10 minutes minimum, 8 hours default, configurable per repo.
  • Push mirror trigger: on every default-branch push + on the configured interval.
  • Credentials at rest: Forgejo encrypts mirror credentials in its database (mirror passwords are not exposed to fremforge operators).
  • Mirror operations count toward the repo’s metering in the same way as normal Git operations.

Threat model + audit notes

  • Every mirror create/update/delete emits an audit event you can see at <org>/_admin/security/audit-log.
  • Mirror fetch failures (e.g. credentials revoked at the source) log as warnings in the repo activity feed. We do not page our oncall on customer mirror failures.
  • A push mirror with leaked credentials gives the destination service the ability to read your repo (and write if you configured push). Treat the access token like any other credential — rotate it if you suspect compromise; rotation steps are documented at the destination service.

See also