Pay for the people you fence. Your team is free.

Anyone whose access is less than everything in at least one repository: a folder or file set to No access, Types only or Can read. Each person counts once, however many repositories they're in. A member of a restricted group counts even if the restrictive rule doesn't match a file today. Admins and full-access teammates are free, and agents never count. Pro is billed for at least one restricted person.

No. An agent works for a person, with that person's access or less, and is never counted: you, your team and every restricted person can run as many as you like, on Free and on Pro. An account with no person behind it (a CI bot or an autonomous worker) that you restrict counts as one restricted person.

The first time you add or invite a restricted person, you get Pro free for 14 days. It starts by itself: no card, nothing to click. During the trial you can add as many restricted people and repositories as you need. There is one trial per organization and per owner GitHub account.

If you subscribed, nothing changes. If you didn't, you can't add or invite restricted people any more, and the ones you have keep cloning and pushing for 5 more days so no work is lost. After that their access is paused until you subscribe, and comes back exactly as it was. Your full-access team and the Free plan are never affected. We email your admins 3 days before the end and when it ends.

Pro is billed for at least one restricted person. If you have none, you're paying the one-person minimum, and Free (your own team and their agents, 1 repository) may suit you better.

You keep Pro for 14 days, and restricted people keep cloning and pushing. After that, you can't add restricted people or repositories, and access for restricted people is paused until you renew; it then comes back exactly as it was. Admins and your full-access team are never affected. (After a free trial that ends unpaid, the grace period is 5 days.)

Yes, from the billing portal. Adding or removing restricted people adjusts the subscription automatically, prorated.

SSO (SAML or OpenID Connect) and SCIM provisioning, audit streaming to your SIEM, a signed DPA, priority support and annual invoicing, Fenced CI, sizing help for large monorepos and a security review with your team. It can run on our hosted service or on your own servers. Email us to talk it through.

Yes, as part of Enterprise. You get a compiled build as one container image with a docker-compose install, licensed with a signed file that is checked offline. It never calls us: no telemetry, no license server. Your code and keys stay with you, optionally with your own HashiCorp Vault key. See self-hosted Gitfence.

Yes. Our data processing agreement (GDPR Article 28) covers every plan. Email [email protected] for a countersigned copy.

No. GitHub stays the source of truth, with your CI, reviews, bots and branch rules. Only restricted people and their agents get a different clone URL. Their pushes arrive as ordinary pull requests that your team reviews on GitHub.

No. Hidden paths are absent from every commit of their view, and the objects never exist in the repository served to them. We test shallow clones, partial clones (--filter), --mirror and direct requests for hidden object IDs on every change. See Security for the full list.

Two ways. Types only gives them the API without the implementation: TypeScript declarations, or Go and Python stubs that compile, so imports resolve and the project builds and type-checks. Fenced CI runs your real test suite on the full code in a sandbox with no network, and returns redacted output or just pass/fail. Fenced CI runs today when you self-host; on our hosted service we set it up with you.

Yes. Agents use plain git, so any agent works. Each view also contains an AGENTS.md / CLAUDE.md section explaining the fence, and an MCP server lets agents check paths, run tests and request access. In our recorded run, Claude Code finished a task in a fenced repo without trying to recreate the hidden code.

Their history moves forward with a commit called Gitfence: access updated that adds or removes files. git pull still fast-forwards. Nobody has to re-clone and nothing is force-pushed.

No, and no tool can. Gitfence controls what someone can see from the moment you fence it. Fence before you invite, and require an NDA before the first clone.

Go, Python and TypeScript. TypeScript gets generated declarations; Go and Python get stubs at the same path that keep every exported type and signature, with bodies that panic or raise and every constant value replaced, so go build and Python imports still work. Other files under a types-only folder (JSON, SQL, .env and so on) are simply hidden. No access, Can read and Can edit work for any file in any language.

Yes. We tested it on the full Kubernetes history: 163,380 commits and 31,600 files. The first setup is the slow part and happens once: preparing a group's view took 33 minutes and a person's first clone about 7 minutes, on two CPUs. After that, fetches take under 5 seconds and pushes about 3. See performance and sizing.

No. SOC 2 and an independent audit are on our roadmap. Until then we publish what we test and what we don't on the security page, including known limits, and answer security questionnaires. The Trust Center shows how to check our releases yourself. If you need everything on your own servers, Enterprise can be self-hosted.