TruStacks is officially in Beta

TruStacks is officially in Beta, and it is open to the first 50 teams, free for 45 days with no card needed. TruStacks is AI delivery governance: the control layer between the people and AI that write your software and the systems that run it. Its agent crew reads your repository, your framework and your deployment target, writes the delivery pipeline, and proposes it as a policy-checked pull request that a human merges.

Getting here took a few years of back and forth, and more than one shift in the market underneath us. We're happy to finally say it out loud.

Why we built it

We built TruStacks so we would never have to worry about pipelines again.

Every team we've worked on, and every team we've worked with, did the same thing. A new service shows up, and someone writes its pipeline from scratch. Build, test, scan, containerize, deploy. The same decisions, made again, slightly differently each time, by whoever had the afternoon free. Then the pipeline needs care for as long as the service lives.

We were tired of re-inventing the wheel.

And the wheel is spinning faster now. AI and humans are pushing code to production at a pace nobody's delivery process was designed for. More code means more changes to govern, and the old answer (a review board, a manual gate, a release train) turns speed straight back into waiting.

So we built a governance platform that works where the rubber meets the road: in the pull request that changes how your software gets delivered.

What it does

Your developers, and their AI assistants, keep writing the service. TruStacks determines how it gets to production, built to your organization's workflow, best practices and signals. It understands three things about each service: your repository, your framework, and your deployment target. From those, the crew writes what you would otherwise write by hand.

1. 1

   It reads

   • Your repository

     The service you want delivered, through a GitHub App.

   • Your framework

     Python (FastAPI), Java (Spring Boot), Go, or .NET 8, and the runtime version.

   • Your deployment target

     Kubernetes or ECS on Fargate, and whether it is dev, uat, or prod.

   • The rules in force

     The signed constitution and the policy packs you run.

2. 2

   It writes

   • A CI workflow

     GitHub Actions: build, test, scan, push the image.

   • A Dockerfile

     For the framework and runtime it detected.

   • Deployment config

     A Helm chart and ArgoCD Application, or an ECS task definition and deploy workflow.

   • The next image tag

     When a new build lands, the bump is proposed too.

3. 3

   You get

   • A pull request

     Checked against the policy before it opens. A denied change never becomes one.

   • Rule citations

     The body names the rules it satisfies, with blast radius and rollback.

   • Your merge

     A named human approves. Your ArgoCD or your workflow deploys it.

Your pipelines become pull requests you review, not YAML you babysit. When a new build lands, the crew proposes the new image tag the same way, so even a routine promotion goes through the same check and the same human approval as everything else.

In Beta, that means GitHub repositories and GitHub Actions; Python (FastAPI), Java (Spring Boot), Go and .NET 8; and Kubernetes with ArgoCD, or ECS on Fargate (itself in Beta). The pipeline generation page lists the rules each generated file has to pass.

Where the governance comes in

Writing pipelines faster isn't the point on its own. Plenty of tools will generate YAML. The point is that every change the crew proposes is checked against your rules before anyone is asked to look at it.

Before a human is involved

1. 1

   Verify the bundle

   An init container pulls the policy bundle as a signed OCI artifact and checks its signature. If verification fails, the runtime never starts.

   cosign verify

2. 2

   Read the rules

   The crew reads your repository, your environment profile, and the index of every rule currently in force, before writing anything.

   rule_index

3. 3

   Emit an artifact

   The DevOps Engineer produces the workflow, chart, and Application your stack needs. At this point it is a candidate, proposed to nobody.

   ci.yaml · Chart.yaml

↓

4

The policy gate

opa eval data.proposal.deny

Three layers are evaluated together. Each may only tighten the one above it.

• Constitution

  ours, non-waivable

• Specialist packs

  SOC 2 today

• Your overlay

  yours, tightens only

✗Denied

Returns an object carrying the rule_id that objected, so the agent knows exactly what to fix.

↺ Back to step 3. No pull request is created.

✓Passes

Every rule in force was satisfied, and the change carries the list of which ones.

↓ Crosses the line below.

Nothing crosses this line unevaluated

What a human sees

1. 5

   The pull request opens

   The body cites the rules the change satisfies, so a reviewer starts from what was already checked rather than from scratch.

2. 6

   A named human merges

   The mechanical questions are answered, so their attention goes to judgement. No configuration flag skips this step.

The argument is the position of step 4, and the arrow that goes backwards. A change that violates policy never becomes a pull request someone has to argue about. It stops there, with the rule that denied it recorded. By the time a person is involved, the only questions left are the ones a person is actually better at.

A few things that follow from that, all of them true on the hosted Beta today:

• A denied change never becomes a pull request. The policy gate runs first. If a rule objects, the change goes back to the agent with the rule's id, and you never see it.
• Every pull request shows its work. The body names the rules it satisfies, the blast radius, and how to roll it back.
• Your AI agents don't get merge rights. A named human merges. There is no setting that turns that off.
• No production credentials in agent hands. The crew opens pull requests. Your ArgoCD, or your deploy workflow, ships what your people merged.
• Your developers' changes count too. The same signed rules audit the Dockerfiles, CI workflows and ECS task definitions already in your repository, whoever wrote them, a person or their AI assistant, and raise what they find. Today that's a finding, not a blocked merge; gating your own pull requests on the same rules is the next piece we're building.
• Signals from the tools you already run. Findings from Dependabot, GitHub code and secret scanning, or any scanner's SARIF file land in one place, and a fix goes through the same policy gate and the same human approval as everything else.
• Production is protected by what it is, not what it's called. Declare a target as prod and the production rules apply, whatever the cluster's name.
• The rules are public. The constitution every proposal must pass is open source, signed, and runs on stock OPA. Read the rules before you buy the product.
• Audit evidence is a side effect. The SOC 2 specialist agent is included, and the product can export the change record it already keeps as a SOC 2 evidence report.

We're looking for 50 teams

The Beta is open to the first 50 teams. Sign up with the Beta link and it's free for 45 days, with no card needed. Setup takes about 30 minutes: you install one runner in a Kubernetes cluster you control (a laptop cluster is fine for a first run), connect a service repository and a platform repository, and bring an Anthropic or OpenRouter API key. The hosted quickstart walks you through every step to your first governed pull request.

What we ask in return is honesty. Put it on a real service. Tell us where it breaks, where it's slow, where it got your stack wrong, and what you expected it to do that it didn't. This is a Beta, and some edges are still sharp; the quickstart names the ones we know about.

You can reach us at support@trustacks.com, or request to join our Discord, where Beta support happens.

Agents propose. Policy decides. Humans approve. We'd love your help proving it.