Your Stack

Your Stack is our developer platform. It is a Backstage portal extended into a single pane of glass over your continuous delivery, with cryptographic supply chain assurance enforced underneath it.

We run our entire business on it, every day. That is the whole reason we are willing to put our name on it — we are not reselling somebody else’s platform, and we are not shipping you something we don’t depend on ourselves.

It does two jobs that are usually sold separately, and they belong together.

One: make delivery boring

GitOps means treating Git as the single source of truth for your environments and applications. Every change is logged, versioned and auditable. No drift, no guesswork, no one asking which box the config actually lives on.

The value is not really the automation, it’s the cognitive load coming off your engineers. Deployment stops being a thing people do carefully and becomes a thing that happens. Teams get to focus on shipping instead of wrangling infrastructure, and they can experiment freely in near-production-ready environments because rolling back to a known good state is instant rather than an incident.

That matters more than it sounds. The commonly cited figure is that most engineers lose eight hours or more a week to inefficient workflows — a full day per person, every week, that you are already paying for.

Pragmatic GitOps, not the textbook version

We are deliberate about this: GitOps is a journey, not a big bang. The idealised model tends to break down where it meets actual humans, and a phased introduction stops the whole thing collapsing under its own purity.

So the portal keeps people in the loop where people belong. Engineers manage catalogs through a UI instead of hand-editing scores of YAML files. Automation gets introduced progressively, targeting the highest-friction areas first — and undoing the flaky “shadow CD” practices that accumulate when continuous delivery tooling gets quietly used for deployment tasks it was never meant to do.

A survey at KubeCon Paris ‘24 found 67% of GitOps practitioners advocate this pragmatic approach over the doctrinaire one. We were already doing it, but it is nice to have company.

Two: prove what you shipped

Modern software isn’t built, it’s assembled. A typical enterprise application pulls in hundreds — sometimes thousands — of third-party components: open-source libraries, container base images, language runtimes, build tools. Each one is an attack surface you did not write.

The exposure is not theoretical. 75% of organisations experienced a supply chain attack across 2023–24, roughly 30% of supply chain breaches involve a third-party actor, and the global average cost of a supply chain breach sits around $4.4M.

Modern applications rely on third-party libraries for 79% of their code. SBOMs alone are not enough — attestations are crucial for ensuring software integrity.

OpenSSF Summit 2025

So every deployment needs cryptographic proof that what you are shipping is exactly what you think you are shipping, unchanged from source to production. Each CI step — build, test, scan — emits an attestation. Human approval in the portal emits one too. SBOMs give you complete component inventory, signatures chain the artifacts together, and Sigstore’s transparency logs make the certificate chain verifiable.

Then the part that actually matters: when ArgoCD updates the cluster, Kyverno pulls the SBOM and the full attestation set and validates them at the admission boundary. If the proof doesn’t hold, the workload does not deploy. Not a warning, not a dashboard item — it doesn’t deploy.

Green means go

Here is the bit we are most pleased with. Deploying software is a business decision, so your approvers should not need to read certificate chains to make it.

They see five checks — SBOM, provenance, vulnerability, SAST, signature — and each one is green or it isn’t. If any fails, the deployment stops. No ambiguity, no exceptions, and no ability to merge a workload that doesn’t meet standard, because the guardrails are in the UI as well as the cluster.

The important property is that these are not decorative. The identical cryptographic requirements that render that interface are what Kyverno enforces at your cluster boundary — same attestations, same signatures, same standards, checked automatically and continuously. There is no gap between what a human approved and what is protecting production.

Your teams end up understanding your business processes instead of cryptographic signing technology. Your managers approve releases instead of validating signature chains. And you can expand how deeply you validate over time rather than deciding everything up front.

What it looks like on a Tuesday

Starting something new. An engineer picks a templated project in the portal. The repository is created, the service catalog updated, a working container published. Continuous deployment notices the catalog change and publishes the service into development, where the synced state can trigger test suites or anything else you want hanging off it. Setup goes from days to minutes, and every project starts with your standards already in it.

Changing something that’s running. The engineer requests the config change through the portal. For protected environments a human approves, and that approval is itself recorded as an attestation. Dependent attestations are accumulated, an SBOM and attestation set is built and pushed to your registry, and admission control verifies the lot before anything lands.

Same portal, same proof chain, whether it’s a new service or a replica count.

Three phases

Foundations. Catalogue your technology assets, integrate version control and identity, get basic technology and people discovery working. This is the phase where organisations find out what they actually have and who owns it, which is more often a surprise than it should be.

Automation. Container publish events trigger deployment to lower environments via ArgoCD or FluxCD. New projects initialise from standardised templates. Delivery stops depending on the person who knows the runbook.

The pane of glass. Catalogs managed through custom portal panels — workload configuration, promotion between environments, environment testing — plus event-driven CD reacting to what happens in your pipelines. This is where governance stops being a meeting.

And you keep it

Your Stack is licensed as part of the three phase engagement, and it is yours. The licence is yours, the customisation is yours, and if you want us gone the thing keeps running.

A platform you cannot leave is just a different kind of dependency, and we would rather be retained because we are useful than because you are stuck.

You also don’t need it to work with us — we would rather say that plainly than have you waiting for the platform pitch. What we would say is that the sequence matters, because each phase answers a question the next one depends on.

The full detail, including how project initiation and policy-driven deployment work end to end, is on the Your Stack page.