gittan for platform engineers

Everything is already per team

Every repo belongs to a team. Every pipeline runs in a team context. Every metric and security finding is scoped to the team that owns it. You do not bolt this on later with naming conventions or labels — it is the data model.

No dashboards to build. No alert-to-owner mapping. The structure is there from the first repo.

OIDC and team membership

No passwords. Each org connects its own identity provider — configure an OIDC issuer, client ID, and optionally enforce SSO for an email domain. Team membership follows from the provider's group claims. When someone joins a group in your IdP, they have access in gittan. When they leave, access is revoked. No manual provisioning, no sync scripts.

Service accounts for CI and automation use OAuth2 client_credentials grants — machine-to-machine tokens scoped to an org, with no human login flow.

Org-level pipeline policies

Define policies that inject mandatory steps across the entire org — security scanning, linting, compliance checks — that teams cannot skip or override. Two modes: enforce (always runs, nobody can skip) and default (applies unless the repo overrides with its own .gittan.yaml).

Policies match repos by file pattern: a repo with pnpm-lock.yaml gets install, typecheck, lint, test, and build. A repo with Dockerfile gets a container publish. Steps run before or after the team's own pipeline, and you can gate steps to specific branches — deploy only on main, lint on everything.

Pipelines and policies →

Secrets

Three scopes — org, team, repo — where narrower overrides broader. Set DEPLOY_KEY at the org level and every pipeline gets it. Override it on a specific team or repo when that team needs a different value. Encrypted at rest, decrypted only at pipeline dispatch time.

Pipeline steps only receive secrets they explicitly declare in their secrets: field — a test step cannot read registry credentials, and a build step cannot read your Slack webhook URL. Least privilege without per-step configuration from the team.

Workload identity

Each pipeline run gets an ephemeral Ed25519 workload token — a JWT minted for that single run, scoped to the org's registry namespace. Registry credentials, npm tokens, and container publish auth are injected automatically. No static CI credentials to rotate. No shared tokens across repos.

The workload token cannot be extracted from build output — it is filtered from build args and container layers. When the pipeline finishes, the token is no longer valid.

Deploy hooks

Register HMAC-signed webhooks on your org that fire on two event types: image-published (a pipeline published a container image) and push (code was pushed to a matching repo). URLs are validated against SSRF before the first delivery. Secrets are returned once at creation, never echoed back.

The primary use case: point an image-published hook at a Flux Receiver (generic-hmac) and deploy triggers the instant the image lands, not at the next poll interval. Measured: seven seconds from push to running in the cluster. Push hooks support repo filters — subscribe to *-gitops repos for instant GitRepository source syncs.

gittan's own platform uses the exact same hook mechanism — there is no privileged internal path. What you configure is what we run on.

Provenance

Every container image published through gittan gets a SLSA v1 provenance attestation — automatically, enabled by default. The in-toto statement records the commit, branch, Dockerfile, and builder. It is signed with the run's ephemeral key and pushed to the OCI registry as a referrer linked to the image digest.

The platform publishes its signing key at /.well-known/provenance-key.pem. Your admission controller, deploy pipeline, or auditor can fetch the key, pull the attestation from the registry, and verify the image was built by gittan from the commit it claims. No Sigstore dependency, no external transparency log — verification is self-contained.

Supply chain security →

Dependency graph

Repos can declare dependencies on other repos in .gittan.yaml. The dependency graph is visible per org — you see which repos depend on which, and what the blast radius of a breaking change looks like. When a team is about to change a shared library, they can see who consumes it before they push.

Security scanning

Secret scanning (gitleaks) and CVE scanning (trivy) are platform-enforced policies — mode enforce, on every push, nobody can skip them. Hardcoded secrets block the push. CRITICAL CVEs block the push. HIGH findings go to the team's security view — scanned, tracked, visible, but not blocking. Orgs can temporarily override CRITICAL blocking in emergencies via a time-limited bypass.

Notifications and audit

Pipeline failures notify the team's Slack channel — configured at org level, routed per team. Five-second batching, sixty-second cooldown per repo to avoid noise. No per-repo webhook setup.

All org-level actions are written to an audit log — member changes, secret operations, policy updates, SSO configuration. Queryable per org.

Team metrics →