The Muppit Sphere
Local-first, purpose-driven.
A practical collection of my working notes and real configurations learnt the hard way.
Play Blaster, then build your own.
Play the retro Blaster game at https://blaster.muppit.au, try to beat the high score, then follow the Blaster GitOps series to build and host your own game or app. When yours is live, message me the link.
I start from the ground up with local-first, on-premises infrastructure on Kubernetes. As I finish documenting the core pieces, I will show how I build apps in Cursor and deploy them to the cluster with GitOps.
You will find my runbooks, notes, and small, focused designs to help you build quickly. I add to it regularly.
What this is
A working notebook from real projects that solve real needs. It helps you and future me fix something, create something, or understand something without digging through thousands of files. The approach is simple: keep dependencies low, keep control high, and prefer local first. The goals are privacy, uptime, and clear guidance we can both use.
This is my approach, not the only one. If you have a better way and you are happy to share, I would love to learn from you.
Muppitify®
Muppitify is my way of aligning engineering craft with human purpose. It is a local-first, modular way of working, with automation and rollback, used in service of something you actually care about.
It blends three areas:
- Ikigai: work at the overlap of what you care about, what you are good at, what is needed, and what sustains you.
- Coaching: clarity of intent, small experiments, honest reflection, and accountability so insight turns into action.
- Engineering: modular design, own-your-core infrastructure, automation with guardrails, and documentation that outlives the author.
In practice that means small, well-named pieces; running the essentials on infrastructure you control; GitOps with rehearsed reversals; and runbooks others can repeat. The aim is the same for clusters and for people: less drift, more deliberate change, and a clear "why" behind each step.
Muppitify applies as much to coaching and personal change as it does to the technology you use: take messy reality, break it into workable parts, and move step by step towards something more intentional, with each step tied back to why you are doing it.
If you want to know more about me, please see Andy the Muppit.
Who this helps
- Practitioners who usually build in the cloud and are now exploring on-premises, where internal certificates and routing are your responsibility.
- Practitioners who want dependable routines and clear, proven runbooks.
- Teams that value privacy, control, and predictable costs.
- Solo operators and small businesses with a limited budget who want to avoid ongoing cloud fees.
I show small clusters that perform well without unnecessary overhead that can scale to enterprise-grade when needed.
What you will find
- Kubernetes: design choices, setup, operations, and runbooks. Start with foundation, provisioning, and the full runbooks.
- Applications: local-first apps I am building, including a fitness coach and a retro blaster game. Browse them all in the applications section.
- Cluster-wide wildcard TLS trust: how to roll out cluster-wide trust for your wildcard certificate using cert-manager trust-manager and Gatekeeper, keeping the private key in a single trust namespace while distributing only the public certificate to opted-in namespaces. Start with Cluster-wide wildcard TLS trust.
- Identity provider series: how to run your own identity provider on Kubernetes (ZITADEL), including OAuth/OIDC setup, SSO for cluster services, secrets management with SOPS, backups and restores, and practical hardening patterns. Start with Identity provider overview.
- WordPress GitOps series: how to host your own WordPress on Kubernetes with full control, including GitOps deployments, hardened ingress, external cron jobs, Redis object cache, and practical backup and restore workflows. Start with WordPress GitOps summary.
- Blaster GitOps series: an end-to-end, real-world walkthrough of taking a Next.js arcade game from a laptop to an on-prem Kubernetes cluster using GitLab CI, FluxCD, SOPS, and Cloudflare Origin CA. Start with the Blaster GitOps summary.
- Code vulnerabilities: my notes and runbooks to quickly answer what the issue is, whether it affects anything I run, and the exact steps to verify and remediate. Start with Code vulnerabilities.
- Runbooks: focused, end to end runbooks that serve a specific purpose. Browse them all in the runbooks section.
- Changelog: what changed and why. See the changelog.
- About: who I am and why I am doing this. See: Andy the Muppit.
Where possible, each page follows the same shape so you can move quickly: context for when and why to use it; prerequisites with versions, access, and gotchas; the steps and what to expect; quick checks to verify it worked; a rollback path if it did not; and brief notes from real use as evidence.
How I build: Infrastructure as Code (IaC) and GitOps
My approach is Infrastructure as Code for provisioning and GitOps for day 2 operations. It is declarative, versioned, reviewable, and reproducible. Remaining gaps are host imaging, base network config, and automated preflight tests.
| Practice | What it means | Tooling here |
|---|---|---|
| IaC | Infra is defined declaratively in code, version-controlled, applied by automation. | Kubespray (Ansible) for cluster build and OS tuning |
| GitOps | Desired cluster state lives in Git; controllers reconcile the running state to match. | FluxCD for manifests and Helm releases |
Additional pieces that make it reproducible and safe:
- SOPS + age stores secrets as encrypted text in Git.
- Pinned manifests and Helm for Calico, MetalLB (FRR), Ingress-NGINX, cert-manager with Cloudflare DNS-01, PostgreSQL, and your apps.
- Runbooks and rollback complete the loop for safe change.
Navigating the Sphere
New here or on a small screen? See the navigation page for a quick tour of the sidebar, table of contents, search, and themes.
How I keep Kubernetes "boring"
- Kubespray with Ansible for a single, repeatable build path.
- One container network interface (CNI) and one ingress across sites.
- GitOps for every add-on and every application.
- Image automation so new versions move from build to cluster through Git, not by hand edits on the cluster.
- Local registry and chart mirrors for control and resilience.
- Backups automated and restore tests proven end to end.
- Clear service level objectives for API, DNS, and ingress, with automated checks.
Why I am sharing this
I learn by doing and by building my own version. When something works, I write it up so others can use it, and I keep it current. You will see rough edges, decisions, and results, not just a tidy end state.
It is good to have an end to journey toward, but it is the journey that matters in the end.
Four rules I keep coming back to
- Fit for purpose: solve the real problem, not the imagined one.
- Automatic: repeatable with minimal manual steps.
- Observable: easy to see what is happening and why.
- Reversible: change it, and change it back safely.
Conventions
Commands
- Shell commands are in blocks; replace values in
<angle-brackets>.
Paths
- File paths are relative to repo sections unless noted.
Links and formatting
- Links prefer a single canonical source.
- Formatting is automated with Prettier and linters.
General info worth calling out.
Helpful advice or best practice.
Background or reference details.
Heads up: something to watch for.
Risky or destructive; proceed with care.
Contributing and corrections
This site is statically built through an automated process. If something is incorrect or could be improved, please message me with a short note and the page link. I read every suggestion and update pages regularly.
How I create the Sphere
Publishing is automatic once I commit a change.
Authoring
- Notes turned into Markdown with One Markdown.
- Authored in Obsidian.
- Published with Docusaurus and local full-text search.
Build and publish
- Built on a private GitLab runner (local-first).
- CI deploys the compiled site to Cloudflare Pages using Wrangler Direct Uploads.
- Public site served at https://sphere.muppit.au with TLS and CDN caching.
- Web Analytics enabled in Cloudflare for privacy-first visitor stats.
- No GitHub mirror. The repository stays on my local Kubernetes cluster.
If there is something specific you want on Kubernetes or related practices, ask for it. I am converting a lot of notes and will prioritise what helps most. If you use a different method and want to share it, message me and I will add it with credit.
I put rain in a cupboard and call it a cloud.