Solutions · Pipeline generation

Stop hand-writing pipelines. Review them instead.

TruStacks reads your service repository, detects the framework and runtime, and proposes the CI workflow and Dockerfile the service needs as a pull request against your platform repository. Every proposal is checked against the constitution before the pull request exists, and a person on your team merges it. Your DevOps engineers stop retyping the same YAML for every new service and spend that time on the review only they can do.

What the crew writes

The boilerplate, proposed. The judgment, yours.

The CI workflow

A GitHub Actions workflow that builds, lints, and tests the service with the commands its framework actually uses, with every third-party action pinned to a commit.

The Dockerfile

A container build for the detected runtime that does not run as root, so the image your cluster pulls starts from a sane default instead of a copied snippet.

The pull request body

A summary, the blast radius, how to roll it back, and the constitution rules the change was written against. Written for the reviewer, and the same record an auditor asks for.

The crew detects Python (FastAPI), Java (Spring Boot), Go, and .NET 8 today. It reads your platform repository before it writes anything, so the customizations your team already made are preserved rather than overwritten, and every pull request notes what it kept.

Checked before you see it

A pipeline that fails the rules never reaches review.

Generated is not the same as trusted. Before a proposal becomes a pull request, it is evaluated against the constitution, the policy bundle we publish and you can read. A denied proposal never opens; the denial is recorded with the rule that caused it. These are some of the rules a pipeline has to pass:

practice.workflow_pins_action_versions
Every third-party `uses:` action in a workflow pins to a SHA, not just a tag.
practice.workflow_has_test_step
Every CI workflow declares a step that runs the test suite.
practice.workflow_has_lint_step
Every CI workflow declares a lint or static-analysis step.
practice.dockerfile_runs_as_nonroot
Every Dockerfile in the proposal declares a USER directive other than root.

Read every rule, and run its tests yourself, in the public trustacks-policy repository.

Today, and where it is headed

GitHub Actions now. Your CI next.

Today the crew works against GitHub repositories and writes CI as GitHub Actions workflows. You can already declare GitLab CI, Azure DevOps, Jenkins, or Tekton in your environment profile, and the crew grounds its recommendations in what you declared, but it does not write configuration for those yet. That is the direction: the policy and the pull request stay the same whichever CI runs the result.

Point it at a service. Review what comes back.

Hosted Beta signup is open, capped at 100 teams. Create your workspace at app.trustacks.com, and the hosted quickstart walks you to your first governed pull request.