Landfall

Hand an issue to a crew of Duo agents and watch it land in production.

Comment

Inspiration

Shipping code is the easy part. After the code is written, the real work starts: planning, review, tests, security scans, a safe rollout, and a record of what happened. Teams do this by hand, and automation rarely explains itself.

We wanted an autopilot that does this work inside GitLab, explains every decision, and never asks for a cloud key.

What it does

Landfall is a crew of GitLab Duo agents plus a CI/CD pipeline. You write an issue and assign it to the Landfall flow. Then:

  • Scout (GitLab Duo agent) reads the issue, posts a plan with testable acceptance criteria and a risk score, writes the code and tests on a branch, and opens a merge request.
  • Warden (GitLab Duo agent) reviews the merge request against each criterion, checks the tests, and posts a verdict: ready for human review, or changes needed.
  • The pipeline runs tests, security scans (SAST, secret detection, dependency scanning), builds the container image, and deploys it to Google Cloud Run as a canary revision with no traffic.
  • Sentinel sends 60 requests to the canary. If the error rate stays under 2%, it moves traffic to the new revision. If not, it rolls back to the stable revision.
  • Release Passport: every landing ends with a one-page record of the plan, the review, the scans, the canary decision and an estimated carbon figure (SCI method). It is published on GitLab Pages.
  • Landfall Console: a web app where you sign in with GitLab, connect a project, hand an issue to Scout, and follow each landing from plan to live.

Scout and Warden never merge. A person still merges.

Architecture

 Developer
     |  assigns or mentions the issue
     v
+-------------------------- GitLab ------------------------------+
|  Issue --> Duo flow: Scout (plan, code)                        |
|              |                                                 |
|              v                                                 |
|         Duo flow: Warden (review, verdict)                     |
|              |                                                 |
|              v                                                 |
|         Merge request --> CI/CD pipeline                       |
|                             tests | SAST | secrets | deps      |
|                             build image                        |
|                             deploy canary (0% traffic)  ----+  |
|                             Sentinel: 60 requests           |  |
|                             Passport on GitLab Pages        |  |
+-------------------------------------------------------------|--+
                                                              |
+---------------------- Google Cloud (europe-north1) ---------|--+
|  Workload Identity Federation: GitLab OIDC token,           |  |
|     no stored keys                                          v  |
|  Artifact Registry: container images                           |
|  Cloud Run: landfall (canary, then 100% or rollback)           |
|  Cloud Run: landfall-console (Landfall Console web app)        |
+----------------------------------------------------------------+

How we built it

  • GitLab Duo Agent Platform: a custom flow with two agents, Scout and Warden, defined in one YAML file. Scout's final answer is passed to Warden with a router.
  • GitLab CI/CD: one pipeline for tests, SAST, secret detection, dependency scanning, image build, canary deploy, Sentinel, carbon, the Passport and Pages.
  • Google Cloud: Cloud Run for the demo app and the console, Artifact Registry for images, and Workload Identity Federation so GitLab gets short-lived Google credentials. No service account key is created or stored.
  • Console: a FastAPI app with GitLab OAuth (PKCE). It stores nothing. Projects, landings and Passports live in GitLab itself: pipelines are landings, and plans and reviews are issue and merge request notes.

Challenges

  • Right issue, right agent: our first Duo prompt let Scout treat the issue number as a merge request. We rewrote the prompt so it reads the issue first.
  • Keyless deploys: getting Workload Identity Federation right, with the right audience and attribute rules, took several attempts. No cloud key is stored anywhere.
  • Honest audit: we wanted every agent decision to be visible. The plan, review and Passport are all written where people already look.

Accomplishments

  • Scout and Warden ran end to end on a real issue (issue #2). Scout opened merge request !1 with the /version route and tests. Warden reviewed it: all five criteria met, verdict "ready for human review". Duo session 9637254.
  • A passing pipeline on the hackathon project, with 24 tests and the full set of security scans.
  • Keyless Google Cloud deploys to Cloud Run with canary and Sentinel promotion.
  • A live Landfall Console on Cloud Run.

What we learned

Agents are most useful when their output lands where humans already look: issues, merge requests and pipelines. A clear, deterministic pipeline is what makes agent work trustworthy.

What's next

More cloud targets, per-project policies, and richer Passport exports.

Built With

Share this project:

Updates

Submission history