2026-08 on Funky Si's Blog (Dev)

GitOps with Flux on my k3s cluster

funkysi1701@gmail.com (funkysi1701) — Tue, 18 Aug 2026 08:00:00 +0000

I already knew how to put things on a Kubernetes cluster. Helm packages the YAML. kubectl apply makes it exist. cert-manager mints the certificates. What I did not have was a boring answer to “what happens next week, when I have forgotten which laptop I ran that from?”

GitOps is that answer, at least for platform on my homelab. In practice, GitOps means keeping the desired cluster state in git and having an in-cluster controller continuously reconcile the live cluster back to that state. simon-cluster is the name I gave the k3s cluster I run at home — a small Kubernetes estate for shared ingress, certificates, monitoring, and the GitHub Actions runners this blog builds on. Flux CD on that cluster watches a private platform repo and keeps it in line with main.

The useful part is not “I put YAML in git.” It is the split. Flux owns MetalLB, Traefik, cert-manager, GitHub runners, the in-cluster registry, Cloudflare Tunnel, and monitoring. Application Helm releases in develop / main / test still come from their own repos and pipelines. Azure DevOps is still in that second column. Flux is not pretending to be the whole estate.

Pull, not push

A lot of “GitOps” talk is really CI with extra steps: a pipeline authenticates to the cluster and runs helm upgrade. That is a push. It works. I still do it for apps.

Flux is a pull. The cluster has a GitRepository pointed at a private platform repo on main. Child Kustomization objects apply paths under that repo on a schedule. If someone (or some leftover pipeline) changes a Flux-managed object by hand, the next reconcile puts it back.

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
 name: flux-system
 namespace: flux-system
spec:
 interval: 1m
 ref:
 branch: main
 url: https://github.com/example/example-config.git

Bootstrap is once: install the Flux controllers (gotk-components.yaml), give Flux a git credential and an age key for SOPS, apply gotk-sync.yaml. After that I mostly work in git rather than reaching for kubeconfig.

git add -A && git commit -m "…" && git push
flux get all -A
flux reconcile kustomization flux-system --with-source

I still keep kubectl for poking at pods. I try not to use it as the source of truth for anything Flux already owns.

How the repo is laid out

clusters/simon-cluster/ # Flux bootstrap + child Kustomizations
infrastructure/ # HelmRepositories, HelmReleases, CRs, SOPS

clusters/simon-cluster is the entry point Flux syncs. Each child Kustomization is a named slice of the platform with its own interval, dependsOn, and (where secrets live) SOPS decryption. infrastructure/ is the actual YAML those slices apply.

Order matters. Helm charts cannot install until the HelmRepository objects exist. cert-manager cannot come up until those sources do. A shortened version of the cert-manager slice looks like this:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
 name: cert-manager
 namespace: flux-system
spec:
 interval: 30m
 dependsOn:
 - name: sources
 path: ./infrastructure/cert-manager
 prune: true
 wait: true
 decryption:
 provider: sops
 secretRef:
 name: sops-age

prune: true is the bit people skip and then regret. If you delete the manifest and Flux still has prune off, the live object sits there forever looking “fine.” wait: true plus dependsOn is the other half of that: cert-manager does not race Traefik because the Kustomization will not move on until the slice is healthy.

The Helm install itself is a HelmRelease, not a pipeline task:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
 name: cert-manager
 namespace: cert-manager
spec:
 interval: 30m
 chart:
 spec:
 chart: cert-manager
 version: "v1.21.0"
 sourceRef:
 kind: HelmRepository
 name: jetstack
 namespace: flux-system

Same idea as deploying with Helm , except the cluster is the thing that runs helm, not me.

One change, end to end

A typical platform change is dull, which is the point.

Edit YAML under infrastructure/… (chart version, values, a ClusterIssuer, a runner replica count).
Open a PR, merge to main.
Wait for the Kustomization interval, or flux reconcile if I am impatient.
flux get hr,ks -A until the slice is Ready.

If it is not Ready, read the condition before assuming git and the cluster agree. That command is the homelab equivalent of a pipeline log.

