gittan for dev teams

Feedback in your terminal

Pipeline output streams to your terminal during git push. Each step starts, runs, and completes — in real time, in the same window where you wrote the code. If something fails, you see the error immediately. No browser tab, no Slack notification twenty minutes later, no "let me check the CI."

The push does not return until the pipeline finishes. You stay in your editor. Fix, commit, push again. The feedback loop is seconds, not context switches.

Why pipeline results belong in the terminal →

Fast pipelines

Pipelines run in containers on warm runners with a persistent build cache. No fresh VM per run, no pulling images from scratch, no reinstalling your dependency tree every time. Steps that don't depend on each other run in parallel.

A typical run — install, typecheck, lint, test, build, publish — finishes in under two minutes. Fast enough that blocking the push is practical, not painful.

Why flow requires fast pipelines →

Gated commits

Every push to main runs the full pipeline — tests, type checks, security scans, whatever your org requires — before it lands. If the pipeline fails, the push is rejected. No review queues, no stale approvals, no merge conflicts from long-lived branches.

You can still review code within your team — push a branch, look at the diff together. But nobody has to approve before it ships.

Why gating is stricter than a PR →

Your team owns everything

Every repo belongs to exactly one team. If you are on the team, you have full access — push, configure, deploy. If you are not, you can read. No shared ownership, no CODEOWNERS file, no "who is responsible for this?"

Teams own everything. Individuals own nothing. →

Pipelines without config

Your platform team defines org-level policies that 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. Secret scanning and CVE scanning run on every push, enforced by the platform — nobody can skip them.

Most repos never need a .gittan.yaml. When you do need custom steps, add one — it overrides the org default for that repo.

The platform handles the boring parts

Registry credentials, npm tokens, container publish auth — the platform injects them automatically. Each pipeline run gets its own short-lived workload token, scoped to your org's images. The token is an Ed25519 JWT minted for that single run — it cannot be reused, it cannot be extracted from build output, and it expires when the pipeline finishes. You never paste a NPM_TOKEN into a CI secret. You never debug expired credentials at 4pm on a Friday.

Pipeline steps only receive secrets they explicitly declare — a test step cannot read your registry token, and a build step cannot read your Slack webhook URL. The platform enforces least privilege without any configuration from your side.

Secret scanning and CVE scanning are enforced by the platform on every push. You don't add security steps to your pipeline — they are already there, and nobody can skip them.

Work that is visible

gittan tracks deployment frequency, lead time, failure rate, and recovery time per team — automatically, from pipeline data. Your team dashboard shows what shipped this week, which repos are active, and where pipelines are failing. Nobody fills in a spreadsheet. Nobody writes a weekly update.

This makes progress visible to everyone — your team, your leads, your stakeholders. When work is visible by default, there is less need for status meetings and follow-up. Leaders can see what is happening without asking, and your team spends less time reporting and more time building.

Pipeline failures notify your team's Slack channel. You hear about it when it matters, not when someone remembers to check.

Team metrics →

Deploy hooks

Register a webhook on your org and gittan fires it when an image is published or code is pushed — HMAC-signed, with the event payload. The primary use case: point it at a Flux Receiver and your deploy triggers the instant the image lands in the registry, instead of waiting for the next poll interval. Measured result: seven seconds from push to running in the cluster.

Hooks support repo filters — subscribe to pushes on *-gitops repos only, or on a specific repo. The mechanism is general-purpose: trigger deploys, notify external systems, kick off downstream jobs. gittan's own platform uses the same hooks as every other org — there is no privileged internal path.

Provenance

Every container image published through gittan gets a SLSA v1 provenance attestation — automatically, no configuration needed. The attestation records which commit, which branch, which Dockerfile, and which builder produced the image. It is signed with a per-run ephemeral key and pushed to the OCI registry as a referrer linked to the image digest.

Verification is straightforward: the platform publishes its signing key at a well-known URL. Anyone — your deploy pipeline, an admission controller, an auditor — can fetch the key, pull the attestation from the registry, and verify that the image was built by gittan from the commit it claims.

Security is visible

Your team's security tab shows vulnerabilities across your repos right now — not a quarterly report, but a live view. Hardcoded secrets block the push. CRITICAL CVEs block the push. HIGH findings are surfaced for your team to prioritise — nothing is hidden, nothing is silently skipped.

Push to production

Gating means every push deploys if it passes. No manual deploy step, no release train. You push, it passes, it ships — with deploy hooks, seconds from commit to running in production.