Forem: Jeff Vincent

From Source to Production with OAuth: The Full Kindling Flow

Jeff Vincent — Wed, 11 Mar 2026 16:49:05 +0000

Your laptop is your staging environment. Literally.

In this post, we'll take a polyglot microservice app from local source code to a production Kubernetes cluster with TLS, Auth0 login, and Stripe webhooks — all working end-to-end. No cloud staging environment. No Docker Compose. No YAML by hand.

The app is oauth-example, a four-service demo you can clone and follow along with.

What we're building

A microservices app with real external integrations:

Browser → UI (React/nginx)
            ↓
         Gateway (Go) ← Auth0 OIDC login/callback
            ↓              ← Stripe webhook receiver
       ┌────┴────┐
    Orders     Inventory
   (Python)    (Node.js)
   Postgres    MongoDB
      Redis ←──── shared event queue

UI — React dashboard served by nginx
Gateway — Go reverse proxy with Auth0 OIDC and Stripe webhook verification
Orders — Python FastAPI with Postgres, publishes events to Redis
Inventory — Node.js Fastify with MongoDB, consumes order events from Redis

The interesting part: Auth0 needs a public HTTPS callback URL, and Stripe needs a public HTTPS webhook endpoint. These are the exact things that make local development painful — and the exact things kindling solves.

Step 1: Init the cluster

brew install kindlingdev/tap/kindling
kindling init

That's it. You now have a Kind cluster with an operator, an in-cluster container registry, and a Traefik ingress controller. All local, all disposable.

Step 2: Register a CI runner

kindling runners -u <github-user> -r oauth-test -t <github-pat>

This deploys a self-hosted GitHub Actions runner inside your Kind cluster. When you push code, CI runs locally — builds happen with Kaniko, images land in the in-cluster registry at localhost:5001. No DockerHub. No ECR. No waiting for remote CI.

Step 3: Generate the CI workflow

kindling generate -k <api-key> -r .

Kindling's AI analyzes your repo — finds the four services, detects languages and frameworks, reads the Dockerfiles, discovers the deploy manifests — and generates a GitHub Actions workflow that builds and deploys everything. The generated workflow handles:

Building each service with Kaniko
Pushing images to the in-cluster registry
Applying the DSE (DevStagingEnvironment) manifests
Service-to-service wiring via environment variables
Dependency provisioning (Postgres, Redis, MongoDB)

You don't write this workflow. You don't maintain it. Push code and it runs.

Step 4: Create Auth0 and Stripe accounts and set credentials

The gateway's deploy manifest references secrets via secretKeyRef — Kubernetes won't start the pod if they don't exist. You need to create your external service accounts and set the credentials before the first deploy.

Create an Auth0 application

Sign up or log in at auth0.com
In the Auth0 Dashboard, go to Applications → Create Application
Name it something like oauth-example-dev, select Regular Web Application, and click Create
In the Settings tab, copy these three values — you'll need them in a moment:
- Domain (e.g. your-tenant.us.auth0.com)
- Client ID
- Client Secret

Don't configure the callback URLs yet — you'll need a public tunnel URL first, which comes after the deploy.

Create a Stripe webhook endpoint

Sign up or log in at dashboard.stripe.com
Make sure you're in Test mode (toggle in the top-right)
Open the Webhooks tab in Workbench

You'll create the actual webhook endpoint later once you have a tunnel URL. For now, just copy your Stripe Secret Key from Developers → API keys — it starts with sk_test_.

Set the pre-deploy secrets

Set the credentials so the pods can start:

kindling secrets set AUTH0_DOMAIN your-tenant.auth0.com
kindling secrets set AUTH0_CLIENT_ID your-client-id
kindling secrets set AUTH0_CLIENT_SECRET your-client-secret
kindling secrets set SESSION_SECRET $(openssl rand -hex 32)
kindling secrets set STRIPE_SECRET_KEY sk_test_your_stripe_secret_key
kindling secrets set STRIPE_WEBHOOK_SECRET placeholder
kindling secrets set PUBLIC_URL http://localhost

STRIPE_WEBHOOK_SECRET and PUBLIC_URL are placeholders — the gateway will start without them working, but it won't crash. You'll set the real values after starting a tunnel.

Note: STRIPE_SECRET_KEY (starts with sk_test_) is your Stripe API key from Developers → API keys. This is different from STRIPE_WEBHOOK_SECRET (starts with whsec_), which is the webhook signing secret you'll get after creating a webhook endpoint in Step 6.

The DSE manifests reference these via secretKeyRef — the operator injects them as environment variables into the gateway pod. No secrets in YAML. No secrets in env files. No secrets in git.

Step 5: Push and deploy

git add -A && git commit -m "initial deploy"
git push origin main

The runner picks up the push, builds all four images, and the operator deploys them. Check status:

kindling status

▸ Dev Staging Environments
    📦 jeff-vincent-gateway      9090   jeff-vincent-gateway.localhost
    📦 jeff-vincent-inventory    3000   jeff-vincent-inventory.localhost
    📦 jeff-vincent-orders       5000   jeff-vincent-orders.localhost
    📦 jeff-vincent-ui           80     jeff-vincent-ui.localhost

▸ All Deployments
    jeff-vincent-gateway             1/1
    jeff-vincent-inventory           1/1
    jeff-vincent-inventory-mongodb   1/1
    jeff-vincent-orders              1/1
    jeff-vincent-orders-postgres     1/1
    jeff-vincent-orders-redis        1/1
    jeff-vincent-ui                  1/1

