|
This entire infrastructure β Kubernetes cluster, GitOps pipeline, monitoring stack, and demo app β is running live on a single ARM server provisioned for free on Oracle Cloud.
A complete DevOps ecosystem running on a single ARM instance
Two ways to look at the same running cluster: raw data straight from the Kubernetes API, or the Grafana dashboards it feeds.
Virtual creatures living as Kubernetes pods. Feed them or they die β and every action becomes a Prometheus metric.
Collecting metrics is the easy part. The gap between a dashboard and being on call is the alert β and what it triggers. Here is the full loop, running in production above, measured end to end.
A business rule evaluates max(tamagotchi_creatures_dead_total) > 0 every 30s. The for: 1m is what stops a pod restart from triggering anything.
Routing is done on labels, never on alert names. The rule carries remediation: auto, and that single label sends it to a machine instead of a human. Ten more alerts can be added tomorrow without touching the routing.
A webhook workflow lists the creatures, keeps only the dead ones, revives them, and records what it did. A silent remediation is an outage you never learn about.
revived: 6 Β· HTTP 200The API updates the gauge, Prometheus scrapes it, the alert resolves on its own. Measured end to end, no human involved: 91 seconds for a fresh incident, near-instant when a death lands while the alert group is already active.
Alerting only on the symptom is an anti-pattern: automation would repair it silently, the alert would always resolve itself, and the day the remediation breaks, nobody would know. So a second rule watches the remediation itself β if creatures are still dead ten minutes later, TamagotchiSelfHealingFailed goes critical and asks for a human. Knowing to alert on the failure of your automation, rather than on the incident it handles, is the difference between having read about SRE and having been on call.
The alert chain above tells you when something breaks. An SLO tells you how much broken you can afford before it matters β and how much of that budget is already spent.
The SLI is request-based, not just up: 1 - (failed requests / total requests), summed over the window rather than averaged, because averaging ratios lies when traffic isn't flat. Two Prometheus recording rules compute it continuously β tamagotchi:availability:ratio30d and tamagotchi:error_budget:consumed_ratio30d β so Grafana only ever reads a pre-computed number, never re-runs a 30-day range query per dashboard load. The 30-day window is real, not decorative: Prometheus's own retention was bumped from 15 days to 30, and β since it turned out to be running on ephemeral storage β given a persistent volume so a pod restart doesn't reset the clock.
Reading about the self-healing chain above is not the same as watching it fire. This button wipes out every living creature in the live database β not a pod, not a Kubernetes object.
βοΈ Send a Meteor calls POST /creatures/:id/kill on tamagotchi-api for every currently living creature, setting each one's is_alive to false β the same state natural decay reaches on its own. That's what feeds tamagotchi_creatures_dead_total, which is exactly what TamagotchiCreatureDied watches. A full wipe makes the alert impossible to miss. Nothing here touches a pod: what heals it is the automation described above β Prometheus notices within a minute, Alertmanager routes on the remediation: auto label, and n8n revives every one of them. Usually under 90 seconds, not instant on purpose β the full chain runs for real, no shortcut.
Rate-limited to one strike per minute, capped per hour β this kills every creature at once, it needs room to actually recover before it can fire again. Watch the counts above, or the Tamagotchi dashboard in the Live Infra tab, to see a meteor strike land and, a few minutes later, get reversed. Want to remove a creature permanently instead? That's a per-creature action in the app itself β the opposite of Adopt, not a chaos event.
I'm an independent DevOps & Platform Engineer with 12+ years of experience. This site isn't a slide deck β it's a production cluster you can click through right now. That's the same rigor I bring to your platform.
The cluster you're browsing is not a managed service. I architected and provisioned every layer of it myself on Oracle Cloud: VCN and subnet design, route tables, internet and NAT gateways, security lists and firewall rules, compute instance sizing (ARM Ampere A1), block and boot volumes, DNS records and TLS termination. Kubernetes only came afterwards β on top of a network I had drawn first. None of it is clicked in a console: the network and the instance are declared in Terraform, everything inside the machine and the cluster in Ansible. Both are public, and rebuild the whole platform from zero in under an hour.
Multi-cloud and bare-metal virtualization are my daily work at EXFO, across 11 Kubernetes clusters β Oracle Cloud is simply where I pay for it myself.
Design, migration, and hardening of K8s clusters (EKS, AKS, OpenStack, K3s). Internal Developer Platforms and Golden Paths that let your teams ship without opening a ticket.
ArgoCD App-of-Apps, GitLab CI, Gitea Actions, Terraform and Crossplane. On my last assignment: release cycles cut by 40% and deployments that stopped being an event.
Prometheus, Grafana, Loki, meaningful SLOs and alerts that actually wake the right person. From blind infrastructure to a 99.9% SLA you can prove.
Trivy/SBOM scanning built into the pipeline, network policies, secrets management β and a cloud bill audit, because the best-architected platform is also the one you can afford.
Tell me about your context in a few lines β I'll reply within 48 hours with an honest read: what I'd do, how long it takes, and whether you even need me.
Time & materials or fixed price Β· short audits as well as long-term assignments Β· first call always free.
Every layer is declared as code, and the code is public. If this server disappeared tonight, one terraform apply and one ansible-playbook would bring it all back in under an hour β network, cluster, GitOps, observability, applications and data.
stops where the Oracle API ends
VCN, subnet, internet gateway, route table, security list, the ARM instance, and a reserved public IP. Terraform is used for what it does best: cloud resources that have a state, where drift must be detected and a plan reviewed before anything changes.
everything inside the machine and the cluster
Packages, firewall, K3s, Helm releases, manifests, images, backup timer. Ansible is used where Terraform would only have local-exec: it is idempotent, replays on a live cluster to correct drift, and turns Helm values into versioned files instead of leaving them buried in a release's state.
The full recovery procedure β including the three traps that cost me hours: the K3s cloud-provider flags that silently taint the node, Linkerd breaking ArgoCD's internal gRPC, and Oracle's Ubuntu image dropping ports 80 and 443 whatever the security list says.
Access all tools directly. Visitor accounts are read-only for security.
GitOps continuous delivery. See application sync status, health, and history.
guest / visitor2026
Dashboards for K8s metrics, Tamagotchi stats, and application performance.
Public Access
Query raw metrics with PromQL. Explore Tamagotchi custom metrics.
No authentication
Self-hosted Git server. Browse the Tamagotchi source code and K8s manifests.
Public repos
The live 3-tier demo app. Adopt creatures, see metrics flow through the entire stack.
Interactive!
Native Continuous Integration pipeline compatible with GitHub Actions.
Login via Gitea
Receives Alertmanager webhooks and revives the dead creatures. This is the remediation step of the self-healing chain, not a demo.
Private instance
Ultralight Service Mesh providing observability, reliability, and security.
No authentication