I already wrote about Let’s Encrypt on this cluster when cert-manager was a kubectl apply of upstream YAML. That install now lives in git as the HelmRelease above plus ClusterIssuer manifests. The DNS-01 token is not in those files in plaintext; it is a SOPS-encrypted Secret Flux decrypts on the cluster.

Grafana followed the same path. I first ran it in Docker Compose for .NET metrics . The homelab copy now sits in the monitoring namespace, owned by Flux, with dashboards as ConfigMaps in the same repo. Compose taught me the product; GitOps is how it stays installed when I am not watching.

This blog is in the picture too, just not as a website on the cluster. Production is still Azure Static Web Apps. What Flux does provision for this repo is a pool of Actions Runner Controller runners labelled k8s, so GitHub Actions can build on the homelab instead of burning hosted minutes. The RunnerDeployment is YAML in that private platform repo. The workflows stay in this git repo. That is the split in miniature.

Secrets in git, not in chat

Platform secrets are *.enc.yaml files encrypted with SOPS and age . Flux has a sops-age Secret in flux-system (created once, not committed) and Kustomizations that need secrets set decryption.provider: sops.

What is in git: Cloudflare DNS-01, the ARC GitHub token, Grafana admin, registry pull secrets, tunnel token. What is not: the age private key. If you clone that private platform repo you get ciphertext and the public key in .sops.yaml. That is enough to add a secret if you have the private key locally; it is not enough to read the live ones.

This is not Azure Key Vault. A homelab cluster does not need a cloud HSM to stop me committing a PAT. It needs encryption at rest in git and a bootstrap secret that never hits GitHub. The repo documents how SOPS and age are wired up.

What Flux does not own

I keep an ownership map in that private platform repo because GitOps fails the moment two systems apply the same object. Deciding who is allowed to apply has been more useful than any controller version pin. The short version:

Owner	Examples
This repo (Flux)	Namespaces, MetalLB, cert-manager, Traefik, ARC, Zot, cloudflared, monitoring
App git + CI	Helm releases in `develop` / `main` / `test` (blog chart, TrekRanks, SQL, …)
k3s / the node	CoreDNS, local-path, metrics-server, disable bundled Traefik

Several apps still deploy from Azure DevOps. That is fine. It is push CI, and Flux will not “fix” a Deployment it does not declare. If an old pipeline and a HelmRelease both think they own Grafana, they will fight. I moved monitoring into Flux on purpose so there is one owner.

k3s itself is not GitOps in this repo either. Node join, versions, and “do not run the bundled Traefik” are documented and applied on the hosts. Flux cannot bootstrap the thing that runs Flux.

In-cluster Renovate is a small extra: it opens image-bump PRs against that private platform repo. Upgrades become git history too, not SSH-and-hope. One note on Renovate, the Renovate package itself is very noisy, with multiple update PRs raised per day. I have chosen to automerge these, but you may want to consider skipping this package or updating on a schedule.

I would not start a new cluster by SSHing in and applying twenty manifests. Ingress, certificates, runners, and monitoring are shared, so they belong in git from the start. I would still start a new app with a pipeline and a Helm chart in that repo — Flux HelmRelease is how those charts get onto the cluster, not a replacement for packaging.

I have not moved every Helm chart into Flux, and I am not pretending that is a moral failing. GitOps earned its place here by making the platform dull. Dull is the goal.

If you run Kubernetes at home — or you are weighing GitOps against push CI — how do you split platform from apps? Full pull, pipelines only, or a hybrid like mine? I would be interested to hear what works for you in the comments.

If this is your first step on the same path, these posts are where I started: learning Kubernetes , deploying with Helm , and Let’s Encrypt on the cluster . For a monthly email when I publish something new, subscribe to the newsletter .

Pairing with AI in VS Code and Cursor

funkysi1701@gmail.com (funkysi1701) — Fri, 07 Aug 2026 12:00:00 +0000

On a lot of days my pair programmer is not a person. It is Copilot finishing a method, or Cursor proposing a multi-file edit I still have to own.

Back in April I covered how I use ChatGPT, Cursor, and Copilot on side projects . That was mostly about which tool I reach for. Here I want to talk about what that looks like when the code is .NET—C#, Blazor, Azure Functions—and I am working in VS Code or Cursor.

I am not claiming a universal workflow. These are habits that have helped me in 2026.

