I’ve been setting up a self-hosted CI pipeline — Jenkins running in Docker on a QNAP NAS, tunneled out to GitHub via Cloudflare. It’s not a trivial project. There are a lot of moving pieces: Docker Compose configs, Jenkinsfiles, webhook setup, network routing, MobSF integration. Normally this is the kind of thing where you spend a lot of time jumping between documentation tabs and Stack Overflow, stitching things together slowly.

I decided to do most of it inside Cursor using Claude as the AI backend, leaning into what people are calling “agentic” mode — where instead of asking one question at a time, you describe a goal and let the AI work through it across multiple steps. Here’s what I noticed.

What’s different about agentic flow

Normal AI-assisted coding looks like this: you ask a question, get an answer, copy something, ask a follow-up, repeat. It’s useful but you’re still doing most of the driving.

Agentic flow is different. You describe what you’re trying to accomplish — “set up a Jenkins pipeline that builds an Android APK, runs Espresso tests, and passes the result to MobSF for a security scan” — and the model starts working through it. It reads your existing files, figures out what’s missing, writes what’s needed, and checks its own output. You’re more like a reviewer than a driver.

The thing that surprised me is how much context it holds across the work. When I was setting up the Cloudflare Tunnel container, it already knew from earlier in the session how Jenkins was configured, which port it was on, and what the Docker network was called. It didn’t need me to repeat myself.

What it was actually like for the QNAP setup

The CI pipeline involved a few distinct problems that would normally each require separate research sessions:

Docker Compose on QNAP — Container Station has some quirks compared to a standard Docker host. Getting the volume mounts right for the Android SDK inside the Jenkins container took some back and forth, but Claude flagged the QNAP-specific paths without me having to look them up.

The Jenkinsfile — Writing a declarative pipeline with three stages (build, test, security scan) and the right failure conditions is the kind of thing where the syntax is fiddly and easy to get wrong. Claude wrote a working first draft, I told it what I wanted to change, and it updated it. I didn’t have to look at the Jenkins documentation once.

MobSF integration — This was the part I was least sure about. MobSF has an API, but wiring it into a Jenkins stage — uploading the APK, polling for the scan result, failing the build above a certain severity score — is not something I’d done before. Claude worked through the API calls, wrote the shell script that handles the integration, and explained what each part was doing as it went.

The Cloudflare Tunnel piece was probably the easiest because the concept is straightforward once you understand it, and Claude explained the “why” well — outbound connection from your machine, no ports, permanent URL — which made it easier to debug when something wasn’t routing correctly.

Where it still needs you

It’s not a replacement for understanding what you’re building. A few times Claude produced something that looked right but had an assumption baked in that didn’t match my setup. If I hadn’t known enough to catch it, I would have had a broken pipeline and no idea why.

It also doesn’t know what it doesn’t know. If you’re exploring something genuinely novel or obscure, it’ll sometimes fill in gaps with plausible-sounding things that aren’t quite right. You still need to verify.

And the agentic mode works best when you give it a clear target. Vague prompts produce vague results. The more specific you are about what done looks like, the better the output.

Would I use it this way again

Yes, without hesitation. The CI pipeline would have taken me significantly longer to piece together manually — not because any individual part is that hard, but because there are a lot of parts, and keeping them all in your head while also looking things up gets tiring fast.

Having something that can hold the full context of what you’re building, write the boilerplate confidently, and explain its reasoning as it goes makes the whole thing faster and less frustrating. It doesn’t replace the thinking — you still have to know what you want and whether you’re getting it — but it removes a lot of the friction in between.

For infrastructure work especially, where the reward is a thing that runs quietly in the background and never needs attention again, that trade-off feels very worth it.

Most Android CI setups end up on GitHub Actions or Bitrise or some other cloud runner. They work fine, but once your free minutes run out or your team grows, the bill follows. I wanted to see if I could get the same result — automated builds, UI tests, security scans — on hardware I already had sitting on my desk.

The short version: it works. Here’s how it’s set up.

The stack

• QNAP NAS — the machine everything runs on
• Container Station — QNAP’s Docker management UI, used to run Jenkins and the other containers
• Jenkins — the CI orchestrator that watches for PRs and runs the pipeline
• Gradle — builds the APK inside the Jenkins pipeline
• Espresso — Android UI tests that run as part of the build
• MobSF — a static security scanner that inspects the APK before it’s allowed through
• Cloudflare Tunnel — how GitHub reaches Jenkins without any port forwarding

The problem with running CI at home

The obvious issue with self-hosted CI is that your machine is behind a router at home. GitHub needs to send webhook events to Jenkins when a PR is opened — but your NAS doesn’t have a public IP address, and even if it did, you’d have to open ports and deal with a dynamic IP changing on you.

Cloudflare Tunnel solves this cleanly. You run a small agent (cloudflared) on the QNAP as another Docker container. It opens an outbound connection to Cloudflare’s edge and keeps it alive. Cloudflare gives you a permanent public URL — something likehttps://your-tunnel.cfargotunnel.com — and any traffic hitting that URL gets forwarded through the tunnel to Jenkins running locally. No ports opened. No domain purchase. No IP management.

From GitHub’s perspective, Jenkins just looks like any other server on the internet.

The pipeline

When a pull request targetsmain, GitHub fires a webhook to Jenkins. The pipeline runs three stages in order:

1. Build

Jenkins checks out the branch and runs the Gradle build inside the container:

./gradlew assembleDebug

