We operate what we advocate.
GitOps.dk is delivered on the model we design for others. This website is the reference implementation: the same review gates, supply-chain controls and evidence generation we specify for enterprise platforms, running on our own production workload.
We do not publish customer names, sector experience or performance figures we cannot attribute and evidence. Measurements are published only with an agreed scope, baseline, method and measurement window.
- 01Changebranch
- 02Pull requestreview + checks
- 03Mergeprotected main
- 04Releasefounder tag
- 05EvidenceSBOM · provenance
- 06Signaturecosign key
- 07Imageby digest
Live on this site today.
Each control below operates on this website’s own delivery and runtime. We walk through the repository, the pipeline and a release’s evidence set in an architecture conversation.
Change control
Reviewed changes
Every change to this site travels through a pull request with required checks and human review. Direct pushes to the main branch are refused.
Verification gate
Lint, type checks, regression tests and a production build run on every pull request and must pass before a merge is possible.
Supply chain
Secret scanning
The full repository history is scanned for secrets on every pull request and on a weekly schedule.
Dependency scanning
Locked dependencies are scanned for known vulnerabilities. Critical and high findings with an available fix block the change.
Image scan gate
Every container image is built and scanned before it can be published. Findings with a fix fail the build.
Reproducible toolchain
Every tool version is pinned and locked. Engineers and the delivery pipeline run identical commands from the same definition.
Release evidence
Evidenced releases
Each release ships a checksummed artefact, a software bill of materials (SPDX) and a SLSA provenance record describing how it was built.
Signed artefacts
The image, the artefact and the checksums are signed, and the provenance is attested, with a key whose public half is published on this page.
Immutable references
Images are published by digest. The digest, never a mutable tag, is the release's deployment reference, so what was scanned and signed is what is referenced.
Runtime
Build identity
The site reports the exact version and commit it is serving, so a running deployment can be checked against its release.
Security headers
A strict, per-request Content Security Policy, strict transport security and frame denial on every response — verifiable from any browser.
Privacy by design
No cookies, no third-party scripts and no tracking. Server logs are privacy-preserving, and retention periods are published.
Architecture
Decisions on record
Durable architecture decisions are recorded as decision records beside the code, with the alternatives that were considered and rejected.
Two things you can check without asking us.
The build serving this page identifies itself, and the key that signs every release is public. Everything else — the repository, the pipeline runs, the release evidence — we show in person.
Build identity
This page is served by version 0.4.0, commit ecdd79845355. The same answer is available to any monitor at /api/health.
Release signing key
Every release image, artefact and checksum file is signed with a key held off the pipeline. The public half is published here so a signature can be verified independently.
/pki/cosign.pubA control loop you can operate.
Press ~ anywhere on this site to open the operator console. It boots with three drifted resources and asks you to reconcile them the way an autonomous platform would: inspect the live state, compare it with what Git declares, and correct the declaration rather than the machine. It is a working model of the principle, not a customer system.
The console keeps one value in your browser’s local storage — its autonomy level — and sends nothing anywhere. See the privacy notice.
Want to see the repository and a release’s evidence set?
We walk through both in the first conversation.