A thin tools map (so we can move on)

I still use the same three buckets. The only change is which bucket I reach for when the stack is .NET-heavy.

Situation	What I reach for
Framing a design question or learning path	ChatGPT (browser)
Multi-file change across a solution	Cursor
Finish this method / test / YAML stanza	GitHub Copilot in the editor
“Build AI into the product”	Separate concern — see Using AI with .NET and Semantic Kernel

If you already read the April post, you can skim this table and skip ahead. The interesting part is not the brand names; it is what happens after a suggestion appears.

For vocabulary (RAG, LLM, Copilot, and friends), Common AI and Copilot Terms is still a useful glossary.

Scenario: unfamiliar code that is still “mine”

Episode Atlas grew the way hobby apps do: Blazor on the front, Azure Functions and Cosmos DB behind, enough moving parts that I forget my own choices. When I come back after a few weeks, I do not want a greenfield tutorial from a chat window. I want something that has seen the repo.

In Cursor I ask questions like “where does per-user progress get written?” or “what breaks if this Cosmos query assumes a different partition key?” The useful answers cite my folders and types. The useless ones invent a service layer I never wrote.

What I do next matters more than the first reply:

Open the files it named and confirm they are the real path.
Diff any proposed edit against how neighbouring code already looks.
Run dotnet build (and the bit of the app I touched) before I trust it.

The productivity win is not that the model “knows Episode Atlas.” It is that I spend less time remapping a codebase I already wrote.

Scenario: boring glue that still has to be correct

This blog is Hugo plus Azure Static Web Apps, with GitHub Actions and a pile of Node/Python checks. A lot of the work is glue: a layout partial, a workflow step, a Playwright selector after a theme tweak. Copilot is often enough when I already know the shape—finish the next YAML key, sketch a test that matches the one above.

Cursor earns its keep when the change spans files: “update this partial and the smoke test that asserts the heading,” or “align the SWA config check with what CI runs.” Those are exactly the edits where an incomplete suggestion is worse than no suggestion—half-applied config fails in ways that waste an evening.

On Blazor and Functions work the same pattern shows up as DTOs, mapping, and tests. Copilot is fast at the third similar test. Cursor is better when the DTO, the endpoint, and the client all need to move together.

Scenario: debugging when the model is too confident

I have let an assistant send me on a wild goose chase: wrong package version, an API that never existed, a “fix” that compiled and still left the bug. A human pair who is sure and wrong is more dangerous than one who says “I am guessing.”

When something fails, I try to feed the model the error text and a failing test, not a vague description of what I think is wrong. If the first patch does not change the symptom, I stop re-prompting the same story. I read the stack, check docs, or bisect—same as I would without AI.

Side projects are a forgiving place to learn that discipline. Production systems are not. Secrets, customer data, and employer code stay out of tools unless policy clearly allows them; I wrote about that boundary in the side projects post and I still follow it.

Guardrails that actually saved me time

These are the practices that keep AI pairing from becoming AI babysitting:

Read every diff you did not type. Especially NuGet names, HTTP routes, auth, and anything touching data.
Prefer project conventions over “cleaner” internet defaults. If my solution uses one DI style, I reject the rewrite that introduces another for a one-line fix.
Verify against official docs when the call looks unfamiliar. Models still hallucinate plausible APIs.
Keep the human review bar. I treat agent output like a junior’s pull request: helpful when it is right, never something I merge on trust alone.
Match depth of context to the task. Do not paste half a solution into a browser chat for a one-line rename; do not ask inline Copilot to redesign a Functions + Cosmos flow.

What “productivity” has meant for me

I am faster at first drafts and at navigating code I have not opened in a month. I am not faster at skipping judgment. If anything, the cost of a bad accept is higher because the broken change can look polished.

That lines up with the longer argument in AI Won’t Replace Developers, But It Will Redefine Us : the work shifts toward directing, reviewing, and verifying. I see that every time I open Cursor or Copilot on Episode Atlas, this blog, or whichever .NET side project I am tinkering with that week.

If you are doing similar work in C# or Blazor, leave a comment and tell me which tool you reach for first—and what you still refuse to hand to an assistant. I am always curious how other people draw that line.