I Hate Jenkins (Sorry Not Sorry) — So I Built My Own CI/CD Platform

I want to tell you about the moment I gave up on Jenkins.

It wasn't dramatic. There was no explosion, no catastrophic failure. It was a Tuesday afternoon, I was three hours deep into debugging a Groovy script in a Jenkinsfile, and I realised I had completely lost the plot. I wasn't writing software anymore. I was maintaining a CI/CD system that had become its own full-time job.

That was the day I started building Callahan CI.

The Problem With Jenkins (You Already Know This)

If you've used Jenkins seriously, you already know the pain:

• The plugin ecosystem is enormous, poorly maintained, and a constant source of breakage
• The Groovy DSL is powerful but arcane — it feels like a different job from the rest of your work
• The UI is dated in a way that goes beyond aesthetics — it's genuinely hard to understand what's happening
• Running it locally for development feels like setting up a server farm
• Configuration lives in a dozen different places and none of them are obvious

GitHub Actions solved some of this — YAML is at least readable, and the marketplace is better curated. But then you're fully cloud-dependent, your secrets live somewhere you can't see, and the per-minute billing adds up faster than you expect on a side project.

I wanted something that ran on my laptop. No cloud. No agents. No plugin marketplace. Just: I push code, something builds it, and I find out what broke.

What I Built

Callahan CI is a single Go binary. You clone the repo, run ./start.sh dev, and you have a working CI/CD platform on localhost:3000. Everything — the API, the pipeline runner, the WebSocket log stream, the dashboard — is in that one process. State lives in a SQLite file.

It reads a Callahanfile.yaml (GitHub Actions-compatible syntax, so migration is low friction), executes your build steps as native shell processes, streams logs in real time, and stores results.

That's the boring part. Here's the part I actually care about.

The AI Layer

When I started building this I knew I wanted AI involved, but I didn't want the usual "AI assistant" bolted on as an afterthought. I wanted agents that do specific jobs at specific moments in the pipeline, without you having to ask.

There are four:

1. The Architect

You describe your pipeline in plain English. The Architect writes the Callahanfile.yaml for you — jobs, steps, deploy stages, AI flags — and commits it back to the repo. If you already have a Jenkinsfile or a GitHub Actions workflow, it can migrate that too.

2. The Debugger

When a build fails, you click AI Explain Failure. The Debugger reads the failed job's logs and your pipeline config, and returns a short root cause with a concrete next step. No more scrolling through 800-line stack traces at 11pm.

DIAGNOSIS: Build failed because npm couldn't find package.json.
The repo is a Go project — language detection fell through to the
JS default. Replace the build step with: go build ./...

3. The Reviewer

This one runs automatically on every build. It reads the diff for the commit that triggered the build and writes a structured code review — severity, finding, fix suggestion. For PR builds, it posts the review as a comment on the originating GitHub or GitLab PR. No action required on your part.

FINDING: internal/auth.go:23 — password hashed with MD5.
Use bcrypt or argon2id instead.

4. The Analyst

If Trivy and Semgrep are on your machine, Callahan runs them on every build, parses the JSON output, and renders findings as expandable cards sorted by severity. If neither is installed, it falls back to an LLM source review. Either way, findings get posted to the PR alongside the code review.

[CRITICAL] GitHub Personal Access Token found in internal/auth/auth.go:14
→ rotate the token, move it to project secrets

The Stack

In case you're curious:

• Backend: Go 1.22, Gin, SQLite (WAL mode), sync.RWMutex for thread safety
• Frontend: Next.js 15 with SWC
• LLM: Groq (llama-3.3-70b-versatile) by default, but Claude, GPT-4o, and Ollama are all wired in — switch in settings without a rebuild
• Webhooks: HMAC-verified GitHub push/PR and GitLab push/MR
• Containerisation: Docker Compose if you want one-command setup

Works fully offline if you point it at Ollama. No data leaves your machine unless you choose a cloud LLM provider.

How It Compares

I'm not going to pretend this replaces Jenkins for a 200-engineer org. It doesn't. Here's an honest comparison:

The honest target audience: solo developers and small teams who want their CI on their machine, with AI parts that actually work rather than being a demo feature.

Trying It

Docker is the fastest path:

git clone https://github.com/Callahan-ci/Callahan
cd Callahan
cp .env.example .env
# Add an LLM key to .env (or skip for Ollama)
docker compose up --build
open http://localhost:8080

From source if you have Go 1.22+ and Node 18+:

git clone https://github.com/Callahan-ci/Callahan
cd Callahan
echo 'GROQ_API_KEY=your-key' >> .env
./start.sh dev
open http://localhost:3000

Full docs at callahanci.com.

What's Next

The Jenkinsfile migration tool is next on the roadmap — paste a Jenkinsfile, get a Callahanfile.yaml back. Given how many teams are stuck on Jenkins not because they love it but because migration feels expensive, I think there's real value there.

Authentication and multi-user support is also in progress — right now it's single-user local, which is fine for solo dev use but limits teams.

Honest Bit at the End

The codebase was built with significant AI assistance throughout. I designed the architecture, made every product decision, and understand and own every part of it — but I want to be transparent rather than pretend I typed every line by hand. That feels like the right thing to say in 2026.

If you try it and something is broken, open an issue. If you have feedback, start a discussion. I read everything.

Callahan CI is MIT licensed. Star the repo if it looks useful — it genuinely helps with visibility.

Website: callahanci.com · Repo: github.com/Callahan-ci/Callahan