Four services, three databases, all running. Open http://jeff-vincent-ui.localhost and the dashboard is live. Auth0 and Stripe aren't wired yet — that's next.

Step 6: Start a tunnel and configure OAuth + webhooks

Now that the services are running, you need a public HTTPS URL for Auth0 callbacks and Stripe webhooks. Kindling uses Cloudflare's free quick tunnels. Sign up for a free Cloudflare account; navigate to Protect and Connect > Networking > Tunnels, and create one. Then, start the Cloudflare daemon on your local machine like so:

brew install cloudflared && 
sudo cloudflared service install <your-token>

kindling expose

You'll get a public URL like https://verb-noun-adj-noun.trycloudflare.com. Copy it.

The tunnel runs in the background. The URL changes each time you restart it, so you'll update the callback URLs in Auth0 and Stripe when you need to test external integrations. Most day-to-day development doesn't need the tunnel at all.

Configure Auth0 callback URLs

Go back to your Auth0 application settings and set:

Auth0 Dashboard → Applications → oauth-example-dev → Settings → Application URIs

Allowed Callback URLs
https://<your-tunnel-url>/auth/callback
Allowed Logout URLs
https://<your-tunnel-url>
Allowed Web Origins
https://<your-tunnel-url>
Replace <your-tunnel-url> with the URL from kindling expose (e.g. verb-noun-adj-noun.trycloudflare.com).

Click Save Changes.

The callback URL is what Auth0 redirects to after a user authenticates. It must match exactly what the gateway sends in the OIDC authorization request — the path /auth/callback is handled by the gateway's OIDC callback handler, which exchanges the authorization code for tokens and sets a session cookie.

The gateway's OIDC integration uses Auth0's Universal Login — no custom login page needed. For more detail, see Auth0's Getting Started guide.

Create the Stripe webhook endpoint

Now create the webhook endpoint in Stripe with your tunnel URL:

In Workbench → Webhooks, click Create an event destination
Walk through the creation flow:

Events from
Your account
API version
Select your default API version (or latest).

Events
checkout.session.completed
payment_intent.succeeded
Click Continue, then select Webhook endpoint as the destination type.

Click Continue, then set:

Endpoint URL
https://<your-tunnel-url>/webhooks/stripe

Click Create destination
Select your new endpoint, then click Click to reveal to copy the signing secret (whsec_...)

The webhook URL is where Stripe sends event payloads via POST. The gateway receives the request at /webhooks/stripe, verifies the Stripe-Signature header against the signing secret using HMAC-SHA256, and forwards validated payloads to the orders service. Unverified requests are rejected with a 400. See Stripe's webhook docs for background on signature verification and event types.

Set the real PUBLIC_URL and webhook secret

Now update the placeholder secrets with the real values:

kindling secrets set PUBLIC_URL https://<your-tunnel-url>
kindling secrets set STRIPE_WEBHOOK_SECRET whsec_your_signing_secret

The gateway pod will restart automatically to pick up the new values. Verify with kindling status that the gateway is back to 1/1.

Step 7: The inner dev loop

Now you're developing. You change code. You need it reflected immediately. Check status:

kindling status

▸ Dev Staging Environments
    📦 jeff-vincent-gateway      9090   jeff-vincent-gateway.localhost
    📦 jeff-vincent-inventory    3000   jeff-vincent-inventory.localhost
    📦 jeff-vincent-orders       5000   jeff-vincent-orders.localhost
    📦 jeff-vincent-ui           80     jeff-vincent-ui.localhost

▸ All Deployments
    jeff-vincent-gateway             1/1
    jeff-vincent-inventory           1/1
    jeff-vincent-inventory-mongodb   1/1
    jeff-vincent-orders              1/1
    jeff-vincent-orders-postgres     1/1
    jeff-vincent-orders-redis        1/1
    jeff-vincent-ui                  1/1

Four services, three databases, all running. Open http://jeff-vincent-ui.localhost and the dashboard is live.

Step 6: The inner dev loop

Now you're developing. You change code. You need it reflected immediately.

kindling sync -d jeff-vincent-gateway

File changes sync directly into the running pod — no image rebuild, no redeploy. For Go services, the binary recompiles inside the container. For Python and Node.js, the file change triggers a reload automatically.

Need to step through code? Run debug from the project root:

cd /path/to/oauth-test
kindling debug -d jeff-vincent-orders --port 5678

Note: kindling debug must be run from the project root directory — it needs access to the source tree to set up the debug session.

Attach your IDE's debugger to localhost:5678 and set breakpoints in the orders service while it's running inside the cluster, talking to real Postgres and Redis.

Step 8: Test the OAuth and Stripe flows

With the services running and secrets configured, verify everything is wired:

curl http://jeff-vincent-gateway.localhost/auth/status
# {"auth0_configured":true,"callback_url":"https://<your-tunnel-url>/auth/callback"}

curl http://jeff-vincent-gateway.localhost/stripe/status
# {"stripe_webhook_configured":true,"webhook_url":"https://<your-tunnel-url>/webhooks/stripe"}

