We're in closed beta. Sign up for early access — founding pricing locks in at signup, for as long as your subscription stays active.
Enterprise readiness
Checked against the code and our operating records on 2026-10-24. A state moves only when the evidence does.
Priority 1
First in line, because it is what a security review asks for first. This is what exists today and what is measured, with the limits next to each item.
Organizations configure SAML or OIDC single sign-on themselves, with domain verification and optional enforcement.
Limits: Enforcement needs a verified domain, an enabled configuration and an active Enterprise entitlement. Owner and admin roles keep a break-glass exemption from enforcement.
Organization owners can require two-factor authentication, restrict access to listed IP ranges, set session and idle limits, and restrict which SSH key types members may use, with an announced transition before a tightening takes effect.
Limits: The IP allowlist is per organization; there is no platform-wide allowlist. Deploy keys are exempt from the IP allowlist because automation has no stable address list. An SSH key restriction applies to the member account, so it also affects that member’s SSH access to repositories outside the organization.
Sign-in configuration, provisioning, membership, repository-governance and security-policy changes are written to an organization audit log that can be exported and streamed to the customer’s own SIEM. Repositories also record selected git transport events such as rejected pushes and denied access.
Limits: High-volume transport events (private reads, deploy key use, denials) are kept at repository level and archived after a retention window; they are not streamed to the organization SIEM. Accepted history rewrites are not audited.
Required approvals, CODEOWNERS enforcement, stale-approval dismissal and required status checks gate the merge, per repository.
Limits: Checks come from external CI over the commit-status API; there are no built-in runners.
Repositories and the database are backed up hourly to a separate provider, the database is also archived continuously for point-in-time recovery, and large files are copied hourly with a retained history. On 2026-09-30 a full restore drill and a point-in-time database recovery were run against real data: the logical restore took about a minute end to end and the point-in-time recovery between about 22 seconds and about 68 seconds.
Limits: Those numbers come from a small pre-launch dataset (469 MiB, 20 repositories) and are a lower bound, not a prediction for production scale. Our internal target is data loss of at most 1 hour; it is a target, not a guarantee, and not an SLA. We do not publish a restoration-time target. Point-in-time recovery of the database depends on an encryption key held outside the server; without it recovery falls back to the hourly dump. Time to provision a replacement server and to switch traffic over is not included and has not been drilled.
The drill procedure and tooling exist and have been run. The documented cadence is quarterly.
Limits: The last drill on record is 2026-09-30 and the next quarterly drill is due in October 2026. An accountable operator and a standing schedule are an ownership decision that has not been recorded as made.
The platform runs on a single server with independent backups. A staged plan to move to managed database and cache services and then to more than one application node is written down.
Limits: A single server is not highly available, and we do not describe it as such. The plan needs infrastructure spend that has not been approved, so it has no date.
A third-party penetration test and a SOC 2 Type I assessment are planned. An internal readiness checklist maps our controls to the SOC 2 criteria.
Limits: No provider has been engaged and no date has been set for either. The checklist is preparation material, not an audit report. We hold no SOC 2, ISO 27001 or other certification.
A public status page reports measured availability of the project-management journey.
Limits: Other areas are not yet measured. We do not offer an uptime commitment or service credits. A contractual commitment needs demonstrated whole-system capability first.
Priority 2
SCIM is the second program, started after the security and recovery work above and planned separately from it.
Enterprise organizations generate a SCIM token themselves and connect their identity provider. Users can be provisioned, looked up, listed, deactivated and reactivated, and groups can be created and listed with their membership managed to map to roles.
Limits: The owner role can never be changed, deactivated or reactivated through SCIM. Administrators are managed by SCIM (a group such as Admins grants the admin role), with a guard that refuses to remove the last administrator. We do not claim compatibility with a named identity provider until it has passed acceptance testing.
The follow-on program would close the gaps we know about: replace-style updates and deletion, the standard discovery endpoints, group membership as a true member list, and acceptance testing against named identity providers.
Limits: Today PUT and DELETE answer “not supported, use PATCH”, there are no discovery endpoints and no bulk operations, and a group’s members are the people who currently hold its mapped role. Accounts are deactivated, never deleted, by SCIM. No date is set.
Priority 3
These are not built. They are considered when a concrete customer requirement justifies the work.
There is no self-hosted or single-tenant deployment. The git service is already separate from the rest of the platform, which makes a packaged deployment feasible, but feasible is not shipped.
Limits: Considered when a customer with concrete requirements asks. No date, no commitment, no pricing.
The organization-level allowlist above is shipped. A platform-wide allowlist that applies independently of any one organization is not built.
Limits: Considered with the same trigger as self-hosted.
Capability inventory
Static site hosting and a package or container registry often appear on enterprise checklists. For this release they rank below the security controls, recovery evidence, abuse protection and pricing clarity above, so they are out of scope: nothing is being built for them in this release and we are not promising a date. If either is a requirement for you, tell us; that is the signal that moves it up.
| Capability | Today | Notes |
|---|---|---|
| Git hosting with pull requests, releases and Git LFS | Available | Public and private repositories over HTTPS and SSH. |
| Pages-style static site hosting from a repository | Not available | Outside this release. The rendered README and the built-in wiki are not static site hosting. No implementation exists and no date is set; whether to build it later is a separate product decision. |
| Package registry and container registry | Not available | Outside this release. Releases are tag-based and are not a package registry. No implementation exists and no date is set; whether to build it later is a separate product decision. |
| Built-in CI runners | Not available | External CI reports status through the commit-status API. |
| Self-hosted or private-cloud deployment | Not available | Demand-gated, see above. |
Tell us your requirement and your review process. A concrete need is what moves a demand-gated item. For the controls themselves, see the security page.