Broccoli: The Agent That Turns Linear Tickets Into PRs Without Your Code Leaving Your Cloud
There’s a silent assumption baked into most of the cloud coding agents that showed up this year: that you’re comfortable handing over your repo, your tickets, and your API keys to someone else’s control plane. You assign a task, it runs somewhere, and back comes a PR. Convenient. And for many teams operating under compliance restrictions or NDAs, straight-up impossible.
Broccoli, which just landed on Show HN, bets the other way. Same outcome—ticket in, reviewable PR out—but the entire pipeline runs inside your Google Cloud project, against your Postgres, with your keys. No third-party control plane. Nothing leaves your tenancy.
That single architectural decision is what makes it worth your attention.
How the Loop Works
The trigger isn’t a CLI command: it’s a Linear ticket. You assign an issue to the Broccoli bot, and it reads the ticket context, plans an implementation, writes the code, runs review loops, and opens a pull request for someone on your team to inspect. The async model is the point: you describe the work where you already describe the work, and the PR shows up while you’re doing something else.
What’s interesting is that Broccoli runs on Claude and Codex, and pits them against each other. On each PR, both models read the diff, leave actionable comments, and push fix commits when you ask them to. It’s less “an agent writes code” and more “a small team of agents discusses the code before a human signs off on it”.
The Architecture Is the Thesis
This isn’t a toy wrapped in a landing page. Underneath, it’s a FastAPI service that receives webhooks from GitHub and Linear, verifies signatures, dedupes deliveries, and creates durable job records. Execution runs as a Cloud Run Job by default—or, optionally, inside Blaxel sandboxes if you set EXECUTION_BACKEND=blaxel. Secret Manager holds the GitHub App private key, webhook secrets, LLM keys, and database URL. The state of jobs, PRs, and Linear issues is persisted, not held in memory.
Each of those choices points the same way: this is built to live in the production infrastructure you already operate, not to be rented.
What You Need to Run It
Broccoli is self-hosted by design, and that’s a requirement, not a caveat. You need a Google Cloud account that can create a project (or administer an existing one) with billing attached. Deployment is a bootstrap script, a config file, and two webhooks—about 30 minutes from clone to running. You also own the prompt templates: they come opinionated, and you fork them, tweak them, and version them alongside your code.
Where It Fits (and Where It Doesn’t)
If your workflow already lives in Linear and GitHub, and the reason you haven’t adopted a cloud agent until now is that your code can’t leave your boundary, Broccoli is built for you. It also fits if you want to own and version the prompts that drive your automation instead of treating them as a vendor’s black box.
It’s a worse fit if you don’t run on GCP, or if you want zero-infra convenience and don’t care where it executes—there are lighter managed options for that. Broccoli asks you to own the stack. That’s the trade, and for the teams it’s built for, that’s all the appeal.
The repo is MIT-licensed and picking up traction fast since its Show HN debut. Just a single commit on main today, but the architecture docs (ARCHITECTURE.md, JOB-CONTRACT.md) are already there—a signal that the authors think of this as infrastructure, not as a demo.
The era of “assign a ticket, get a PR” has clearly arrived. The open question Broccoli raises is whether that has to mean handing over custody of your code. Its answer is no.
Would you run a code agent inside your own cloud, or do you prefer the convenience of a managed service even if your code leaves your boundary? I’d like to hear from you below.