Gitfence on your own servers
The same product as our hosted service, in your infrastructure. Your code, your GitHub App and your keys stay with you, and Gitfence never calls us.
What you get
One container, docker compose
A compiled build with no source tree. MongoDB and optional HTTPS come in the same bundle.
An offline license
A signed file, checked on your server. No license server, no outbound check.
No telemetry
Gitfence never calls us. Block everything but GitHub and it works the same.
Encrypted at rest
Mirrors and views in a kernel-encrypted folder, locked when nobody is using them.
Your own key
Seal the keys with HashiCorp Vault. Disable the Vault key and the code locks.
GitHub or GitHub Enterprise Server
github.com, Enterprise Cloud, or your own GitHub Enterprise Server 3.9 or later.
Fenced CI included
Contractors and their agents run your real tests in a sandbox with no network.
SSO and SCIM
SAML or OpenID Connect, and provisioning from your identity provider.
What you provide
- A Linux host, x86_64 or arm64, with Docker or Podman and the compose plugin.
- A DNS name and TLS: the bundled Caddy, or your own load balancer.
- Your own GitHub App, created in your organization by one command. Its private key never leaves your server.
- Outbound HTTPS to GitHub, and GitHub able to reach Gitfence's webhook.
- Optional: an identity provider, SMTP or Postmark, an S3-compatible bucket for backups, a Vault server.
The install takes 30 to 45 minutes for someone who knows Docker, most of it the GitHub App and DNS. In our clean-install rehearsal, the first contractor's pull request came 15 minutes of commands after loading the image.
Sizing
| Repository | Host | Disk |
|---|---|---|
| Up to ~50k commits, ~10k files | 2 vCPU, 4 GB | the mirror + ~0.4 GB per restricted person |
| Up to ~150k commits, ~30k files | 4 vCPU, 8 GB | the mirror + ~1 GB per restricted person and per group |
| ~500k commits, ~100k files | 8 vCPU, 16 GB | the mirror + 3–4 GB per restricted person |
Measured on the full Kubernetes history (163,000 commits). The first preparation of a group's view is the slow part and happens once per set of rules. Performance and sizing has the numbers.
The license
- A seat is a restricted person. Admins and full-access teammates are free; AI agents are not counted.
- Renewals are a new file, picked up within a day without a restart.
- An expired license or a full seat count never cuts anyone's existing access. It only stops adding new restricted people, after a 30-day grace.
Updates
- Versions are pinned. You upgrade when you choose: change the version, pull, start.
- Data migrations run at start and resume if interrupted. Roll back by restoring the backup taken before.
- Air-gapped installs load a signed image tarball instead of using our registry.
What we can and can't see
- Nothing at run time. Your server talks only to GitHub, and to your mail relay, S3 bucket and Vault if you use them.
- We hold the details of the license we issue: customer, seats, expiry.
- Support works from the logs and screenshots you choose to share.
Backups and alerts
Daily backups of the database and signed documents go to your own S3-compatible bucket, never to us, and contain no source code. Health checks and alerts go to your own email or webhook.
Every release is signed, with an SBOM, a vulnerability scan and a public ledger entry. The Trust Center shows how to check each one.
The build is compiled, minified JavaScript. It protects nothing by cryptography: our code is protected by the license agreement.
Run it on your own servers
Tell us about your repository and your environment. We'll send a license and the install bundle for a pilot.