If the build fails — compile error, missing dependency, whatever — the pipeline stops here and the PR is blocked.

2. UI Tests

Espresso tests run against the debug APK. This is the stage that catches things a unit test wouldn’t — navigation flows, UI state after an action, things that only break when the full app is running.

./gradlew connectedDebugAndroidTest

3. Security Scan

The APK gets passed to MobSF, which does a static analysis — checking for hardcoded secrets, insecure API usage, exported components that shouldn’t be, and a few dozen other things. If MobSF finds anything above the severity threshold, the stage fails.

All three stages have to pass for the PR to be mergeable. GitHub’s branch protection rules enforce this — the Jenkins job reports its status back to the PR, and the merge button stays locked until the check goes green.

Why this setup

The main reason is cost. Once it’s running, this pipeline costs nothing to operate. The NAS was already there. Cloudflare Tunnel is free. Jenkins is open source. The only thing you’re spending is electricity and the time it takes to set it up.

The second reason is that it’s genuinely interesting to build. Running a build system on a NAS, tunneling it through Cloudflare’s edge, wiring up GitHub webhooks — there are a few moving parts that have to fit together, and getting there teaches you something about how CI infrastructure actually works, rather than just filling in a YAML file and hoping for the best.

What’s left

The pipeline is functional but there are a few things I still want to add — artifact storage so built APKs are retained, Slack notifications when a build fails, and eventually wiring up the release signing so a passing build onmain can go straight to a draft Play Store release.

More on those as they come together.

I’ve been using Notion for a while mostly as a notes app, but recently I set it up more like a proper project tracker — epics, issues, priorities, statuses, the whole thing. The kind of setup you’d normally see in Jira, but without the $20/month and the 47 tabs it takes to do anything.

The part I actually enjoyed was connecting it to the Notion API so I can manage tasks from the terminal instead of clicking around in the UI. Here’s how it works.

The setup

Inside Notion I have a project board with three databases:

• Epics — the big feature areas (e.g. “Blog Section”, “Mobile App v2”)
• Issues — the actual tasks, linked back to an epic
• Sprints — time boxes that issues can be assigned to

Issues have all the fields you’d expect: status, priority, labels, story points, assignee, due date. Epics and sprints have their own trimmed-down schemas.

To talk to all of this from outside Notion, you create an internal integration in your workspace settings, grab a token, and share the relevant pages with it. After that you’re just making HTTP requests.

Creating an epic

Here’s what creating an epic looks like at the API level:

curl -X POST"https://api.notion.com/v1/pages"\ -H"Authorization: Bearer$NOTION_TOKEN"\ -H"Content-Type: application/json"\ -H"Notion-Version: 2022-06-28"\ -d'{ "parent": { "database_id": "your-epics-db-id" }, "properties": { "Name": { "title": [{ "type": "text", "text": { "content": "Blog Section" } }] }, "Status": { "select": { "name": "Backlog" } }, "Priority": { "select": { "name": "Medium" } } } }'

You’re just creating a new page inside the Epics database. Notion treats every row in a database as a page, so the API is the same regardless of whether you’re making an epic, an issue, or a sprint.

Creating issues under that epic

Issues work the same way, but you also pass a relation back to the epic. The thing to know here is that relations use the epic row’spage ID, not the database ID — I got tripped up on that the first time.

curl -X POST"https://api.notion.com/v1/pages"\ -H"Authorization: Bearer$NOTION_TOKEN"\ -H"Content-Type: application/json"\ -H"Notion-Version: 2022-06-28"\ -d'{ "parent": { "database_id": "your-issues-db-id" }, "properties": { "Name": { "title": [{ "type": "text", "text": { "content": "Add blog section to Hugo site" } }] }, "Status": { "select": { "name": "To Do" } }, "Priority": { "select": { "name": "High" } }, "Labels": { "multi_select": [{ "name": "Frontend" }, { "name": "Feature" }] }, "Epic": { "relation": [{ "id": "epic-page-id-here" }] } } }'

Moving an issue through the board

Updating status is just a PATCH to the page with the new select value:

curl -X PATCH"https://api.notion.com/v1/pages/issue-page-id"\ -H"Authorization: Bearer$NOTION_TOKEN"\ -H"Content-Type: application/json"\ -H"Notion-Version: 2022-06-28"\ -d'{ "properties": { "Status": { "select": { "name": "Done" } } } }'

Wrapping it in a CLI

Typing all that curl by hand gets old fast. I wrote a small Node.js script (notion.js) that wraps the common operations so I can do things like:

# Create an epicnode notion.js create-epic --title"Blog Section" --priority Medium# Create an issue under itnode notion.js create-issue --title"Deploy to production" --epic"Blog Section" --priority High --labels"Feature"# See what's opennode notion.js list-issues --status"In Progress"# Close it outnode notion.js move-issue --id page-id-here --status"Done"

The script finds the epic by name, looks up its page ID, and wires everything together — so I never have to paste IDs manually.

Why bother

The main reason is that I find it easier to stay on top of side projects when the tracking is close to where the work is actually happening. Instead of switching to a browser and hunting for the right page, I can run a command in the same terminal I’m already working in.

It also means I can have Claude update the board automatically as tasks finish — writing notes on what was done, any errors that came up, and how things got resolved. So the board stays accurate without extra effort on my end.

Not something I’d recommend for a team, but for solo projects it’s a nice middle ground between “sticky note on my monitor” and a full Jira setup.