Postcode

Postcode turns every GitLab issue into a parcel that GitLab Duo agents carry through all 9 DevSecOps stages, from work order to merge request, scans, review and proof of delivery.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learnedInspiration

Writing code is no longer the hard part. An agent can open more merge requests in a morning than a small team can review in a week. What's left is everything after the code: review, security triage, packaging, release notes, deploys, canaries, rollbacks and the audit trail. On a team of three, that work either lands on one tired maintainer or quietly doesn't happen.

We didn't want a smarter code generator. We wanted a delivery service: you hand over a parcel, it passes through every station it needs, and someone signs for it at the door.

What it does Postcode turns every GitLab issue into a tracked parcel with a tracking number. Nine stations, one for each GitLab DevSecOps stage, carry it toward production:

Plan, Sorting Office. A Duo flow fires when an issue is created and writes a work order: acceptance criteria, plan, tests, changelog type. Create, Courier. It implements the change, runs lint and tests, and opens a merge request. Verify, Inspector and Mechanic. CI runs the tests. The Inspector reviews the change against the acceptance criteria and posts a verdict. If the pipeline breaks, the Mechanic reads the logs and pushes a fix. Package. Container image, CycloneDX SBOM and a Sigstore signature. Secure, Customs. GitLab's SAST, secret, dependency, container and IaC scans. Customs fixes real findings and explains false positives. Release. A semantic version, generated notes and a GitLab release. Configure. OpenTofu with GitLab-managed state, for staging infrastructure. Monitor, Night Watch. A canary judged against the SLO. If it fails, traffic rolls back, an incident opens, and the Night Watch opens a revert. Govern, Notary. Every gate decision goes into an autonomy ledger. The Notary posts a proof of delivery on the original issue and closes it. The requester opens an issue and walks away.

How we built it GitLab Duo Agent Platform. Six custom flows with ten agents, each with a scoped toolset: the Inspector and Notary can't write code, and the Sorter can't touch the repository. Prompt-injection guards and a dedicated service account per flow. A read-only MCP server, so Duo Chat can answer questions like "where is PC-0042-K7?". Postmaster. GitLab doesn't let flows start flows, and AI sessions can't merge. We kept those rules. Postmaster is a small FastAPI control plane outside the agent sandbox, live on Render. It: receives secret-verified webhooks and CI evidence signed with GitLab OIDC; evaluates a deterministic merge gate; starts the next flow through the Flows API; merges only the exact commit it evaluated. Earned autonomy. .postcode/policy.yml scores each change's risk from its size, sensitive paths, findings, review verdict and tests. Low risk ships hands-off. High risk waits for one human signature. No model output decides how much freedom a change gets. Editing the policy itself always counts as high risk. Pipeline. One .gitlab-ci.yml covers tests, five security analyzers, the image, SBOM, signing, gate evidence, release, OpenTofu, canary and rollback. Tracking site. A parcel board, plus a timeline for each parcel across the nine stations. Each gate decision with its risk factors. A carbon receipt per change, and a ledger with DORA metrics. Quality. 70 tests at 86% coverage, including replays of real GitLab webhook payloads. A CI validator checks every flow against GitLab's custom-flow rules. Challenges we ran into Chaining agents inside GitLab's rules. Our first design had flows triggering each other, which GitLab forbids. Moving orchestration into Postmaster gave a cleaner split: agents make judgements, deterministic code makes decisions. Out-of-order events. Webhooks retry and arrive in any order. Gate decisions are idempotent for each pipeline, and evidence only counts if it belongs to the current one. Endless repair loops. Agents could fix each other's fixes forever. A repair budget in the policy escalates to a human after three attempts. Hosting under deadline. Google Cloud billing didn't activate in time, so we shipped Postmaster on Render from the same Dockerfile. The Cloud Run setup is written in OpenTofu, ready to apply. Accomplishments that we're proud of A real issue in our project was triaged by the Sorting Office, implemented in a merge request, and passed a ten-job evidence pipeline across verify, secure, package and govern. The Inspector agent then reviewed it. Six Duo flows run under their own service accounts, each limited to the tools it needs. The same system runs assisted, supervised or hands-off for each change, decided by a written policy rather than a toggle. A carbon receipt for every change, following the Green Software Foundation's SCI method. What we learned The interesting question isn't "can an agent do this step?" but "who is allowed to decide this step is done?" Separating judgement (agents) from decisions (a deterministic gate with a written policy) made the system both more autonomous and easier to trust.

What's next for Postcode Deploy to Google Cloud Run and run the full loop through canary and the Notary's proof of delivery. Per-team policies, plus policy simulation ("what would last month look like under this policy?"). Learning risk weights from the ledger, so rollbacks raise a path's risk automatically. Packaging Postmaster as a GitLab CI/CD catalog component so any project can adopt it.

What's next for Postcode

Built With

Share this project:

Updates

Submission history