Open your tunnel URL in a browser (e.g. https://verb-noun-adj-noun.trycloudflare.com), click Login — Auth0's universal login page loads, you authenticate, and the callback redirects to your tunnel URL. The request routes through Cloudflare → localhost:80 → Traefik → the gateway ingress, which exchanges the code for tokens and sets a session cookie. The full OIDC flow, running locally.

For Stripe, trigger a test event from the Stripe Dashboard (or use the Stripe CLI). The event hits the gateway at your tunnel URL via the same path — Cloudflare → localhost:80 → Traefik → gateway — the signature is verified against the signing secret, and the payload is forwarded to the orders service, which updates the order status in Postgres.

Step 9: Deploy to production

The dev environment is validated. Auth0 callbacks work. Stripe webhooks land. Time to go live.

kindling dashboard --prod-context <your-prod-cluster-context>

The production dashboard connects to your real cluster. From there:

Snapshot your dev environment — the operator captures the exact image tags, env vars, and dependency configuration
Deploy to production — images are re-tagged and pushed to your production registry, manifests are applied
TLS — cert-manager provisions Let's Encrypt certificates automatically

Note: After deploying, you'll need to update your domain's DNS A record to point to the new load balancer IP (find it with kubectl get svc traefik -n traefik). DNS propagation can take a few minutes — during that time you may see a browser warning like "Your connection is not private" (ERR_CERT_AUTHORITY_INVALID). This is normal. Go walk your dog, knit a sweater, contemplate the mass of the universe — whatever you do, don't sit there refreshing the browser. Once DNS propagates, cert-manager will complete the ACME challenge and the Let's Encrypt certificate will be issued automatically.

In production, swap the secrets for production values:

AUTH0_DOMAIN → your production Auth0 tenant
AUTH0_CLIENT_ID / AUTH0_CLIENT_SECRET → production app credentials
STRIPE_SECRET_KEY → production Stripe API key (starts with sk_live_)
STRIPE_WEBHOOK_SECRET → production webhook signing secret (starts with whsec_)
PUBLIC_URL → your production domain

The same code, the same architecture, the same deployment model. The only things that change are the secrets and the domain.

What just happened

Let's trace the full path:

Source code on your laptop
kindling init — local Kind cluster with operator, registry, ingress
kindling generate — AI-generated CI workflow
kindling secrets set — set Auth0/Stripe credentials so pods can start
git push — local runner builds with Kaniko, deploys via operator
kindling expose + kindling secrets set — start tunnel, configure Auth0/Stripe callback URLs, set PUBLIC_URL
kindling sync — live code changes without rebuilding
Test OAuth + Stripe — verify callback flows end-to-end
Production deploy — same images, same config, real cluster with TLS

No Docker Compose file. No Helm charts. No Terraform. No cloud staging environment bill. No "works on my machine" gaps between dev and prod.

The entire staging environment runs on your laptop. When it works there, it works in production — because it's the same Kubernetes, the same container images, the same networking model.

Try it

brew install kindlingdev/tap/kindling
git clone https://github.com/kindling-sh/oauth-example
cd oauth-example
kindling init
kindling runners -u <user> -r oauth-example -t <pat>
kindling generate -k <api-key> -r .
# Set credentials so pods can start
kindling secrets set AUTH0_DOMAIN <your-domain>
kindling secrets set AUTH0_CLIENT_ID <your-id>
kindling secrets set AUTH0_CLIENT_SECRET <your-secret>
kindling secrets set SESSION_SECRET $(openssl rand -hex 32)
kindling secrets set STRIPE_SECRET_KEY <sk_test_...>
kindling secrets set STRIPE_WEBHOOK_SECRET placeholder
kindling secrets set PUBLIC_URL http://localhost
# Deploy
git push origin main
# Start tunnel, configure Auth0/Stripe callback URLs, then update secrets
kindling expose
# copy the tunnel URL, set it in Auth0 + Stripe dashboards
kindling secrets set PUBLIC_URL <your-tunnel-url>
kindling secrets set STRIPE_WEBHOOK_SECRET <whsec_...>

Your laptop is your staging environment. Start building.

What I've Actually Learned Using Coding Agents to Build Software

Jeff Vincent — Tue, 24 Feb 2026 03:08:01 +0000

Most of the writing about coding agents right now falls into two buckets: breathless excitement or dismissive skepticism. Neither is particularly useful if you're trying to figure out how to actually build things with these tools.

I've been using GitHub Copilot (backed by Claude) as my primary development partner for a while now, building a project with real scope — a Kubernetes operator, a CLI, an embedded web dashboard, CI pipelines, the works. Not a demo. Not a weekend project. Software I ship and maintain.

What follows isn't advice about prompting. It's what I've come to believe about the relationship between your codebase, your infrastructure, and how much leverage you actually get from an agent.

Pattern Inertia Is Real, and It Cuts Both Ways

Coding agents are pattern-completion machines. They look at your codebase and write more of what's already there. This sounds obvious, but the second-order effects are worth thinking about carefully.

Here's a concrete example. My project has two interfaces — a CLI and a web dashboard. The CLI got built first. When it came time to bring the dashboard up to feature parity, I pointed the agent at the work and let it go. What it produced was functional and correct — and completely duplicated. ~800 lines of business logic, reimplemented in a second location, because that's what the existing code looked like. Two implementations of secret management, two implementations of tunnel lifecycle, two implementations of kubectl wrappers.

The agent wasn't wrong. It was doing exactly what the patterns suggested. The problem was that nobody had named the abstraction. In a team of humans, someone eventually says "hey, we should pull this out" in a code review. The agent will never feel the mess accumulating. That's your job.

What's interesting is what happened when I did name it. I said, roughly, "there's a lot of duplicated code between the CLI and the dashboard — look at this closely and refactor." The agent analyzed both codebases, identified the shared logic, designed a core/ package with clean interfaces, migrated every call site, fixed the tests, and verified the build. Hundreds of lines removed, zero regressions. But it would never have initiated that on its own.

The lesson I take from this is that your early architectural decisions carry more weight than they used to. In agent-assisted development, a pattern isn't just a pattern — it's a template the agent will replicate indefinitely. Get the abstractions right early, and you're not writing one good module. You're establishing a convention the agent follows for the rest of the project. Get them wrong, and you're compounding technical debt at the speed of generation.

It Will Write Like You (If You Let It)

This one genuinely surprised me.

Every developer has idioms. The way you handle errors. The way you name things. The abstractions you reach for instinctively. I expected to spend a lot of time nudging the agent away from generic patterns and toward my preferences.

What actually happened, once the codebase had enough of my own code in it, is that the agent internalized my style. Not "clean Go" in the abstract. My Go. My error handling conventions, my naming patterns, my preferred ways of structuring packages. At a certain point, code the agent wrote was indistinguishable from code I wrote — not because it was copying, but because it had enough signal to generalize from.

This has a practical implication that I think people undervalue: the time you spend early on writing clean, consistent, opinionated code isn't just good hygiene. It's training data. The more coherent your existing codebase is, the less correction you do later. Your style becomes the agent's style, and the collaboration gets smoother the longer you work together.

Your Pipeline Is the Real Feedback Loop

Here's maybe the most important structural insight I've arrived at: the agent needs guardrails it can run against, and your CI/CD pipeline is where those guardrails live.

An agent can produce a lot of plausible-looking code quickly. "Plausible-looking" and "actually works" are different things. Without a tight feedback loop, you accumulate silent drift — code that reads fine, passes a casual glance, and breaks somewhere downstream.

In practice, what I've found works is treating the build-test-lint cycle as the environment that keeps the agent honest. When the agent refactored my codebase — touching 19 files across two packages — the Go compiler immediately caught every signature mismatch, every missing import, every call site that didn't match the new interface. The agent fixed them iteratively, ran the tests, confirmed zero regressions, and moved on. I didn't review individual lines during that process. I didn't need to. The pipeline told both of us whether the code was correct.

This is also what makes delegation possible. If you trust your pipeline to catch problems, you can hand the agent a substantial task — "write an e2e test suite that exercises every feature group against a real Kind cluster" — and let it work. Without that trust, you're reading every line of output, which isn't meaningfully faster than writing it yourself.

The tighter and faster the feedback, the less drift you get. A build that runs in seconds is worth more than a code review that happens in hours.

All of this is how and why I built Kindling.

The feedback loop I just described only works if it's fast. Cloud CI is slow. You push a commit, wait in a queue behind everyone else's jobs, watch a runner spin up from scratch, and by the time the feedback lands you've already context-switched into something else. That's not a feedback loop. That's a waiting room.

Kindling flips the model. It's a Kubernetes operator that routes your GitHub Actions CI jobs back to your own laptop, running in a local Kind cluster. When you push code, the job comes to you. It builds your container image via Kaniko, right there on your machine, and deploys a full ephemeral staging environment — Deployment, Service, Ingress, all auto-provisioned dependencies wired up and ready — to localhost. In seconds. On compute you already own.

The patterns I've been describing aren't abstract. They showed up here. The CLI and dashboard diverging into ~800 lines of duplication? That happened in Kindling — two interfaces, one codebase, and an agent that faithfully reproduced the mess until I explicitly told it otherwise. The types that caught mistakes early? Go's type system running in a tight local build loop, surfacing errors before they had a chance to become integration bugs. The idiosyncratic style the agent picked up? A Go codebase opinionated enough about its abstractions that Copilot eventually just wrote them the same way.

Kindling also ships a kindling generate command that uses an LLM to scan your repo and produce a GitHub Actions workflow tailored to what's actually in your code — detected services, dependencies, ports, credentials, the works. It's a coding agent operating on your infrastructure configuration. And it works well precisely because the environment it's generating for is well-defined and testable. The feedback loop is tight. The builds are fast. The agent stays honest.

Strong Types Are Cheap Insurance

This is a narrower point but it matters more than I expected: invest in strong typing early, even when it feels like overhead.

When the agent makes a mistake in a dynamically typed language, that mistake might not surface until runtime, or integration, or production. In a strongly typed language, the compiler catches it in seconds and tells the agent exactly what went wrong and where. A compile failure is free. An integration bug discovered three days later costs a week.

The same logic applies to schemas, API contracts, CRD definitions — anything that gives the agent a formal specification to check its work against. Without that, the agent is improvising. Improvisation at speed is how you get subtle inconsistencies that are painful to debug later.

I think of the type system as just another part of the feedback loop. Every checkpoint that catches drift early makes the whole system more reliable.

What This Actually Changes About Your Job

The shift I've experienced isn't "I write code faster now." It's that my job has changed shape.

I spend less time writing individual functions and more time thinking about architecture — where the boundaries should be, what patterns I want replicated, what the feedback loops look like. The agent handles volume. I handle direction. When I see something wrong, I name it at the level of design intent — "this is duplicated," "this should be a shared package," "write an e2e that covers every feature group" — and the agent figures out the implementation.

This isn't a small change. It means the skills that matter shift toward systems thinking, toward knowing when an abstraction is missing, toward building infrastructure that validates correctness automatically. The developers who get the most out of these tools won't be the ones who learn to prompt better. They'll be the ones who build environments where the agent can do good work — tight feedback loops, clean patterns, strong types, fast builds.

That's less exciting than "AI writes all my code." But it's closer to the truth, and honestly, it's more interesting. You're not being replaced by the tool. You're designing the system in which the tool operates. That's a different skill, and it's worth developing deliberately.

Kindling v0.6.0: Hot Reload for Every Language in Your Kubernetes Dev Environment

Jeff Vincent — Mon, 23 Feb 2026 03:15:37 +0000

February 2026 · kindling-sh/kindling

We just shipped v0.6.0 of kindling, and the headline feature is kindling sync — live hot reload for any language running in a Kubernetes pod. This post walks through how it works, what it replaces, and where the project is headed.

The Problem

If you're building on Kubernetes, your development loop probably looks like this:

Edit code
Build a container image
Push to a registry
Wait for a rollout
Check logs
Repeat

Even with local tools, steps 2–4 take 30–90 seconds. Multiply that by the number of iterations in a session and you lose hours per week to build latency. Docker Compose sidesteps Kubernetes entirely, but then you're not testing against real Services, Ingress, RBAC, or any of the infrastructure your app actually runs on.

Kindling takes a different approach: keep the full Kubernetes environment, but make the feedback loop sub-second.

How `kindling sync` Works

The sync command watches your local source directory using fsnotify, debounces changes (default 500ms), and copies modified files into the running container via kubectl cp. That part is straightforward. The interesting part is what happens next.

Runtime Detection

When you run kindling sync -d my-api --restart, the CLI reads /proc/1/cmdline from the target container to identify the running process. It matches the process name against a table of 30+ known runtimes and selects a restart strategy:

$ kindling sync -d my-api --restart
✓ Detected runtime: Python (uvicorn)
✓ Strategy: signal reload (SIGHUP)
⚡ Watching /Users/you/src/my-api → /app in pod my-api-6f8b9c4d7-x2k9p

The detection is based on the actual PID 1 binary, not filenames or heuristics. If the container runs uvicorn, kindling sends SIGHUP. If it runs node server.js, kindling injects a restart-loop wrapper. If it runs a compiled Go binary, kindling cross-compiles locally and syncs the binary.

Four Restart Modes

The sync engine implements four distinct restart strategies:

Signal reload — For servers that support graceful reload (uvicorn, gunicorn, Puma, nginx, Apache). Kindling sends SIGHUP to PID 1. No wrapper injection, no downtime, no container restart. This is the lightest path.

Wrapper + kill — For interpreted runtimes (Node.js, Python, Ruby, Deno, Bun, Elixir, Perl). Kindling patches the deployment to wrap the original command in a restart loop (while true; do <original cmd>; sleep 1; done), then kills the child process after each sync. The loop respawns it with the updated code. The deployment spec records the pre-patch revision for rollback.

Local build + binary sync — For compiled languages (Go, Rust, Java/Gradle, C#, C/C++, Zig). Kindling queries the Kind node's CPU architecture, cross-compiles on your host machine, and syncs the resulting binary into the container. For Go, the default command is:

CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o /tmp/kindling-build/<binary> .

The architecture is detected automatically — no manual GOARCH flag needed.

Auto-reload — For runtimes that already watch for file changes (PHP with mod_php/php-fpm, nodemon). Files are synced and the runtime picks them up. No restart signal needed.

Automatic Rollback

When you stop a sync session — Ctrl+C from the CLI or the Stop button in the dashboard — kindling restores the deployment to its pre-sync state. If a wrapper was injected, it performs a kubectl rollout undo to the saved revision. If only files were synced (signal-reload servers), it does a rollout restart to get a fresh pod from the original image. Either way, the container goes back to exactly where it was.

This matters because sync is a dev-time overlay, not a deployment mechanism. You shouldn't have to remember to clean up patched deployments.

Load: Full Rebuild Without the CI Round-Trip

Sync covers most iteration, but sometimes you need a real container build — you changed a dependency, updated a Dockerfile, or you're working with a language the sync engine doesn't have a runtime profile for yet. That's what Load does.

The pipeline is three steps, all local:

docker build — builds the image on your machine using the project's Dockerfile, with optional --platform for cross-arch (e.g., linux/arm64 on an Apple Silicon host)
kind load docker-image — loads the built image directly into the Kind cluster's containerd store, no registry push needed
Patch + rollout — updates the DSE or Deployment image reference and waits for the rolling update to complete

From the CLI, this is kindling push (which wraps git push and triggers the full CI pipeline) or, for a faster local-only path, the Load button in the dashboard. The dashboard's Load modal auto-discovers your project's service directories and Dockerfiles, so you pick a service and click build.

The key difference from sync: Load produces a real container image. The deployment runs your updated Dockerfile, installs new dependencies, and goes through the normal Kubernetes rollout. It takes 15–60 seconds instead of sub-second, but it's a complete build — and it's still entirely local, no CI minutes consumed.

For languages where sync doesn't yet have a runtime profile, Load is the inner loop. Edit code, click Load, wait for the rollout. It's slower than sync but still faster than pushing to a remote CI system.

The Dashboard

v0.6.0 also ships a built-in web dashboard (kindling dashboard) — a single-binary React app embedded in the CLI via go:embed. It shows your cluster state and provides one-click access to the inner loop:

Each deployed service shows its detected runtime as a badge (Node.js, Python, Go, nginx, etc.)
Sync button opens a modal pre-filled with the detected runtime and source directory, starts a sync session via the API
Load button triggers a full rebuild: docker build → kind load → rollout restart
Live sync status (file count, duration) is visible on each card while a session is active

The dashboard talks to the same APIs as the CLI. Everything you can do in the terminal, you can do from the browser.

kindling dashboard --port 9090

What Kindling Actually Is

Kindling is a Kubernetes operator and CLI that gives you a complete dev environment on a local Kind cluster. The full system has two loops:

Outer loop (CI): git push triggers a real GitHub Actions workflow. The job runs on a self-hosted runner inside your Kind cluster. Kaniko builds the image (no Docker daemon), pushes to an in-cluster registry, and the kindling operator reconciles a DevStagingEnvironment CR into a running Deployment with Service, Ingress, and auto-provisioned dependencies (Postgres, Redis, MongoDB, Kafka, RabbitMQ, and others — 15 dependency types).

Inner loop (dev): kindling sync watches local files, syncs them into the running container, and restarts the process. Sub-second feedback without rebuilding an image. When you're done iterating, stop sync and the deployment rolls back.

The inner loop runs inside the outer loop. You push code to get a real staging environment, then use sync to iterate on it without waiting for builds. When you're satisfied, push again and the CI pipeline produces the real artifact.

Technical Details

A few implementation notes for anyone reading the source:

File watching uses fsnotify with configurable debounce. Changes are batched and synced as a group to avoid thrashing the container with rapid saves.
Runtime detection parses /proc/1/cmdline via kubectl exec. The process name is matched against a lookup table, with fallback heuristics for bare interpreters (e.g., python3 running a gunicorn module gets detected as gunicorn by scanning the full command line for known framework entry points).
Architecture detection for compiled-language cross-compilation reads the Kind node's architecture via kubectl get node -o jsonpath='{.status.nodeInfo.architecture}'.
Distroless containers — containers without a shell — are handled by falling back to the Kubernetes API's tar-stream endpoint instead of kubectl cp, which requires tar in the container.
Wrapper injection patches the deployment spec's container command. The original command and revision number are recorded so rollback is exact, not just "undo the last change."
Default excludes skip .git, node_modules, __pycache__, vendor, dist, .next, build outputs, and other artifacts. Additional patterns can be added with --exclude.
The dashboard frontend is a TypeScript/React SPA built with Vite, compiled to static assets, and embedded into the Go binary at build time. No separate process, no npm at runtime.

Getting Started

brew install kindling-sh/tap/kindling
kindling init
kindling deploy -f dev-environment.yaml
kindling sync -d my-service --restart

Or open the dashboard and click Sync.

The getting started guide walks through the full setup, from cluster bootstrap to inner-loop iteration.

Contributing

Kindling is Apache 2.0 licensed and actively looking for contributors and early adopters. The codebase is Go (operator + CLI) and TypeScript (dashboard), built with Kubebuilder v4. Current areas where contributions would have the most impact:

Runtime profiles — adding detection and restart strategies for languages/frameworks not yet in the table (Scala, Haskell, OCaml, Swift, etc.)
Sync engine hardening — edge cases around symlinks, large binary files, permission preservation across different container base images
Dashboard features — log streaming, resource usage visualization, multi-environment views
Testing — expanding e2e coverage across different project types and cluster configurations
Documentation — tutorials, example projects, integration guides for specific frameworks

If you're building microservices on Kubernetes and tired of waiting for builds, try it out. File issues, open PRs, or just tell us what breaks.

GitHub: github.com/kindling-sh/kindling
Docs: kindling-sh.github.io/kindling
License: Apache 2.0

Run Real K8s CI on your Laptop with Kindling

Jeff Vincent — Mon, 16 Feb 2026 07:09:42 +0000

TLDR: Kindling wires your GitHub repo to a local Kubernetes cluster. Every git push builds and deploys your app with real databases and services. No cloud CI minutes, no waiting. AI generates your workflow. A built-in dashboard gives you full cluster visibility.

Kindling is a Kubernetes operator that runs in a local KinD cluster. Point it at your repo, and it handles builds and deployments locally while you develop.

It spins up a GitHub Actions runner pool inside your cluster. When you push code, the runner builds your containers using Kaniko and deploys everything to the cluster. Your app gets real Postgres, Redis, Kafka, or whatever you need — already configured and wired up.

Since the initial release, the CLI has grown quite a bit. Here's what's new.

The operator supports 15 dependency types:

Type	Default Image	Port	Injected Env Var	Notes
`postgres`	`postgres:16`	5432	`DATABASE_URL`	Auto-creates `devdb` with user `devuser`
`redis`	`redis`	6379	`REDIS_URL`	Stateless, no persistence
`mysql`	`mysql`	3306	`DATABASE_URL`	Auto-creates `devdb` with user `devuser`
`mongodb`	`mongo`	27017	`MONGO_URL`	Root user `devuser`
`rabbitmq`	`rabbitmq:3-management`	5672	`AMQP_URL`	Includes management UI on port 15672
`minio`	`minio/minio`	9000	`S3_ENDPOINT`	Also injects `S3_ACCESS_KEY` + `S3_SECRET_KEY`
`elasticsearch`	`docker.elastic.co/elasticsearch/elasticsearch:8.12.0`	9200	`ELASTICSEARCH_URL`	Single-node, security disabled
`kafka`	`apache/kafka`	9092	`KAFKA_BROKER_URL`	KRaft mode (no ZooKeeper)
`nats`	`nats`	4222	`NATS_URL`	Lightweight messaging
`memcached`	`memcached`	11211	`MEMCACHED_URL`	In-memory cache
`cassandra`	`cassandra`	9042	`CASSANDRA_URL`	Single-node dev cluster
`consul`	`hashicorp/consul`	8500	`CONSUL_HTTP_ADDR`	Dev-mode agent
`vault`	`hashicorp/vault`	8200	`VAULT_ADDR`	Dev mode, also injects `VAULT_TOKEN`
`influxdb`	`influxdb`	8086	`INFLUXDB_URL`	Also injects `INFLUXDB_ORG` + `INFLUXDB_BUCKET`
`jaeger`	`jaegertracing/all-in-one`	16686	`JAEGER_ENDPOINT`	Also injects `OTEL_EXPORTER_OTLP_ENDPOINT`

AI-powered workflow generation

kindling generate scans your repo and calls an LLM to produce a complete GitHub Actions workflow. It walks your project tree, reads Dockerfiles, dependency manifests, and source files, and sends the right context to the model. It recognizes 20+ ecosystems — Go, Node, Python, Rust, Java, Ruby, PHP, Elixir, .NET, and more.

kindling generate -k <your-api-key>

It also detects external credential references and OAuth/OIDC patterns in your code. If it finds them, it suggests follow-up commands like kindling secrets set and kindling expose. Supports both OpenAI and Anthropic models via the --provider flag.

The generated workflow drops into .github/workflows/dev-deploy.yml, ready to go on your next push.

Embedded dashboard

kindling dashboard launches a local web UI embedded directly in the CLI binary. No extra installs, no Docker image — just run the command and open http://localhost:9090.

kindling dashboard

The dashboard gives you full cluster visibility: nodes, deployments, pods, services, ingresses, secrets, events, DSEs, runner pools, and RBAC resources. It also exposes action endpoints — you can deploy, manage secrets, create runners, set env vars, expose tunnels, restart or scale deployments, and apply raw YAML, all from the browser.

There's a command palette (Cmd+K) for quick actions and a sidebar with real-time tunnel status when you have a public URL active.

Public HTTPS tunnels

kindling expose creates a secure tunnel from a public URL to your cluster's ingress controller. Useful for OAuth callbacks, webhook testing, or showing someone your work without deploying to the cloud.

kindling expose

It runs cloudflared (or ngrok) in the background and patches your ingress routes to use the tunnel hostname. When you're done, kindling expose --stop tears it down and restores the original ingress config. The tunnel URL is also stored in a ConfigMap so the deploy action can auto-discover it during CI.

Secrets management

kindling secrets manages external service credentials as Kubernetes Secrets. API keys, tokens, connection strings — set them once and they're available to your deployments.

kindling secrets set STRIPE_KEY sk_test_abc123
kindling secrets list

Credentials are also saved to .kindling/secrets.yaml locally, so kindling secrets restore can re-create them after a cluster rebuild.

Live env var management

kindling env sets or removes environment variables on a running deployment without redeploying. Changes take effect immediately via a rolling restart.

kindling env set my-app DEBUG=true LOG_LEVEL=verbose
kindling env unset my-app DEBUG

Selective rebuilds

kindling push wraps git push with an optional service filter. Tag your push so CI only rebuilds the services you changed instead of the full pipeline.

kindling push --service ui --service gateway

It amends the HEAD commit with a [kindling:ui,gateway] marker that CI parses. Omit --service to rebuild everything as usual.

Other CLI commands

kindling status — Full environment overview: cluster health, operator, registry, runner pools, DSEs, deployments, ingress routes, and unhealthy pod logs. Color-coded, no flags needed.
kindling logs — Streams operator logs. --all for all containers, --since 10m to adjust the window.
kindling reset — Removes the runner pool and its token secret without touching the cluster or your deployments. Good for switching repos.
kindling destroy — Tears down the entire Kind cluster.

Setup

You need Docker, Kind, and kubectl installed.

1. Install the CLI

Homebrew (recommended — macOS and Linux)

brew install kindling-sh/tap/kindling

This installs the latest release and pulls in Kind and kubectl as dependencies.

Pre-built binaries

Download the latest release for your platform from GitHub Releases:

# macOS (Apple Silicon)
curl -Lo kindling.tar.gz https://github.com/kindling-sh/kindling/releases/latest/download/kindling_$(curl -s https://api.github.com/repos/kindling-sh/kindling/releases/latest | grep tag_name | cut -d '"' -f4 | sed 's/^v//')_darwin_arm64.tar.gz
tar xzf kindling.tar.gz
sudo mv kindling /usr/local/bin/

# macOS (Intel)
curl -Lo kindling.tar.gz https://github.com/kindling-sh/kindling/releases/latest/download/kindling_$(curl -s https://api.github.com/repos/kindling-sh/kindling/releases/latest | grep tag_name | cut -d '"' -f4 | sed 's/^v//')_darwin_amd64.tar.gz
tar xzf kindling.tar.gz
sudo mv kindling /usr/local/bin/

# Linux (amd64)
curl -Lo kindling.tar.gz https://github.com/kindling-sh/kindling/releases/latest/download/kindling_$(curl -s https://api.github.com/repos/kindling-sh/kindling/releases/latest | grep tag_name | cut -d '"' -f4 | sed 's/^v//')_linux_amd64.tar.gz
tar xzf kindling.tar.gz
sudo mv kindling /usr/local/bin/

macOS Gatekeeper note: If you see "Apple could not verify kindling is free of malware", clear the quarantine flag:
sudo xattr -d com.apple.quarantine /usr/local/bin/kindling

Build from source

Requires Go 1.25+:

git clone https://github.com/kindling-sh/kindling.git && cd kindling
make cli
sudo mv bin/kindling /usr/local/bin/

2. Bootstrap the cluster

kindling init

This creates a KinD cluster, installs an in-cluster registry, sets up ingress-nginx, and deploys the operator. Takes about a minute.

3. Create a GitHub repo

You need a repo on GitHub before you can register a runner to it. The easiest way is with the GitHub CLI:

gh repo create my-app --public --clone && cd my-app

If you don't have gh installed, create the repo on github.com/new, then clone it:

git clone git@github.com:<you>/my-app.git && cd my-app

4. Register your GitHub runner

Note: the following -r should be in the format of <your-gh-user-name>/my-app if you followed the above exactly.

kindling runners -u <github-user> -r <owner/repo> -t <your-pat>

You need a GitHub PAT with repo scope. The runner registers with GitHub and starts polling for jobs.

5. Generate your workflow

You can write the GitHub Actions workflow by hand, or let the AI generate it:

kindling generate -k <your-openai-or-anthropic-key>

This scans your project and writes .github/workflows/dev-deploy.yml. Review it, tweak if needed, and move on.

6. Deploy the sample app

cp -r ~/kindling/examples/microservices/* .
cp -r ~/kindling/examples/microservices/.github .

git add -A && git commit -m "initial deploy" && git push

7. Watch it deploy

Check the Actions tab in GitHub or watch pods locally:

kubectl get pods -w

Your app, Postgres, and Redis will spin up and start running.

8. Access your app

Navigate in your browser to:

http://<your-gh-username>-ui.localhost

9. Make changes

# Edit code
git add -A && git commit -m "update" && git push

Fresh build and deploy in seconds.

How it works

The GitHub workflow uses two actions:

kindling-build builds your image with Kaniko and pushes to the in-cluster registry.

kindling-deploy generates a DevStagingEnvironment resource. The operator reads it and creates your Deployment, Service, Ingress, and backing services.

Here's a sample app workflow:

- name: Build image
  uses: kindling-sh/kindling/.github/actions/kindling-build@main
  with:
    name: sample-app
    context: ${{ github.workspace }}
    image: "registry:5000/sample-app:${{ env.TAG }}"

- name: Deploy
  uses: kindling-sh/kindling/.github/actions/kindling-deploy@main
  with:
    name: "${{ github.actor }}-sample-app"
    image: "registry:5000/sample-app:${{ env.TAG }}"
    port: "8080"
    ingress-host: "${{ github.actor }}-sample-app.localhost"
    dependencies: |
      - type: postgres
        version: "16"
      - type: redis

What's next

Multi-cluster support
Built-in observability
Helm chart integration
Change detection at the operator level

Contributing

Contributions welcome. Open an issue or PR on the GitHub repo. Apache 2.0 licensed.

Conclusion

Kindling gives you local CI speed with real infrastructure. Push code, get a deployed app with real databases in seconds. Generate your workflow with AI, manage secrets and env vars without redeploying, expose your app publicly for OAuth testing, and monitor everything from a built-in dashboard. If you're tired of waiting for cloud CI or want tighter feedback loops, give it a try.

Star the repo if you find it useful.

Say "Hello" to Byte Sized K8s

Jeff Vincent — Sat, 30 Sep 2023 19:26:00 +0000

I'm excited to announce the start of a new side project, in which I'm creating "byte sized" videos that explain specific Kubernetes topics in 10 minutes or less.

If you're thinking of getting started with K8s, but don't have time to dig into a textbook, check out this video series.

Here are the first two installments:

Byte Sized K8s: Containers

Byte Sized K8s: Pods

Thanks for reading, and happy developing!!!

Forem: Jeff Vincent

From Source to Production with OAuth: The Full Kindling Flow

What we're building

Step 1: Init the cluster

Step 2: Register a CI runner

Step 3: Generate the CI workflow

Step 4: Create Auth0 and Stripe accounts and set credentials

Create an Auth0 application

Create a Stripe webhook endpoint

Set the pre-deploy secrets

Step 5: Push and deploy

Step 6: Start a tunnel and configure OAuth + webhooks

Configure Auth0 callback URLs

Create the Stripe webhook endpoint

Set the real PUBLIC_URL and webhook secret

Step 7: The inner dev loop

Step 6: The inner dev loop

Step 8: Test the OAuth and Stripe flows

Step 9: Deploy to production

What just happened

Try it

What I've Actually Learned Using Coding Agents to Build Software

Pattern Inertia Is Real, and It Cuts Both Ways

It Will Write Like You (If You Let It)

Your Pipeline Is the Real Feedback Loop

Strong Types Are Cheap Insurance

What This Actually Changes About Your Job

Kindling v0.6.0: Hot Reload for Every Language in Your Kubernetes Dev Environment

The Problem

How kindling sync Works

Runtime Detection

Four Restart Modes

Automatic Rollback

Load: Full Rebuild Without the CI Round-Trip

The Dashboard

What Kindling Actually Is

Technical Details

Getting Started

Contributing

Run Real K8s CI on your Laptop with Kindling

AI-powered workflow generation

Embedded dashboard

Public HTTPS tunnels

Secrets management

Live env var management

Selective rebuilds

Other CLI commands

Setup

1. Install the CLI

Homebrew (recommended — macOS and Linux)

Pre-built binaries

Build from source

2. Bootstrap the cluster

3. Create a GitHub repo

4. Register your GitHub runner

5. Generate your workflow

6. Deploy the sample app

7. Watch it deploy

8. Access your app

9. Make changes

How it works

What's next

Contributing

Conclusion

Say "Hello" to Byte Sized K8s

How `kindling sync` Works