I needed to take notes every day, so I started the way most people do: pen and paper. It worked for a while. Then two things got annoying. I couldn’t search old notes, and I couldn’t put a code block in them. For an engineer, that’s a real problem. I tried a lot of note apps after that. None of them fit me 100%. So I built Loggo , a self-hosted note app for engineers, and it’s open source.

Loggo

Launched September 2026

Self-hosted note app for engineers. A day is a board; you drop Logs onto it all day.

↗

A day is a board

The idea is simple. Every day is a board. Through the day, you drop Logs onto it. A Log can be a thought, a command, a task, a snippet. I don’t have to decide where something goes. It goes on today’s board.

The board is an infinite canvas. You can drag Logs around and resize them, or switch to a masonry layout when you want something tidier. You can also move between days with keyboard shortcuts.

Writing and finding things

Each Log is written in a Markdown editor, so code blocks work the way I wanted from day one. There are tags and tasks, with due dates shown in the editor. You can attach files, and tables and YouTube links render inside the Log. Search is full-text and uses SQLite FTS5, which fixes the thing I hated most about paper.

Workspaces let you keep personal and professional notes apart. Daily templates keep each day’s entries consistent.

Notes stay as plain files

This is the part I care about most. Loggo uses SQLite for search and metadata, but every Log is also written as a Markdown file with YAML frontmatter, in a folder you can open without the app. The path includes the date, like workspaces/<slug>/YYYY/MM/DD/<ulid>-<slug>.md.

If the database breaks, the files are still there. The frontmatter carries enough information that loggo rebuild can build the database again from the folder. Loggo never runs git on that folder. Committing it is up to me.

Built on what I already had

Loggo is the third one after Recipery and Bookhoarder . By the time I started it, I already had a working stack from those two: Next.js, TypeScript, a pluggable storage layer (local disk or S3-compatible), and a way to ship it as a Docker container, on Cloudflare, or on Kubernetes. I didn’t want to throw that away and start from zero. So I built on top of it.

One thing is different this time. Recipery and Bookhoarder have no database. Loggo has one, because full-text search needs it. SQLite needs a single writer, so the Kubernetes setup runs one replica with a persistent volume. The Cloudflare version is a read-only demo, using D1 and R2.

Run it

docker run -d \
  --name loggo \
  -p 3000:3000 \
  -v /path/to/your/data:/app/data \
  ghcr.io/loggo-dev/loggo:latest

Open http://localhost:3000 and you have today’s board. The Docker guide has the full setup, and the docs cover the rest. The code is on GitHub under AGPL-3.0.

Conclusion

Paper couldn’t search or hold code, and the other apps never fit. Loggo does both, and my notes are plain Markdown files I can open without it. If I ever stop using the app, I lose nothing.

I used Mealie for my recipes for a couple of years. It’s a fine app, but every time I moved my stack to a new host, backup and restore turned into a gamble. Mealie keeps recipes in a database plus a separate folder for images, and moving both across at once, without them drifting out of sync, never went as smoothly as it should have. More than once I lost recipes and had to rebuild them from scratch. I’d had enough. I built Recipery , a self-hosted recipe library, and open sourced it from day one.

Recipery

Launched August 2026

Self-hosted recipe library backed by object storage, no database.

↗

Object storage instead of a database

The part I kept getting burned by with Mealie was the database. A recipe app’s data isn’t that complex, it’s mostly text and a photo, but a database still needs a proper backup step, a restore step, and both need to survive a version upgrade without breaking. I didn’t want to solve that problem again. Recipery doesn’t have a database at all. Everything, recipes, images, profiles, collections, is written straight to object storage: local disk, S3, or Cloudflare R2. The bucket is the only thing that persists.

That changes what “moving my stack” even means. If a host dies or I want to redeploy somewhere else, the container is disposable. I point a fresh one at the same bucket, and the library is there, because it never lived on that host to begin with. I can also keep as many recipes and photos as I want, S3 doesn’t care, and I’m not managing disk space on a VPS for a stray photo of a lasagna.

Getting recipes in

The other thing I wanted to fix was typing recipes in by hand. Paste a link from a food blog into Recipery, and it scrapes the title, ingredients, steps, and photo straight off the page.

Profiles and collections

Recipery supports multiple profiles, each set to admin or reader access, with an optional password per profile, so a shared library doesn’t mean shared edit rights. Recipes get grouped into collections instead of sitting in one flat list.

Shopping list and discovery

There’s a shopping list that pulls ingredients straight from a recipe, and if two recipes share an ingredient, it merges them into one line instead of listing it twice. Recipery can also search sites like NYT Cooking and BBC Good Food directly, either an open search when you don’t know what to cook, or a “find similar” search that starts from a recipe already in the library.

Conclusion

Recipery is still new, but it already solved the one thing that mattered to me: my recipes live in storage I control now, not in a database I have to babysit across every move. If losing a recipe collection to a bad restore sounds familiar, the code is on GitHub .

There’s a push right now for whole companies to adopt AI wholesale - dump every bit of context into it, write an AGENTS.md or INSTRUCTIONS.md in every repo so any project is discoverable and contributable by an agent, not just a human. Slightly funny, if you think about it: I’ve never once gotten a human teammate to actually read the README, and now we’re all writing better docs than we ever did, just aimed at a robot instead. The question that comes with it is the obvious one: does this make engineering redundant? Once all the context about a stack and its infrastructure is written down somewhere an agent can read it, are we next?

I don’t think that’s quite the right question, because we’ve already lived through a version of it.

We’ve Been Here Before

Did Kubernetes kill Ansible? Kind of. I haven’t written an Ansible playbook in years - if you handed me one right now I’d be squinting at the module syntax like I’d never seen it before. Configuration management didn’t stop mattering. Kubernetes just made server management easy enough that we stopped building our own node images at all - we just use whatever the cloud provider hands us, an AWS AMI built for us, no questions asked. And when did I last SSH into a node to debug something? Mostly never. If a node’s acting up, I kill it and hope the replacement doesn’t have the same problem. The next layer up went the same way: run a container on ECS Fargate, in a Lambda, or on Cloudflare Containers, and I genuinely don’t know or care what node it landed on - but that doesn’t mean nobody’s orchestrating it, it means I still decided that workload should be a container in the first place, what image it runs, what it’s allowed to talk to, how it scales, what happens when it fails. Kubernetes and serverless containers didn’t remove that layer of decisions, they moved the unit of work up from “the machine” to “the workload,” and everything below that layer got quietly automated away.

Nobody would say Kubernetes, or Fargate, or Cloudflare’s container platform, replaced infrastructure engineers. Each one replaced a specific layer of manual work - hand-building images, hand-patching boxes, knowing which node a workload landed on - and the engineers moved up to the layer above it every time. I think AI is doing the same thing again, one layer higher.

What Changed Day to Day

I use Claude daily to generate Helm charts and write Terraform modules. The part it actually removed from my day isn’t the thinking - it’s the lookup work. I don’t read through the AWS provider’s changelog to figure out what changed between v5 and v6 anymore; I describe what I want, in whatever shape I want the module or chart to end up, and Claude produces a version of it. It takes iteration to get it into the shape I’d actually ship, but once it’s there, it becomes the example for next time - especially with an AGENTS.md in the repo pointing at it.

The same thing happened one level down a while ago: I don’t hand-write raw Kubernetes YAML any more than I hand-write Ansible modules - that’s what Helm charts are for. Increasingly, I don’t hand-write the Helm chart either - the chart-as-a-dependency pattern I run now is exactly the kind of thing I described to Claude and let it draft first. I direct what it should do, and Claude writes it.

What Hasn’t Changed

I still need to know what a good Terraform module or a well-structured Helm chart looks like. When something genuinely goes wrong and killing the node isn’t an option, I still need to be able to SSH into it - the layer above doesn’t remove the layer below, it just moves how often you have to touch it. I’m also still the one deciding the actual shape of things: what the final version of a module looks like, what’s maintainable a year from now, how a chart should be deployed and versioned. AI does the time-consuming part. I still give the direction.

The Skill You Trade Away

The honest tradeoff: I’m faster at building and debugging things than I was two years ago, and I’m also visibly rustier at the fundamentals underneath that speed. My HCL syntax recall isn’t what it used to be. Four years ago I hand-wrote a nested for loop - four levels deep, tagging subnets across regions and availability zones in another AWS account - and it took me about an hour to get the syntax right:

locals {
  subnet_tags = merge([
    for account, regions in var.accounts : merge([
      for region, azs in regions : merge([
        for az, subnets in azs : {
          for subnet_id, tags in subnets :
          "${account}/${region}/${az}/${subnet_id}" => tags
        }
      ]...)
    ]...)
  ]...)
}

Four merge([...]...) calls stacked on top of each other just to flatten a map of a map of a map of subnets. Claude writes the equivalent in seconds now, and if you asked me to produce that from scratch today, I’d genuinely have to sit and think about it. My reflexes for debugging a broken node over SSH are a little slower than when that was the only way I knew how to do it. I can feel that happening in real time, the same way plenty of engineers who came up after Kubernetes never really learned to hand-roll a node OS image, and were fine, because they never needed to.

Where This Goes Next

The part I’m less sure about is how long “I still give the direction” holds. Right now I’m the one who decides the long-term shape of a stack, because I have the context and the agent doesn’t - not really, not beyond what’s written down in a repo’s AGENTS.md. But that’s exactly the gap those company-wide AI pushes are trying to close: give the agent the whole context, not just one repo’s. If that actually works, an agent with a genuine long-term view of the entire infrastructure - not just this Terraform module, but every decision made across every repo for years - might end up planning better than I do, the same way I can’t out-debug a tool that’s read every changelog for every provider I use.

I think AI is still busy eating the layer just below “give direction”. I’m not fully convinced that’s the last layer it eats. Ask me again in five years whether “I still give the direction” was the whole story, or just where I happened to be standing when I wrote this.

I wanted to add Chatwoot to my homelab, and I run everything there through GitOps with ArgoCD - a change is a commit, not a command I typed once from my laptop. Chatwoot ships an official Helm chart, so the obvious move was helm repo add, then helm install with my own values.yaml on top. That gets it running, but re-running helm upgrade by hand every time a value changes isn’t really GitOps, and if Chatwoot needed something the chart doesn’t ship - a NetworkPolicy, say - there’d be nowhere to put it except a second, unrelated manifest. That’s what pushed me toward a different pattern: instead of overriding an upstream chart’s values from the outside, make it a dependency of your own chart. Chatwoot is just the example - the pattern applies to any chart you’d otherwise be installing straight from someone else’s repo.

The Usual Way

❯ helm repo add chatwoot https://chatwoot.github.io/charts
❯ helm install chatwoot chatwoot/chatwoot -n chatwoot -f values.yaml

This works, but the chart version isn’t pinned anywhere reviewable - it’s whatever --version you typed, or whatever helm repo update happened to resolve to, sitting only in shell history. And values.yaml only makes sense next to that version; nothing ties the two together.

Depend on It Instead

Make a small chart of your own, and declare the upstream chart as a dependency rather than installing it directly:

# Chart.yaml
apiVersion: v2
name: chatwoot
type: application
version: 0.1.0

dependencies:
  - name: chatwoot
    version: 2.0.24
    repository: https://chatwoot.github.io/charts

❯ helm dependency build
Saving 1 charts

That resolves the dependency, writes the exact version and a digest to Chart.lock, and downloads the packaged chart into charts/chatwoot-2.0.24.tgz. A version bump is now editing one number in Chart.yaml and re-running helm dependency build - a real diff on Chart.lock, the same way a go.sum or package-lock.json pins a library version, instead of a fact that only lives in shell history. And because the chart and its dependency versions are just files, they deploy the same way everything else in a GitOps repo does - ArgoCD (or Flux, or helm upgrade in CI) reconciles the directory, rather than someone needing to remember to re-run a command.

Your chart, not the upstream one, is what gets installed - the upstream chart just hangs off it as a dependency.

Renovate Bumps It For You

The other benefit of turning a chart version into a plain field in Chart.yaml is that it stops being something only a human remembers to check. Renovate ’s helmv3 manager reads dependencies[].version the same way it reads a go.mod or package.json entry, checks the chart repository’s index for anything newer, and opens a PR:

That’s a genuine PR from this same repo, just a different chart (external-secrets) - same pattern as the Chatwoot one, one line changed, repository: untouched. Renovate leaves its usual summary alongside it:

It also keeps Chart.lock in sync with whatever it bumps, so the digest never goes stale next to the version. The one thing it won’t do on its own is refresh a vendored charts/*.tgz - for that you need postUpdateOptions: ["helmUpdateSubChartArchives"] in Renovate’s config, so the archive ArgoCD (or whatever renders the chart) actually reads gets updated in the same PR as the version bump. Either way, keeping a chart current goes from “remember to check upstream” to “review a PR” - the same place every other dependency bump in the repo already shows up.

Values, Same Shape as Before

Whatever you’d have passed with -f values.yaml against the upstream chart directly still works exactly the same - it just sits under the dependency’s name instead of the top level:

# values.yaml
chatwoot:
  ingress:
    enabled: true
    hosts:
      - host: chatwoot.example.com
  postgresql:
    enabled: false
    postgresqlHost: postgres.postgres.svc.cluster.local

Nothing about the values themselves changes - it’s still Chatwoot’s own values.schema.json underneath - only the namespacing, so your chart could in principle depend on more than one thing.

Room for Your Own Resources

This is the part a bare helm install genuinely can’t give you: your chart’s own templates/ directory sits right next to the dependency and contributes to the same release. The NetworkPolicy I wanted for Chatwoot is just another template file, not a manifest applied on the side:

# templates/networkpolicy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: chatwoot-egress
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: postgres
      ports:
        - protocol: TCP
          port: 5432

helm template shows it rendering as one release, not two things pretending to be related:

❯ helm template chatwoot . -f values.yaml | grep -E '^kind:' | sort | uniq -c
   1 ConfigMap
   2 Deployment
   1 NetworkPolicy
   1 Secret
   4 Service
   1 StatefulSet

Conclusion

The upstream chart still takes the same input - same chart, same options, same maintainers. What’s different is where things live: a pinned version in Chart.lock, values in the same shape you’d have passed with -f, and a place for whatever the upstream chart doesn’t cover. For a GitOps setup like mine, that’s the whole point - helm upgrade isn’t a command I run anymore, it’s just what ArgoCD does with the directory every time I push a commit.

I like reading on a Kindle, but I don’t actually own any of those books. They’re DRM’d, tied to one app, and I have no real guarantee I’ll be able to open them again in twenty years if Amazon decides otherwise. For the books I actually want to keep, I’ve been building an EPUB collection for 9 years, and it’s a proper archive by now, sitting in an S3 bucket. What I never solved was the boring part: browsing that archive and getting a book onto an e-reader without SSHing in and copying a file by hand. So I built Bookhoarder , a self-hosted EPUB library.

I wanted this one open source from the start, not as an afterthought. Anyone with a bucket full of EPUBs has the same problem I did, and there was no reason to keep the fix to myself.

Bookhoarder

Launched August 2026

Self-hosted EPUB library backed by object storage, no database.

↗

Object storage instead of a database

Every self-hosted EPUB app I tried expected me to import my books into its own database first. I didn’t want a second copy of nine years of files living inside some app’s storage format, with its own backup and migration story on top of the one I already had for the bucket. Bookhoarder skips that step entirely. The storage driver is pluggable, local disk, S3, or Cloudflare R2, and the bucket itself is the only thing that persists. There’s no database to provision, back up, or migrate between versions, because there isn’t one. Point it at the bucket I’ve been using for years, and the library is already there.

Reading it and getting it to a device

The point of the whole thing is getting a book off the shelf and in front of my eyes, so the rest of Bookhoarder is built around that. There’s an in-browser reader, built on epub.js, for when I just want to read something without touching a device. Metadata and covers come from Open Library, looked up automatically and editable by hand when it gets something wrong. And for the actual e-reader, there are two ways in: send a book over SMTP the same way Kindle’s own send-to-device email works, or point any OPDS-compatible reader app at Bookhoarder’s /opds feed and browse the whole library from the device itself, no email round-trip needed.

Conclusion

I still read plenty of things in Kindle’s own app, that isn’t going away. But the books I actually want to keep now live somewhere I control, in a plain format any reader can open, not locked to whichever app happens to still exist in twenty years. The bucket and the OPDS feed are just plumbing. The point was always owning the file.

When I started at my current job, we were running self-managed, bare-metal Kubernetes clusters on kOps, partway through a migration to EKS. That migration was also our chance to redesign the networking. Under kOps, a handful of clusters shared a VPC, roughly one VPC for every three or four clusters, so around 80 clusters came out to a manageable number of VPCs. For EKS we wanted a tighter boundary: one VPC per cluster, so a cluster’s blast radius stopped at its own network. That gave us the isolation we wanted, and a new problem we hadn’t planned for. Eighty clusters now meant close to eighty VPCs, and VPC peering doesn’t stay manageable at that size.

The mesh problem

VPC peering connections are point to point. There’s no such thing as transitive peering, so if VPC A peers with B and B peers with C, A still can’t reach C unless you peer A and C directly too. That means the number of connections you need grows with the number of pairs of VPCs, not the number of VPCs.

With 4 VPCs that’s 6 peering connections. With 10 VPCs it’s 45. Worse, that growth lands on you one VPC at a time: every new VPC needs its own peering connection to every VPC that’s already there.

Add a fifth VPC to a set of four and that’s four new peering connections, each with its own route table entries on both sides and its own security group rules, not one. Multiply that by eighty clusters and you stop reasoning about the mesh as a diagram at all, you just grep route tables when something can’t connect.

Where Transit Gateway fits

A Transit Gateway is a regional router that VPCs attach to instead of attaching to each other. Each VPC needs exactly one attachment, and traffic between any two VPCs routes through the gateway.

Adding a VPC now means one attachment and one route, not one new connection per existing VPC. The route tables live on the gateway, in one place, instead of scattered across every VPC that needs to reach every other one.

The attachment itself is a small piece of Terraform:

resource "aws_ec2_transit_gateway" "main" {
  description = "Cluster VPC connectivity"
}

resource "aws_ec2_transit_gateway_vpc_attachment" "cluster" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id             = var.vpc_id
  subnet_ids         = var.private_subnet_ids
}

Every cluster VPC gets one of these attachments, and a route pointing at the transit gateway for the CIDR ranges of the other VPCs. That’s the whole change, per VPC, from here on.

The same problem for datastores and Lambdas

Cluster VPCs peering with each other isn’t the only traffic pushing on this. Datastores usually end up isolated into their own VPC too, an RDS instance behind its own subnets and security groups, and every cluster that reads from it needs a path in. A Lambda function calling a service running inside a cluster needs the same kind of path, just from the other direction.

Neither of those is a new cluster added to the mesh, but each one is a new participant, and peering treats it the same way it treats a cluster VPC: one more VPC, one more connection to every VPC it needs to reach. A shared RDS VPC that every one of 80 cluster VPCs reads from picks up all 80 of those connections itself. Its route table and its security groups end up tracking every consumer that was ever added.

Put that RDS VPC on the Transit Gateway instead and it’s one more attachment, same as a cluster. A Lambda VPC is the same story. Reachability now comes down to Transit Gateway route tables , not which VPCs happen to have a peering connection to the datastore: an attachment only gets a route to it if it’s associated with a route table that carries one.

resource "aws_ec2_transit_gateway_route_table" "datastores" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
}

resource "aws_ec2_transit_gateway_route_table_association" "rds" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.rds.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.datastores.id
}

resource "aws_ec2_transit_gateway_route_table_association" "cluster" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.cluster.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.datastores.id
}

Only attachments associated with datastores get a route to the RDS VPC. Everything else on the gateway can still reach the cluster VPCs directly, just not the datastore behind them.

This is also where the Lambda cross-region PrivateLink setup I wrote about earlier stops applying. That one existed because the Lambda needed to cross a region boundary we deliberately don’t route through. A Lambda in the same region calling a cluster service doesn’t need a one-off endpoint at all once its VPC is already an attachment on the gateway everything else uses. It just needs a route, the same as any other consumer.

What Transit Gateway costs

VPC peering connections themselves are free. Data crossing a peering connection is billed like any other cross-AZ traffic, $0.01 per GB, same region, in each direction. Transit Gateway bills differently: $0.05 per attachment per hour, whether or not it’s carrying anything, plus $0.02 per GB processed, twice the peering rate (us-east-1 figures, other regions vary slightly).

Take the 80 cluster VPCs from the redesign, plus the RDS VPC and the Lambda VPC from the last section, moving a combined 20 TB in a month:

VPC peering, full mesh
  cluster to cluster   80 × 79 / 2           = 3,160 connections
  RDS to each cluster  80 × 1                =    80 connections
  Lambda to its cluster                      =     1 connection
  connections total                          = 3,241

  data transfer  20,000 GB × $0.01/GB        = $200/mo

Transit Gateway
  attachments    82 × $0.05 × 24h × 30d      = $2,952/mo
  data transfer  20,000 GB × $0.02/GB        =   $400/mo
  total                                      = $3,352/mo

That extra $3,152 a month buys 82 attachments to one gateway instead of 3,241 pairwise connections nobody could keep straight, the RDS VPC and the Lambda VPC included.

Conclusion

Peering doesn’t fail loudly. Nothing breaks when you add one more VPC past the point where the mesh stopped scaling, you just accumulate more manual route table work than any one person can track correctly. The other cost never shows up on a bill: try explaining a 3,241-connection peering topology to an engineer who joined last week, versus pointing at one gateway and saying everything goes through here. If I were redesigning that networking again knowing we’d end up with eighty VPCs, I’d go straight to a Transit Gateway instead of peering.

Our infra isolates AWS regions on purpose. Nothing in eu-west-1 talks directly to anything in us-east-1, and nothing routes back the other way. It keeps a bad deploy or a bad actor in one region from becoming a problem in both. A team came to me needing exactly the thing that policy exists to prevent: a management app running in eu-west-1 had to call services that only exist in us-east-1. It was a one-time need for one app, not a reason to open the regions up to each other generally, so VPC peering or a Transit Gateway were both off the table. I needed a path that was narrow enough to still call it isolation.

Prerequisites

1. Two AWS regions already set up with their own VPCs, private subnets, and Lambda functions. I’ll call them euw1 and use1 below.
2. Terraform with the AWS provider at 5.83 or newer. Cross-region PrivateLink support landed in that version.
3. Comfort with VPC endpoints, NLBs, and ALBs. I won’t re-explain what those are.

The shape of the fix

AWS PrivateLink lets a VPC endpoint in one region connect to an endpoint service in another, over AWS’s own network, no peering or internet exposure involved. That’s the narrow path: one interface endpoint in euw1, pointed at one endpoint service in use1, carrying traffic for exactly this app and nothing else.

An endpoint service has to sit behind a Network Load Balancer, and an NLB can’t target a Lambda function directly, only instances, IPs, or an ALB. So the US side ends up as a small stack: NLB in front, forwarding to an ALB target group, which is the piece that’s actually allowed to invoke Lambda.

Setting up the US side

Two providers, one per region, since everything below is split across them:

provider "aws" {
  alias  = "use1"
  region = "us-east-1"
}

provider "aws" {
  alias  = "euw1"
  region = "eu-west-1"
}

The NLB, its ALB-type target group, and the endpoint service that sits in front of it:

resource "aws_lb_target_group" "nlb_to_alb" {
  provider    = aws.use1
  name        = "us-services-nlb-tg"
  target_type = "alb"
  port        = 443
  protocol    = "TCP"
  vpc_id      = var.use1_vpc_id
}

resource "aws_lb_target_group_attachment" "nlb_to_alb" {
  provider          = aws.use1
  target_group_arn  = aws_lb_target_group.nlb_to_alb.arn
  target_id         = aws_lb.us_internal_alb.arn
  port              = 443
}

resource "aws_lb" "us_nlb" {
  provider           = aws.use1
  name               = "us-services-nlb"
  internal           = true
  load_balancer_type = "network"
  subnets            = var.use1_private_subnet_ids
}

resource "aws_vpc_endpoint_service" "us_services" {
  provider                   = aws.use1
  acceptance_required        = true
  network_load_balancer_arns = [aws_lb.us_nlb.arn]
  supported_regions          = ["eu-west-1"]
}

us_internal_alb is the ALB with a lambda-type target group in front of the US Lambda. I’m leaving that part out since it’s just the standard ALB-to-Lambda setup, nothing specific to the region-crossing part.

Setting up the EU side

The interface endpoint is the only new thing on this side, and it needs service_region set to tell it the service lives elsewhere:

resource "aws_security_group" "us_services_endpoint" {
  provider = aws.euw1
  name     = "us-services-endpoint-sg"
  vpc_id   = var.euw1_vpc_id

  ingress {
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = [aws_security_group.euw1_lambda.id]
  }
}

resource "aws_vpc_endpoint" "us_services" {
  provider            = aws.euw1
  vpc_id              = var.euw1_vpc_id
  service_name        = aws_vpc_endpoint_service.us_services.service_name
  service_region      = "us-east-1"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = var.euw1_private_subnet_ids
  security_group_ids  = [aws_security_group.us_services_endpoint.id]
  private_dns_enabled = false
}

I left private_dns_enabled off. Private DNS on a cross-region endpoint means resolving the target service’s own domain name to the local endpoint, and I didn’t want to lean on that working the same as it does in-region. The EU Lambda calls the endpoint’s own generated DNS name directly instead, which is one extra environment variable, not a real cost.

The endpoint connection needs to be accepted on the use1 side before traffic flows, because acceptance_required is true above:

❯ aws ec2 describe-vpc-endpoint-connections --region us-east-1 \
  --filters Name=vpc-endpoint-state,Values=pendingAcceptance
{
    "VpcEndpointConnections": [
        {
            "ServiceId": "vpce-svc-0a1b2c3d4e5f6a7b8",
            "VpcEndpointId": "vpce-0f1e2d3c4b5a69788",
            "VpcEndpointOwner": "123456789012",
            "VpcEndpointState": "pendingAcceptance"
        }
    ]
}

❯ aws ec2 accept-vpc-endpoint-connections --region us-east-1 \
  --service-id vpce-svc-0a1b2c3d4e5f6a7b8 \
  --vpc-endpoint-ids vpce-0f1e2d3c4b5a69788

Same account on both ends here, so I did that by hand once. A recurring setup would script it or add the accepter as its own Terraform resource.

Conclusion

The stack is more layers than I’d like for one app calling another region, NLB, ALB, endpoint service, interface endpoint, but each layer is there because something upstream of it can’t do the next hop itself. It stays a narrow, named exception instead of a general path between regions, which was the actual requirement. If this app ever turns into “several apps need this,” I’d stop reaching for one-off endpoints and go read up on Transit Gateway properly instead.

My team used to run sprint planning with a couple of the existing planning poker tools out there. None of them were bad, exactly, they were just built for someone else’s team: too many settings we didn’t need, too few of the ones we did. At some point that turns into an itch, and I built Scrummy to scratch it, a free planning poker room with no accounts and no setup, tuned to how my own team actually plays. The code is open source, if you want more than the snippets below.

Scrummy

Launched September 2022

Scrum sizing game for remote teams.

↗

The first version worked. It also ran on more infrastructure than a “type in a URL, vote on a card, see the average” app should need.

The first version was overkill

Scrummy started as a Laravel app with a Postgres database, real user accounts, and teams you’d invite people to, plus a separate Redis-backed websocket server pushing votes around a room in real time. I’d built it as sign-up-and-invite software, then realized nobody wants to create an account just to vote on a story point with their team. So I dropped the whole auth and teams layer: no accounts, just a nickname and a room link, and anyone who has the link can join.

That decision made the rest obvious. If nothing needs to persist past a room’s lifetime, the app doesn’t need a traditional server-plus-database stack running underneath it either.

One Durable Object per room

The rebuild replaced all of it with Cloudflare Workers and a single Durable Object per room.

If you haven’t used one before, picture a Durable Object as a single storage bucket that lives in one specific place on Cloudflare’s network, not copied across every point of presence (PoP) the way a normal Worker request is. A regular Worker runs wherever the request happens to land, closest to whoever’s asking, and remembers nothing between requests. A Durable Object is the opposite: you give it an ID, and every request for that ID gets routed to that same one instance, wherever it actually lives, so it can hold state in memory and handle requests one at a time instead of two copies of itself stepping on each other.

For Scrummy, that ID is the room’s slug. A Worker routes an incoming WebSocket request to the Durable Object for that slug:

const id = env.ROOM.idFromName(slug);
const stub = env.ROOM.get(id);
return stub.fetch(request);

idFromName derives that ID from the slug itself, so the routing needs no lookup table of its own; the same slug always maps to the same object. There’s no separate process to keep alive between rooms, and no shared database row two rooms could collide on. Each room is its own small, isolated unit of state.

Wiring it up is a few lines in wrangler.jsonc:

"durable_objects": {
  "bindings": [{ "name": "ROOM", "class_name": "Room" }]
},
"migrations": [{ "tag": "v1", "new_sqlite_classes": ["Room"] }]

Websockets that don’t cost anything while idle

The part that replaced the Redis server is the WebSocket Hibernation API . A Durable Object can accept a WebSocket connection and then hibernate between messages, holding no memory or compute open, and wake back up when one arrives:

async fetch(request: Request): Promise<Response> {
  const pair = new WebSocketPair();
  const [client, server] = Object.values(pair);
  this.ctx.acceptWebSocket(server);
  return new Response(null, { status: 101, webSocket: client });
}

State that needs to survive hibernation goes into the Durable Object’s own SQLite storage, and each socket carries its user’s identity with ws.serializeAttachment, so a room that wakes back up after sitting idle for a day still knows who’s who without a database lookup. A 30-day alarm handles cleanup: if nobody’s visited a room in a month, the object deletes its own storage and disappears.

The full Room object, including how it handles joins, votes, and a short reconnect grace period for someone who just refreshed the page, is in worker/room.ts on GitHub.

Why not just a database

A database would work here too, it’s just the wrong tool for this. The thing Scrummy needs on every vote is simple: tell everyone else in the room. The old stack meant a separate Node process fanning out socket events, with Redis and Postgres nearby for everything else. With a Durable Object, the Worker already holds every open socket for that room in memory, so broadcasting a vote is a loop over connections it already has, not a hop through another service:

private async broadcast(message: ServerMessage): Promise<void> {
  const payload = JSON.stringify(message);
  for (const ws of this.ctx.getWebSockets()) {
    if (ws.readyState === WebSocket.OPEN) ws.send(payload);
  }
}

Storage only comes into it to survive hibernation, a restart, or the Durable Object migrating between machines. Coordinating the people in the room doesn’t touch it at all.

Conclusion

I wouldn’t reach for a Durable Object for most of what Redis is good at. But for state scoped to a small group of people, that lives for a few days and needs to reach everyone watching the instant it changes, one object per room turned out to be a better match than a server and a database ever were, and it’s one less thing I have to keep running.

Try it yourself at scrummy.dev . If something’s missing or you’d build a piece of it differently, open an issue or a PR on GitHub .

Between the Terraform-managed VM and backups landing on the NAS , the Portainer container is solid, but everything on it is LAN-only. To check on it, or hit an app running behind it, I have to be home. This post gets remote access working without opening anything to the public internet - Tailscale instead.

Why Tailscale Here, Not a Public Tunnel

I already wrote about exposing a service through a Cloudflare Tunnel gated by Zero Trust identity . That’s the right tool when something needs to be reachable by anyone with the right login. This isn’t that - it’s just me, wanting to reach my own homelab from my own devices. Tailscale builds a private mesh network (WireGuard under the hood) between devices I’ve enrolled (registering a machine to Tailnet) myself; nothing gets a public hostname or a public IP at all, so there’s no login screen to gate because there’s no public entry point to gate in the first place.

Prerequisites

1. The Proxmox VM and Portainer setup from the first post .
2. A Tailscale account and tailnet.
3. A reusable Tailscale auth key (Settings > Keys > Generate auth key, tick “Reusable” - a plain key from a logged-in session, not an OAuth-client key, which Tailscale requires to be tagged).

What tsdproxy Does

tsdproxy watches the Docker socket and, for containers with the right labels, registers each one as its own node on the tailnet with its own hostname - opt-in per container, rather than one subnet router exposing the whole LAN at once. That fits Portainer well: I add a label to whatever stack I want reachable, and nothing else on the box is affected.

The tsdproxy Stack

I added this the same way as everything else in this series: another entry in services, deployed as its own portainer_stack by Terraform, not clicked together in the Portainer UI. Rather than paste the compose file here and let it drift from what I actually run, the real one lives in the repo from the first post : templates/tsdproxy.yaml.tftpl . The parts worth calling out:

• TSDPROXY_AUTHKEY only seeds /config/tsdproxy.yaml on tsdproxy’s first boot - later restarts read the config file it already wrote, not the env var again.
• tsdproxy isn’t on the same Docker network as the containers it proxies (every Portainer stack gets its own default network), so it reaches them over host.docker.internal at whatever host port they’ve published - extra_hosts: host.docker.internal:host-gateway is what makes that resolve. This is tsdproxy’s documented pattern for exactly this situation - two containers in separate Compose stacks.

Wiring it in is one services entry in terraform.tfvars:

services = [
  # ... the whoami stack from the first post ...
  {
    name         = "tsdproxy"
    compose_file = "tsdproxy.yaml.tftpl"
    env = {
      TS_AUTHKEY = "<your reusable Tailscale auth key>"
    }
  },
]

❯ terraform apply
...
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Labeling the Dummy App

tsdproxy discovers containers the same way Traefik does - two labels on the container itself, not a separate config file per app:

labels:
  tsdproxy.enable: "true"
  tsdproxy.name: "whoami"

I added those to the same whoami stack from the first post - see the current version in templates/whoami.yaml.tftpl . tsdproxy.enable is what gets it picked up at all; tsdproxy.name sets the hostname it shows up under on the tailnet - drop it and tsdproxy falls back to the container name. The full label reference (multi-port apps, TCP/UDP proxying, health checks) is in tsdproxy’s docs if you need more than the two labels here.

Reaching It From a Tailnet Device

Once the stack redeployed with that label, whoami shows up as its own machine in the Tailscale admin console, with its own *.ts.net hostname and a Tailscale-issued HTTPS certificate for it:

❯ curl -s https://whoami.my-tailnet.ts.net
Hostname: a1b2c3d4e5f6
IP: 172.18.0.2

Ran from my laptop, off the home LAN entirely, over the tailnet.

Conclusion

The Cloudflare Zero Trust post needed an actual identity policy - an Okta group, a session duration, a decision about who gets in. This one skips that entirely: nothing is reachable at all unless the requesting device is already enrolled in my tailnet, so there’s no access policy to configure or get wrong. A VM built by Terraform, Portainer running stacks on it declaratively, backups landing on the NAS on a schedule, and now remote access without a single port opened on my router.

The previous post got me a Terraform-managed VM running Docker and Portainer. Great, except it exists in exactly one place: the local disk of one Proxmox host. If that disk dies, the VM, Portainer, and every stack in it go with it. This post is getting backups off that box and onto a NAS I already have on the LAN.

Prerequisites

1. The Proxmox host from the previous post .
2. A NAS on the same LAN that can export an NFS share.

Creating the NFS Share on the NAS

On the NAS, I created a shared folder for this specifically - /volume1/proxmox-backup - and exported it over NFS restricted to the Proxmox host’s IP only, 192.168.1.70/32, not the whole LAN. Same principle as restricting NetworkPolicy egress on the Talos cluster: nothing else on the network has a reason to write into this share, so nothing else gets a route to it.

Adding the NAS as Proxmox Storage

Datacenter > Storage > Add > NFS in the Proxmox UI, pointed at the export, with content type set to “VZDump backup file” (not disk images - this share is backups only). That writes an entry into /etc/pve/storage.cfg:

nfs: nas-backup
    export /volume1/proxmox-backup
    path /mnt/pve/nas-backup
    server 192.168.1.30
    content backup
    prune-backups keep-last=7

prune-backups keep-last=7 caps it at the last 7 backups per guest - Proxmox deletes older ones itself on each new backup, so the NAS share doesn’t grow unbounded.

Scheduling Backups

Datacenter > Backup > Add: target the portainer VM, storage nas-backup, mode snapshot (backs up a running VM without stopping it, using a live snapshot), compression zstd, schedule 02:00 daily. Mode matters here specifically because this VM is meant to stay up - stop or suspend mode would take Portainer and everything behind it down for the duration of every backup.

Running One Manually

Didn’t want to wait until 2am to find out if this actually works:

❯ vzdump 100 --storage nas-backup --mode snapshot --compress zstd
INFO: starting new backup job: vzdump 100 --storage nas-backup --mode snapshot --compress zstd
INFO: Starting Backup of VM 100 (qemu)
INFO: status = running
INFO: backup mode: snapshot
INFO: creating vzdump archive '/mnt/pve/nas-backup/dump/vzdump-qemu-100-2025_11_14-02_03_11.vma.zst'
INFO: Finished Backup of VM 100 (00:01:47)
INFO: Backup job finished successfully

And confirmed the file actually landed on the NAS, not just in Proxmox’s view of the mount:

❯ ssh nas 'ls -la /volume1/proxmox-backup/dump/'
-rw-r--r-- 1 root root 3812048291 Nov 14 02:05 vzdump-qemu-100-2025_11_14-02_03_11.vma.zst

Conclusion

The VM now has off-box backups on a schedule, capped at 7 generations, and I’ve confirmed manually that a backup actually reaches the NAS rather than trusting the UI’s green checkmark. It’s still all on the same LAN, though - if I want to check on Portainer, or hit an app running behind it, from anywhere other than my home network, none of that is reachable yet. Next post : exposing it over Tailscale.

Alongside the Talos Kubernetes cluster I’ve written about, I picked up another mini PC and wanted a general-purpose machine for the stuff that doesn’t need Kubernetes at all - Pi-hole, Home Assistant, that kind of thing. Spinning up pods for every small self-hosted app felt like the wrong tool. Proxmox VE gives me VMs and LXC containers directly on the hardware instead, and I wanted the VM creation itself to be Terraform, not a manual install wizard. This post is that: Proxmox installed, one VM created by Terraform, Docker and Portainer on it, and a dummy container deployed into Portainer the same declarative way.

Prerequisites

1. A machine to install Proxmox VE on - I used a mini used Lenovo Tiny.
2. Terraform .
3. The bpg/proxmox and portainer/portainer Terraform providers (declared in code below, nothing to install by hand).

Installing Proxmox

Flashed the Proxmox VE ISO to a USB stick, installed it on the mini PC, and got the web UI at https://192.168.1.70:8006. One thing Terraform genuinely cannot do for you: create its own API credentials. Before anything else, I created a token under Datacenter > Permissions > API Tokens - Terraform authenticates with that token, it can’t bootstrap it.

Creating the VM with Terraform

Instead of another manual ISO install for the VM itself, I import a Debian cloud image and let cloud-init configure it - faster, and it’s the only way this stays fully declarative:

module "portainer_vm" {
  source = "./modules/vm"

  node_name   = var.proxmox_node_name
  name        = "portainer"
  description = "Docker + Portainer host - managed by Terraform"
  tags        = ["terraform", "portainer"]

  cores     = 4
  memory_mb = 8192

  disk_datastore_id = var.vm_disk_datastore_id
  disk_size_gb      = 40

  image_url          = "https://cloud.debian.org/images/cloud/trixie/latest/debian-13-generic-amd64.qcow2"
  image_datastore_id = "local"

  bridge       = "vmbr0"
  ipv4_address = "${var.portainer_vm_ip}/24"
  ipv4_gateway = var.lan_gateway

  username        = "debian"
  ssh_public_keys = [trimspace(file(pathexpand(var.ssh_public_key_path)))]
  ssh_private_key = file(pathexpand(var.ssh_private_key_path))

  provision_commands = [
    templatefile("${path.module}/templates/portainer-bootstrap.sh.tftpl", {
      admin_password = var.portainer_admin_password
    }),
  ]
}

provision_commands runs over SSH once the VM is up: install Docker, run Portainer, wait for its API to answer. One real bug from getting this working - the bootstrap script must not exit 0 on success. When you concatenate more than one script into provision_commands, an early exit on the first one silently skips everything after it.

❯ terraform apply -target=module.portainer_vm
...
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

❯ terraform output portainer_vm_ip
"192.168.1.110"

That -target is required on a from-scratch apply, not optional: the portainer provider block authenticates against the VM’s IP immediately, before any resource exists, so a plain apply on an empty state fails before it gets anywhere near creating the VM that IP belongs to.

A Dummy Container, Deployed Declaratively

The issue I wrote for myself said “use Portainer to create a dummy container,” which is normally a few clicks - Stacks > Add stack, paste a compose file, deploy. Since the VM itself is already Terraform, I deployed the stack the same way instead, through the portainer provider:

resource "portainer_stack" "this" {
  name            = var.name
  deployment_type = "standalone"
  method          = "string"
  endpoint_id     = var.endpoint_id
  stack_file_content = var.compose_content
  prune = true
}

pointed at a genuinely throwaway service:

name: whoami

services:
  whoami:
    container_name: whoami
    image: traefik/whoami:latest
    ports:
      - "8081:80"
    restart: unless-stopped

❯ terraform apply
...
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

❯ curl -s http://192.168.1.110:8081 | head -3
Hostname: a1b2c3d4e5f6
IP: 127.0.0.1
IP: 172.18.0.2

The full setup - the VM module, the Portainer stack module, this compose file - is in omegion/proxmox-portainer-example on GitHub, sanitized of anything specific to my own network.

Conclusion

One VM, created by Terraform, running Docker and Portainer, with a stack deployed into it the same declarative way - no manual clicking anywhere in this loop. It only exists on the LAN right now and there’s nothing backing it up. Next post : getting it backed up to a NAS.

When I was building my Talos Kubernetes homelab cluster, I wrote about setting it up and turning on Flannel’s native NetworkPolicy enforcement along the way, with one generic example: allow HTTPS out, block the home LAN. That was a decent first pass, but it didn’t say anything about what a specific app actually needs. Without a policy, every pod on that cluster still gets Kubernetes’ default “allow all egress”. A pod can reach anything else in the cluster, or anything on my LAN, just as easily as the one service it’s actually supposed to talk to. This post is the real version of that lock, for one real app: Chatwoot , which needs the cluster’s shared Postgres and its own Redis, and nothing else.

Prerequisites

1. A Talos cluster with Flannel’s policy enforcement turned on. I covered that when I first built this cluster, in the post about setting it up .
2. An app already running that you want to lock down (Chatwoot, in this example).
3. kubectl pointed at the cluster.

What Chatwoot actually talks to

Chatwoot’s web and worker pods need three things to work: the shared CloudNativePG cluster in the postgres namespace, a Redis instance in Chatwoot’s own namespace for the Sidekiq/Bull job queue and cache, and DNS to resolve both of those. It also needs outbound SMTP and HTTPS for email and a couple of third-party integrations. Everything else, the rest of the cluster, my home LAN, the internet at large, is stuff it has no reason to reach.

The egress policy

podSelector: {} matches every pod in the namespace, so the mere presence of this NetworkPolicy flips Chatwoot from “allow all egress” to “deny anything not explicitly listed below”:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: chatwoot-egress
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    # DNS
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    # Shared CNPG postgres cluster
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: postgres
      ports:
        - protocol: TCP
          port: 5432
    # Own redis (Bull/Sidekiq queue + cache), same namespace
    - to:
        - podSelector:
            matchLabels:
              app.kubernetes.io/name: chatwoot-redis
              app.kubernetes.io/component: master
      ports:
        - protocol: TCP
          port: 6379
    # SMTP relay + HTTPS (S3 storage, Slack/Google OAuth). No stable
    # IP/CIDR published for either, so scoped by port only.
    # Still excludes the LAN, just not a specific host.
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 192.168.1.0/24
      ports:
        - protocol: TCP
          port: 587
        - protocol: TCP
          port: 443

No rule for the Kubernetes API, on purpose. Chatwoot doesn’t call it, so there’s nothing to allow there.

The DNS rule has to match the pod, not the ClusterIP

That first rule looks like it should just be an ipBlock for CoreDNS’s ClusterIP. I wrote it that way the first time, on a different app on this same cluster, and it broke DNS completely. Flannel’s policy engine evaluates after kube-proxy has already rewritten the destination to CoreDNS’s real pod IP, so a rule matching the virtual ClusterIP never actually matches anything. Matching CoreDNS by namespaceSelector + podSelector instead, by pod identity rather than by the Service address, is what actually works. I pulled this into a small shared Helm chart (network-policy-snippets) so every app’s egress policy includes the same correct DNS rule instead of each one risking that mistake on its own.

Testing it

To check the policy is actually doing what I think it’s doing, I dropped a netshoot pod into the chatwoot namespace and tried reaching both an allowed destination and a denied one:

❯ kubectl run chatwoot-netpol-demo -n chatwoot --image=nicolaka/netshoot:latest \
  --restart=Never --command -- sleep 3600
pod/chatwoot-netpol-demo created

Postgres and Redis, both explicitly allowed, connect straight away:

❯ kubectl exec -n chatwoot chatwoot-netpol-demo -- \
  nc -zv -w3 postgres.postgres.svc.cluster.local 5432
Connection to postgres.postgres.svc.cluster.local (10.107.254.52) 5432 port [tcp/postgresql] succeeded!

❯ kubectl exec -n chatwoot chatwoot-netpol-demo -- \
  nc -zv -w3 chatwoot-chatwoot-redis-master 6379
Connection to chatwoot-chatwoot-redis-master (10.104.168.82) 6379 port [tcp/redis] succeeded!

The kube-apiserver, which isn’t in the policy at all, just hangs until the connection times out:

❯ kubectl exec -n chatwoot chatwoot-netpol-demo -- nc -zv -w5 192.168.1.10 6443
nc: connect to 192.168.1.10 port 6443 (tcp) timed out: Operation in progress
command terminated with exit code 1

That’s the difference between a policy that exists and a policy that’s actually enforced. I deleted the pod once I’d seen both results.

Conclusion

It’s still not real network isolation, though. Enforcement happens in Flannel, on the same node the pod runs on, not on a VLAN or a separate firewall device sitting between the cluster and the rest of the LAN. A CNI bug or a misconfigured node bypasses it entirely. What it does catch is the boring failure, an app reaching somewhere it has no business reaching, and that’s the case that actually happens on a homelab. Anywhere the stakes were higher, physical or VLAN segmentation would still be the real fix, not a NetworkPolicy.

Usertune served personalized content in real time based on user location, device, behavior, and custom attributes, over a REST API, JS SDK, or GraphQL endpoint, with webhooks for event-driven cases. Content was delivered from the edge to keep latency down, and the dashboard covered the basics: conversion rates, engagement, and A/B testing content variants.

In the previous post I got an app on my Talos cluster reachable from the internet through cloudflared. That was also the problem it left behind: anyone with the URL could hit it, no login, nothing. Before I put anything real behind a tunnel, it needs to actually require someone to be who they say they are. That’s Cloudflare Access, and this post is wiring it up.

Why Zero Trust Instead of Auth in the App

The easy option would be adding a login page to the app itself. Cloudflare Access does the check in front of the tunnel instead, before the request ever reaches the cluster - the app doesn’t need to know anything about authentication at all. The “zero trust” part is the model behind it: access is decided by who you are, not by whether you’re on my LAN or a VPN. Nothing gets a pass just because of where the request came from.

Choosing an Identity Provider

Cloudflare Access supports a handful of identity providers - Google, GitHub, one-time PIN over email, generic OIDC/SAML. I picked Okta: simpler to wire up as a single IdP than standing up something else just for a one-person homelab, and it’s the one I’m managing the policy against for every app that needs it.

Terraform: The Access Application

Each protected hostname gets a cloudflare_access_application plus a policy that only lets a specific Okta group through:

resource "cloudflare_access_application" "this" {
  zone_id                   = data.cloudflare_zones.this.zones[0].id
  name                      = var.hostname
  domain                    = "${var.hostname}.${var.domain}"
  allowed_idps              = [data.cloudflare_access_identity_provider.okta.id]
  type                      = "self_hosted"
  session_duration          = "730h"   # ~30 days
  auto_redirect_to_identity = true
}

resource "cloudflare_access_policy" "this" {
  application_id = cloudflare_access_application.this.id
  zone_id        = data.cloudflare_zones.this.zones[0].id
  name           = "Okta Groups"
  precedence     = "1"
  decision       = "allow"

  include {
    okta {
      name                 = var.okta_groups
      identity_provider_id = data.cloudflare_access_identity_provider.okta.id
    }
  }
}

auto_redirect_to_identity skips Cloudflare’s own IdP picker and sends visitors straight to Okta. session_duration controls how long that login sticks before Access makes them go through Okta again - long enough that I don’t re-authenticate on every visit, short enough that it isn’t effectively permanent.

❯ terraform apply
...
  # cloudflare_access_application.this will be created
  # cloudflare_access_policy.this will be created
Plan: 2 to add, 0 to change, 0 to destroy.

cloudflare_access_application.this: Creating...
cloudflare_access_policy.this: Creating...
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

That’s what shows up in the dashboard afterward - the Destinations tab on one of my actual protected apps (not nginx-demo, but the same shape: one public hostname per application):

And the Access policy it creates - on this app the policy happens to be named “Okta Admin” rather than “Okta Groups”, but it’s the same default-deny-plus-an-Okta-group pattern from the Terraform above:

Hitting nginx.example.com in a browser now bounces through Okta before it ever reaches nginx, and only members of the group in okta_groups get past the login.

What About Scripts and curl?

An Okta redirect is fine for a browser, useless for anything scripted - curl can’t click through a login page. Cloudflare Access covers that with service tokens: a separate policy, opt-in per application, that doesn’t touch Okta at all:

resource "cloudflare_access_policy" "service_token" {
  count = var.enable_service_token ? 1 : 0

  application_id = cloudflare_access_application.this.id
  zone_id        = data.cloudflare_zones.this.zones[0].id
  name           = "Service Token"
  precedence     = "3"
  decision       = "non_identity"

  include {
    any_valid_service_token = true
  }
}

With that policy in place, a request carrying a valid service token’s client ID and secret gets through without ever seeing the Okta redirect:

❯ curl -H "CF-Access-Client-Id: <client-id>.access" \
  -H "CF-Access-Client-Secret: <client-secret>" \
  https://nginx.example.com

It’s a separate credential from anyone’s Okta login, so I mint one per script or automation that needs in, and it can be revoked on its own without touching anyone’s actual account.

Conclusion

The cluster from the first post, storage from the second, a database in the third, and now anything exposed through the fourth post’s tunnel requires either an Okta login or a service token to reach it at all - no more anonymous public access to anything sitting behind Cloudflare on this homelab. Four posts to get here, and the three mini PCs that used to just sit on my desk now run a cluster where nothing gets in without proving who it is.

Between the cluster , the storage , and Postgres , I’ve got a real place to run apps now. All of that is still only reachable from inside my LAN, though. This post is getting a service out to the internet without opening a port on my home router or publishing my home IP anywhere - cloudflared running as an ingress controller inside the cluster.

Why a Tunnel Instead of Port Forwarding

cloudflared makes an outbound connection from inside the cluster out to Cloudflare’s edge and keeps it open. Traffic comes in over that connection, not through an inbound port on my router. There’s nothing to forward, no firewall rule pointing at my home IP, and no home IP exposed in DNS at all - every request goes through Cloudflare’s edge first.

Routing everything through that edge also means bot protection, WAF rules, and rate limiting are available on the same traffic, configured in Cloudflare rather than in the app or on the tunnel itself - nginx here doesn’t have to know any of that exists. I haven’t turned any of it on yet for this dummy app, but it’s sitting there for when something behind this tunnel actually needs it.

Prerequisites

1. The Talos cluster from the first post and the ceph-rbd storage class from the second post .
2. A domain onboarded to a Cloudflare account .
3. Helm 3 .
4. A Cloudflare API token scoped to manage Tunnels .
5. The cloudflare-tunnel-ingress-controller Helm chart.

Installing the Tunnel Ingress Controller

I run the cloudflare-tunnel-ingress-controller chart, which both manages the cloudflared pods and watches Kubernetes Ingress objects to create the matching tunnel routes and DNS records automatically:

cloudflare-tunnel-ingress-controller:
  cloudflare:
    accountId: "<account-id>"
    tunnelName: "homelab-ingress"
    apiToken: "<api-token>"

  cloudflared:
    replicaCount: 2
    podAntiAffinity: true
    resources:
      requests:
        cpu: 50m
        memory: 64Mi
      limits:
        cpu: 250m
        memory: 256Mi
    pdb:
      enabled: true
      minAvailable: 1

❯ helm install cloudflare-ingress cloudflare/cloudflare-tunnel-ingress-controller \
  -n cloudflare-ingress --create-namespace -f values.yaml

I didn’t start with the replicaCount, podAntiAffinity, and resources block above - the chart defaults to a single replica with no resource limits at all, which meant every app behind the tunnel went down with that one pod. I also caught it stuck on a stale image build: cloudflared warns “outdated” on every startup, and left on latest with IfNotPresent it just never re-pulls once a pod already exists. Pinning the tag and running two replicas spread across nodes with a PodDisruptionBudget fixed both.

Pointing an App at It

Any Ingress with ingressClassName: cloudflare-tunnel gets picked up by the controller automatically - no manual cloudflared tunnel route dns step. To prove it works, a dummy nginx deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-demo
spec:
  selector:
    app: nginx-demo
  ports:
    - port: 80
      targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-demo
spec:
  ingressClassName: cloudflare-tunnel
  rules:
    - host: nginx.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-demo
                port:
                  number: 80

❯ kubectl apply -f nginx-demo.yaml
❯ curl -sI https://nginx.example.com
HTTP/2 200
server: cloudflare
content-type: text/html

That request went from my laptop, out to Cloudflare, back down through the tunnel, into the cluster, and hit nginx - without touching my router at all:

Conclusion

The app is reachable from the internet now, which is the point, but also the problem: right now anyone with the URL can hit it, nginx welcome page and all. Next post : putting Cloudflare Zero Trust in front of this so it actually requires a login.

How to Host a Personal Blog with Hugo on GitHub Pages walked through getting a Hugo site onto GitHub Pages, a GitHub Actions workflow that builds the site and lets GitHub serve the result for free. Cloudflare Pages does the same job, hosting a folder of static files, but the path to get there is different. Instead of a Git-connected build, you push an already-built directory straight up with Wrangler , Cloudflare’s CLI, from your own CI. Same Hugo site, same public/ output, a different way of shipping it.

Prerequisites

1. Hugo Extended , 0.146.0 or newer.
2. Node.js and npm, to run Wrangler.
3. A Cloudflare account.
4. A Hugo site. If you don’t have one yet, check the previous post for that from an empty folder. A GitHub repo for it only matters later, for the GitHub Actions section.

Create a Cloudflare Pages project

Cloudflare Pages has two ways to get a site onto it: connect a Git repo and let Cloudflare run the build, or direct upload a folder you already built yourself. This post uses direct upload, since the build already happens in GitHub Actions and there’s no reason to run it a second time on Cloudflare’s side. A direct upload project can’t be switched to Git integration later, so decide up front if you might want Cloudflare running the build too.

Log in and create the project with Wrangler:

npx wrangler login
npx wrangler pages project create

It asks for a project name and a production branch, then the project exists and is served at <PROJECT_NAME>.pages.dev until you attach a custom domain.

Deploy the build by hand

Build the site the same way as before:

hugo --gc --minify

Then push the public/ directory up with Wrangler:

npx wrangler pages deploy public --project-name=<PROJECT_NAME>

That’s a full deploy on its own, useful the first time to make sure the project and the build output line up before wiring up CI.

Automate the deploy with GitHub Actions

Deploying from a laptop works, but the point of the GitHub Pages post was never touching the deploy step by hand again. Wrangler needs two values to run from CI: an API token and the account ID, both from the Cloudflare dashboard’s API Tokens page and Account Home overview respectively. Add them as repository secrets, CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID, under Settings > Secrets and variables > Actions.

The workflow reuses the Hugo install step from the GitHub Pages post, then hands the build off to cloudflare/wrangler-action instead of actions/deploy-pages:

# .github/workflows/deploy-cloudflare.yaml
name: Deploy Hugo site to Cloudflare Pages

on:
  push:
    branches:
      - master
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    env:
      HUGO_VERSION: 0.165.0
    steps:
      - name: Install Hugo CLI
        run: |
          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb
          sudo dpkg -i ${{ runner.temp }}/hugo.deb
      - name: Checkout
        uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - name: Build with Hugo
        env:
          HUGO_ENVIRONMENT: production
          HUGO_ENV: production
        run: |
          hugo --gc --minify
      - name: Deploy to Cloudflare Pages
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy public --project-name=<PROJECT_NAME>
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}

One difference from the GitHub Pages workflow: there’s no --baseURL override on the build step. actions/configure-pages needed that because GitHub can serve a project from a subpath. Cloudflare Pages always serves from the domain root, so whatever baseURL is already set in hugo.toml is correct as is.

Push, and the Actions tab shows the same build-then-deploy shape as the GitHub Pages workflow, just handing the finished files to Wrangler instead of actions/deploy-pages.

Conclusion

Direct upload is the whole difference here: GitHub Pages ties the build to its own Pages integration, Cloudflare Pages with direct upload doesn’t care where public/ came from, only that it’s a folder of files and a Wrangler command pointed at it. Same Hugo site, same GitHub Actions trigger, just a different platform on the receiving end.

Between this post and the previous one , that’s a Hugo site deployed for free both ways, GitHub Pages and Cloudflare Pages. Pick whichever one the rest of your stack already leans on.

I run EKS clusters and edge infrastructure for a living, and I still don’t want to run or pay for any of it on my own time. That’s a rule I keep for side projects: no self-hosting, no Kubernetes, no Cloudflare Workers, nothing with a bill attached. When I started this blog in 2020 that rule meant two decisions: what to write it in, and where to put it. I landed on Hugo and GitHub Pages, and this post is the whole path from an empty folder to a live site, the same setup omegion.dev runs on today.

Prerequisites

1. Hugo Extended , 0.146.0 or newer. On macOS: brew install hugo.
2. Git.
3. A GitHub account, and an empty repository created there to push this site into.

What is Hugo

Hugo is a static site generator written in Go. You write content in Markdown, Hugo runs it through a set of templates, and the output is plain HTML files, nothing server-side, no database, no request-time rendering. It ships as a single binary, no Node toolchain, no Ruby, nothing to install beyond the binary itself. I’m a Go person, so that was an easy sell on its own, but the part that actually matters for “no infrastructure” is the output: a folder of HTML files is the cheapest possible thing to host, because it doesn’t need a running process at all.

Create a new site

❯ hugo new site myblog
Congratulations! Your new Hugo project was created in /Users/hakan/myblog.

Just a few more steps...

1. Change the current directory to /Users/hakan/myblog.
2. Create or install a theme:
   - Create a new theme with the command "hugo new theme <THEMENAME>"
   - Or, install a theme from https://themes.gohugo.io/
3. Edit hugo.toml, setting the "theme" property to the theme name.
4. Create new content with the command "hugo new content <SECTIONNAME>/<FILENAME>.<FORMAT>".
5. Start the embedded web server with the command "hugo server --buildDrafts".

See documentation at https://gohugo.io/.

That scaffolds content/, layouts/, static/, archetypes/, and a hugo.toml with just a baseURL, title, and locale. cd myblog and turn it into a git repo:

git init
git add .
git commit -m "Initial commit"

Write your first post

hugo new content uses the default archetype to stamp out a new page with frontmatter already filled in:

❯ hugo new content posts/hello-world.md
Content "/Users/hakan/myblog/content/posts/hello-world.md" created

+++
date = '2026-08-27T08:56:30+02:00'
draft = true
title = 'Hello World'
+++

Add a line or two of body text under that frontmatter, and flip draft to false once you actually want it live, Hugo skips draft content by default outside of local preview.

Build it locally

hugo server --buildDrafts runs a local dev server with live reload:

❯ hugo server --buildDrafts
Watching for changes in /Users/hakan/myblog/{archetypes,assets,content,data,i18n,layouts,static}
Watching for config changes in /Users/hakan/myblog/hugo.toml
Start building sites …

WARN  found no layout file for "html" for kind "home": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN  found no layout file for "html" for kind "page": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.

                  │ EN
──────────────────┼────
 Pages            │  5

Web Server is available at http://localhost:1313/
Press Ctrl+C to stop

Those WARN lines are expected right now. A freshly scaffolded site has no theme, so there’s nothing telling Hugo how to turn a post into a page. It’ll build, the server will start, and the browser tab will be blank. That gets fixed in the last section, once the deploy pipeline is in place.

For a real build instead of the dev server:

❯ hugo --gc --minify

That writes the finished site to public/, the same directory the deploy workflow below picks up and publishes.

Deploy it to GitHub Pages with GitHub Actions

Push the repo to GitHub, then add a workflow that builds the site and deploys it on every push, this is the exact file I run for this blog:

# .github/workflows/deploy.yaml
name: Deploy Hugo site to Pages

on:
  push:
    branches:
      - master
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: "pages"
  cancel-in-progress: false

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      HUGO_VERSION: 0.165.0
    steps:
      - name: Install Hugo CLI
        run: |
          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb
          sudo dpkg -i ${{ runner.temp }}/hugo.deb
      - name: Checkout
        uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - name: Setup Pages
        id: pages
        uses: actions/configure-pages@v6
      - name: Build with Hugo
        env:
          HUGO_ENVIRONMENT: production
          HUGO_ENV: production
        run: |
          hugo --gc --minify --baseURL "${{ steps.pages.outputs.base_url }}/"
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v5
        with:
          path: ./public

  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v5

fetch-depth: 0 in the checkout step matters if you turn on enableGitInfo later. Without full history Hugo can’t read a page’s last commit date. One setting has to happen by hand: in the repo’s Settings > Pages, set Source to GitHub Actions, not Deploy from a branch. That’s what lets actions/deploy-pages publish without a gh-pages branch or a committed CNAME file at all. A custom domain is set in that same Pages screen. GitHub writes and manages the CNAME file for you from there.

Push, and the Actions tab shows the build and deploy jobs running. A few minutes later the site is live at your GitHub Pages URL, or your custom domain if you set one, no server, no SSH key, no FTP, just Actions minutes GitHub already gives away for free on a public repo.

Add a theme

This is the piece that fixes the blank page and WARN lines from earlier. Hugo doesn’t ship with a default look, a theme is what supplies the actual templates. themes.gohugo.io has a few hundred to pick from, or you can build your own the way I did: hugo-omegion , the theme this blog runs. Sidebar-first layout, dark/light mode, client-side search with no backend, Mermaid diagrams, syntax-highlighted code blocks with a copy button, RSS, and the SEO/OpenGraph/JSON-LD metadata a blog actually needs. MIT licensed, free to take.

Whichever theme you pick, I’d recommend installing it as a Hugo Module instead of the classic git submodule under themes/, it’s one version pinned in go.mod like any other dependency, instead of a submodule pointer nobody remembers to update:

hugo mod init github.com/<you>/myblog

# hugo.toml
enableEmoji = true
enableGitInfo = true

[[module.imports]]
path = 'github.com/omegion/hugo-omegion'

❯ hugo mod tidy
go: added github.com/omegion/hugo-omegion v1.0.16
hugo: collected modules in 607 ms

Rebuilding after that pulls in the theme’s layouts/, assets/, and static/, the WARN lines are gone and the page count jumps once there’s an actual template rendering each post:

❯ hugo --buildDrafts
                  │ EN
──────────────────┼────
 Pages            │ 11

What a theme doesn’t inherit automatically is the site’s own config. enableGitInfo, the searchindex output format a search box needs, and goldmark.renderer.unsafe = true for raw HTML in posts all have to be set in your own hugo.toml, not the theme’s. hugo-omegion’s README spells out the exact block to copy. Skip one and the symptom is quiet: a blank search box, no “Updated” date on a post, nothing that looks like an error.

Bumping the theme later is hugo mod get -u github.com/omegion/hugo-omegion, a normal diff in go.mod and go.sum, the same motion as updating any other Go module.

Conclusion

That’s the whole setup: a new Hugo site, a first post, a GitHub Actions workflow that builds and deploys it on every push, and a theme on top. No server to run, no database, nothing to patch, and no bill at the end of the month. Push a commit and the site is live a few minutes later. For a personal blog, that’s exactly the amount of infrastructure I wanted: none.

The previous post got me a ceph-rbd StorageClass backed by three-way replicated storage across the cluster. The thing I actually wanted it for is Postgres, so this post is a CloudNativePG (CNPG) cluster on top of it, with automated backups to S3 through the Barman Cloud plugin.

Prerequisites

1. A working ceph-rbd default StorageClass from the previous post .
2. Helm 3 .
3. An S3-compatible bucket and credentials for backups.

What Is CloudNativePG

CloudNativePG (CNPG) is a Kubernetes operator for running Postgres - you describe the cluster you want as a Cluster custom resource and it handles the rest: provisioning the instances, promoting a replica if the primary dies, wiring up roles and databases declaratively, and driving backups through a plugin like Barman Cloud. The part I actually wanted it for is not having to hand-roll failover myself - before this I’d have needed a StatefulSet, my own replication setup, and something watching the primary to promote a replica if it went down. CNPG does all of that from one CR.

Installing the Operator

CNPG needs cert-manager for its webhooks, plus the Barman Cloud plugin, which has to run in the same namespace as the CNPG operator itself. I wrap all of that - cert-manager, the operator, the backup plugin, and the cluster chart from the next section - as dependencies in my own postgres chart, so the whole thing lands as one Helm release. This part of the values file is the operator side:

cert-manager:
  crds:
    enabled: true

cloudnative-pg:
  config:
    clusterWide: true

plugin-barman-cloud: {}

clusterWide: true on the operator means it watches Cluster resources in every namespace, not just its own - useful once more than one app needs its own database.

The Cluster

I run this through the CNPG project’s own cluster chart, using its TimescaleDB packaging (Postgres 17 + the TimescaleDB extension bundled in, even though I’m not using hypertables yet - it was just the variant I standardized on):

shared:
  enabled: true
  type: timescaledb
  version:
    postgresql: "17"
    timescaledb: "2.17"
  mode: standalone   # fresh cluster, not a recovery

  cluster:
    instances: 1
    storage:
      size: 100Gi
      storageClass: ""   # empty = cluster default StorageClass = ceph-rbd
    resources:
      requests:
        cpu: "1"
        memory: 2Gi
      limits:
        cpu: "2"
        memory: 4Gi
    plugins:
      - name: barman-cloud.cloudnative-pg.io
        enabled: true
        isWALArchiver: true

With both pieces of the values file in place, one helm install brings up cert-manager, the CNPG operator, the Barman Cloud plugin, and the Postgres cluster itself together:

❯ helm dependency build
❯ helm install postgres . -n postgres --create-namespace -f values.yaml

Leaving storageClass empty is deliberate - it falls back to whatever the cluster’s default StorageClass is, so I don’t have to hardcode ceph-rbd in two places. mode: standalone is what makes this a fresh cluster instead of a restore; flipping that field plus a bootstrap.recovery block pointed at the same backup location is how I’d stand up a replacement cluster from backups later.

A Test Role and Database

CNPG can create roles and databases declaratively instead of running SQL by hand:

  cluster:
    roles:
      - name: demo
        ensure: present
        login: true
        superuser: false
        createdb: false
        connectionLimit: -1
        inherit: true
        passwordSecret:
          name: demo-postgres-credentials

apiVersion: postgresql.cnpg.io/v1
kind: Database
metadata:
  name: demo
spec:
  name: demo
  owner: demo
  cluster:
    name: postgres-cluster

Connecting to It

To poke at it from inside the cluster, I run a throwaway client pod rather than exec into the database pod directly:

apiVersion: v1
kind: Pod
metadata:
  name: psql-client
spec:
  containers:
    - name: psql
      image: postgres:17
      command: ["sleep", "infinity"]

❯ kubectl exec -it psql-client -- bash
root@psql-client:/# psql "host=postgres-cluster-rw.postgres.svc port=5432 dbname=demo user=demo"
Password for user demo:
psql (17.2)
Type "help" for help.

demo=> \dt
Did not find any relations.
demo=> \q

Scheduled Backups

Backups go through the Barman Cloud plugin to S3, on a daily schedule with a 30-day retention window:

  backups:
    enabled: true
    method: plugin
    pluginConfiguration:
      name: barman-cloud.cloudnative-pg.io
    provider: s3
    s3:
      region: eu-central-1
      bucket: my-pg-backups
      path: "/shared"
      accessKey: "<redacted>"
      secretKey: "<redacted>"
    scheduledBackups:
      - name: daily-backup
        schedule: "0 0 0 * * *"
        backupOwnerReference: self
        method: plugin
        pluginConfiguration:
          name: barman-cloud.cloudnative-pg.io
    retentionPolicy: "30d"

Those keys sit plaintext in the same values file as everything else in this homelab config - fine for a private repo, not something I’d do anywhere more exposed. I can also trigger a one-off backup outside the schedule with a Backup object:

❯ kubectl apply -f - <<EOF
apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
  name: postgres-manual-backup
  namespace: postgres
spec:
  cluster:
    name: postgres-cluster
  method: plugin
  pluginConfiguration:
    name: barman-cloud.cloudnative-pg.io
EOF

❯ kubectl get backup postgres-manual-backup -n postgres
NAME                     AGE   CLUSTER            METHOD   PHASE       ERROR
postgres-manual-backup   14s   postgres-cluster    plugin   completed

I haven’t had to pull the recovery lever on this cluster for real yet. Restoring is a separate Cluster with mode: recovery (instead of standalone) pointed at the same S3 path - CNPG replays the base backup plus WAL and comes back up as a new cluster, rather than overwriting the one that’s still running.

Conclusion

One Helm release gets me an operator-managed Postgres cluster, replicated storage underneath it courtesy of Ceph, and backups leaving the cluster every night without me doing anything. It’s a fresh cluster and I haven’t tested a disaster-recovery restore against it yet - that’s the next thing on my list, not something I’d claim works until I’ve actually broken it on purpose. Next post : this cluster is only reachable from inside the LAN, so I’ll expose an app in front of it to the internet through Cloudflare.

In the previous post I got a 3-node Talos cluster running, but it has no storage - anything that writes to disk loses everything the moment its pod moves. The reason I care is Postgres, which is coming in the next post, so this one is about getting a real, replicated StorageClass in place first: Rook Ceph, spread across all three nodes.

Prerequisites

1. The 3-node Talos cluster from the previous post .
2. Helm 3 .
3. A spare, unpartitioned chunk of disk on each node for Ceph to use.

What Ceph and Rook Actually Do

Without something like this, a PersistentVolumeClaim backed by local disk is stuck on whichever node created it - if the pod gets rescheduled to another node, its data doesn’t come with it. Ceph pools the disks across all three nodes into one distributed storage cluster and replicates data between them, so a volume isn’t tied to a single node’s disk anymore - a pod can land on any of the three and still mount the same volume, with Ceph handling where the actual replicas live and keeping them in sync.

Rook is what makes running Ceph itself not miserable: it’s a Kubernetes operator that deploys and manages the Ceph cluster - mons, mgrs, OSDs, the CSI driver - from a handful of CRDs, and reacts to things like a node going down by rebalancing data instead of me doing it by hand.

Giving Talos a Raw Partition for Ceph

Each node only has one NVMe drive, so instead of a second physical disk I had Talos carve the drive into two managed volumes: the normal EPHEMERAL volume for the OS, and a raw volume for Ceph to claim as a block device.

apiVersion: v1alpha1
kind: VolumeConfig
name: EPHEMERAL
provisioning:
  diskSelector:
    match: disk.transport == 'nvme'
  maxSize: 100GiB
---
apiVersion: v1alpha1
kind: RawVolumeConfig
name: osd-data
provisioning:
  diskSelector:
    match: disk.transport == 'nvme'
  minSize: 10GiB
  grow: true

EPHEMERAL is where container images, pod logs, and etcd actually live - the normal day-to-day disk usage of running Kubernetes on the node. I capped it at 100GiB on purpose: left unbounded, that’s the volume that grows quietly over time as images pile up and logs accumulate, and I don’t want it eating into the space I need for Ceph. osd-data gets a 10GiB floor and grow: true to claim whatever’s left on the disk beyond that cap.

Applying that config (same talosctl apply-config flow as part 1) makes Talos create the partition and label it r-osd-data, which is what I point Rook at below.

Installing Rook Ceph

I install the upstream rook-ceph and rook-ceph-cluster charts with a values file. The important parts:

rook-ceph-cluster:
  toolbox:
    enabled: true   # for `ceph status` debugging

  cephClusterSpec:
    mon:
      count: 3
      allowMultiplePerNode: false
    mgr:
      count: 2   # active/standby
    dashboard:
      enabled: true
    storage:
      useAllNodes: false
      useAllDevices: false
      nodes:
        - name: "node1"
          devices:
            - fullpath: /dev/disk/by-partlabel/r-osd-data
        - name: "node2"
          devices:
            - fullpath: /dev/disk/by-partlabel/r-osd-data
        - name: "node3"
          devices:
            - fullpath: /dev/disk/by-partlabel/r-osd-data

❯ helm repo add rook-release https://charts.rook.io/release
❯ helm repo update
❯ helm install rook-ceph rook-release/rook-ceph -n rook-ceph --create-namespace
❯ helm install rook-ceph-cluster rook-release/rook-ceph-cluster -n rook-ceph -f values.yaml

The operator (rook-ceph) and the cluster (rook-ceph-cluster) are two separate chart installs into the same namespace - the operator first, then the cluster chart with the values above, which is what actually stands up the mons, mgrs, and OSDs.

3 nodes means 3 mons, which is the smallest quorum that tolerates one mon going down. useAllDevices: false plus an explicit nodes: list matters here - without it, Rook will happily try to claim any unformatted disk it finds, including the wrong one.

Replication Across All Three Nodes

  cephBlockPools:
    - name: replicapool
      spec:
        failureDomain: host
        replicated:
          size: 3
          requireSafeReplicaSize: true
      storageClass:
        enabled: true
        name: ceph-rbd
        isDefault: true
        reclaimPolicy: Delete
        allowVolumeExpansion: true

failureDomain: host plus size: 3 means every object gets a full copy on each of the three nodes - I can lose one node entirely and still have every piece of data available twice over. ceph-rbd becomes the default StorageClass, so anything that creates a PersistentVolumeClaim without specifying one lands here automatically.

I also explicitly turned off the two other pool types the chart wants to create by default:

  cephFileSystems: []
  cephObjectStores: []

Both CephFilesystem and CephObjectStore default to erasure-coded pools that need 3 failure domains of their own on top of the block pool. I only need RBD block storage for a database, so leaving those enabled would just be wasted capacity on a 3-node cluster.

Testing It With a Throwaway Pod

Before trusting it with a database, I wanted to prove a pod’s data actually survives a restart:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ceph-test-pvc
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: ceph-rbd
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: ceph-test-pod
spec:
  containers:
    - name: test
      image: busybox
      command: ["sh", "-c", "echo hello from ceph > /data/hello.txt && sleep 3600"]
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: ceph-test-pvc

❯ kubectl apply -f ceph-test.yaml
❯ kubectl get pvc ceph-test-pvc
NAME            STATUS   VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS
ceph-test-pvc   Bound    pvc-a1b2   1Gi        RWO            ceph-rbd

❯ kubectl delete pod ceph-test-pod
❯ kubectl apply -f ceph-test.yaml
❯ kubectl exec ceph-test-pod -- cat /data/hello.txt
hello from ceph

The pod got deleted and recreated, the PVC stayed bound, and the file was still there. That’s the whole point.

Conclusion

Three Ceph mons, three-way replicated block storage, and a default StorageClass that survives a node dropping out. It’s not fast storage - network-replicated block storage on consumer NVMe over a home LAN never will be - but it’s durable, which is what a database actually needs. Next post : putting a real Postgres cluster on top of it.

I was running a handful of services on a managed Kubernetes cluster on Hetzner. It worked fine, but the hardware pricing kept climbing and I was paying every month for compute that idled most of the time. I ended up with three small mini PCs (16-32GB RAM each) sitting on my desk instead, and decided to move those services onto a real cluster of my own: something that survives a node dying, that I don’t have to SSH into to patch, and that I don’t have to babysit. Talos Linux fit that better than a regular distro plus kubeadm - no shell, no package manager, the whole machine is configured from one YAML file and managed over an API. This post is the base cluster. Storage, a database, and exposing something to the internet come in later posts.

Prerequisites

1. Three (or more) amd64 machines that can run Talos Linux. I used three mini PCs.
2. Each machine booted into Talos maintenance mode (a Talos ISO on a USB stick works fine).
3. talosctl installed locally.
4. A LAN segment where you can hand out static IPs to the nodes.

Why All Three Nodes Are Control Plane

Three nodes is the minimum for an etcd quorum that survives one node going down. I didn’t have a fourth machine to dedicate as a worker, so instead of one control-plane node and two workers, all three run as control plane with scheduling enabled on them:

cluster:
  allowSchedulingOnControlPlanes: true

That gets me HA etcd and three schedulable nodes, at the cost of workloads sharing the box with the control plane components. For a homelab that tradeoff is fine.

Generating the Base Config

talosctl gen config homelab https://192.168.1.10:6443 --output-dir configs

This writes controlplane.yaml, worker.yaml, and talosconfig into configs/. Since every node here is a control-plane node, I only need controlplane.yaml - copied once per node and edited for hostname and IP.

Per-Node Network Config

Each node gets a static IP instead of DHCP, plus its hostname:

machine:
  network:
    hostname: node1
    interfaces:
      - interface: eth0
        dhcp: false
        addresses:
          - 192.168.1.10/24
        routes:
          - network: 0.0.0.0/0
            gateway: 192.168.1.1
    nameservers:
      - 192.168.1.1
  install:
    disk: /dev/nvme0n1
    wipe: false

node2 and node3 are the same file with 192.168.1.11 / 192.168.1.12 and the matching hostname: at the bottom.

Laid out, the network looks like this - all three nodes and my laptop share one flat 192.168.1.0/24 LAN, kubectl only ever talks to node1 directly, and the nodes talk to each other over etcd to keep quorum:

CNI: Flannel, With NetworkPolicy Actually Enforced

Talos ships Flannel by default. As of Talos 1.13, Flannel can enforce standard Kubernetes NetworkPolicy objects natively, which meant I didn’t need to bolt on Calico or Cilium just to get policy enforcement:

cluster:
  network:
    cni:
      name: flannel
      flannel:
        kubeNetworkPoliciesEnabled: true

Without that flag, NetworkPolicy resources are accepted by the API but silently not enforced - worth knowing before you assume a policy is doing anything.

Why I Actually Need NetworkPolicy Here

These three nodes sit on the same flat LAN as the rest of my house - no VLAN, no physical separation between “cluster” and “home network.” By default a pod can reach my NAS or router just as easily as it can reach another pod. NetworkPolicy is the only thing stopping that.

The pattern is default-deny egress per namespace, plus an explicit carve-out for anything that needs the internet:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: postgres-egress
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 192.168.1.0/24
      ports:
        - protocol: TCP
          port: 443

Allow HTTPS to anywhere, except the home LAN - a pod can reach S3, not my NAS.

Worth being honest about what this is: not real isolation. No VLAN, no firewall appliance, enforcement happens in Flannel on the same node the pod runs on - a kernel or CNI bug bypasses it entirely. It stops the boring case, a buggy app reaching somewhere on my LAN it shouldn’t, which is good enough for a homelab. Anywhere it actually mattered, physical or VLAN segmentation would be step one, not a “maybe later.”

Applying Config and Bootstrapping

While a node is still in maintenance mode it’s on a temporary DHCP address, not the static one baked into its config yet, so the first apply targets that temporary address with --insecure:

❯ talosctl apply-config --insecure -n 192.168.1.110 --file configs/node1.yaml

Repeat for node2 and node3 against their own temporary addresses. Once all three have rebooted onto their real static IPs, bootstrap etcd on one of them:

❯ talosctl bootstrap -n 192.168.1.10

Then pull a kubeconfig:

❯ talosctl kubeconfig ~/.kube/homelab -n 192.168.1.10
❯ export KUBECONFIG=~/.kube/homelab
❯ kubectl get nodes
NAME    STATUS   ROLES           AGE   VERSION
node1   Ready    control-plane   3m    v1.36.3
node2   Ready    control-plane   2m    v1.36.3
node3   Ready    control-plane   1m    v1.36.3

No VIP Yet, Just Quorum

Worth being honest about a gap here: cluster.controlPlane.endpoint points at node1’s static IP directly, not a floating VIP. What I have is etcd quorum HA - the cluster tolerates one node going down - not endpoint HA. If node1 itself is the one that goes down, kubectl pointed at 192.168.1.10:6443 stops working until I repoint it at node2 or node3 manually, since all three run the API server. That’s a real limitation I’m leaving for later - a keepalived VIP or an external load balancer would fix it, but for a cluster with one client (me) it hasn’t been worth the extra moving part yet.

Conclusion

Three nodes, one YAML file each, no SSH, no OS to patch by hand. The cluster itself was the easy part - it doesn’t do anything yet. Next up: persistent storage , because a Postgres cluster is coming and it needs somewhere to put its data that survives a node reboot.

It runs on a Cloudflare Durable Object per room, using the WebSocket Hibernation API so an idle room holds no live compute between messages — state lives in the Durable Object’s SQLite storage and rehydrates on the next message. Rooms clean themselves up after 30 days of total inactivity.

When building a static website with Vuepress, Hugo, or mkdocs, it is not possible to add API tokens to authenticate requests. This is a security measure to prevent unauthorized access to your API and data. However, if you need to provide a service that does not require authentication.

These services allow you to deploy static websites and APIs without the need for authentication, making it easier to build and deploy your applications.

The Counter API addresses this issue by offering a free API that does not require authentication to count things. This means that anyone can access the API and use it to count anything, without the need for any credentials or authentication.

This is a great solution for developers who want to build applications that require counting without the need for authentication. The Counter API is a simple and easy-to-use API. Overall, the Counter API is a great solution for developers who want to build applications that require counting without the need for authentication.

What is Counter API?

The Counter API is a simple and easy-to-use REST API that allows developers to store and retrieve count data in static applications without the need for a backend.

With the Counter API, you can easily keep track of user engagement, website traffic, and other important metrics without the need for a database or server.

The API is available in both JavaScript and Go programming languages, making it easy for developers to integrate it into their projects.

How to use it with Javascript?

The Counter API is a module that can be easily integrated into your JavaScript project without the need for API calls. Simply import the module and use it in your code to track and analyze website visitors.

The fastest way to get Counter API for your project, install it with yarn or npm.

To use it, open up your terminal in the desired directory and run the following command:

yarn add counterapi.dev

Count Up

You can count up with a given name and the name of the counter is unique. This means that only one person with that name can count up or down at a time. It’s important to note that anyone with the same name can also count up or down, so be sure to choose a unique name for your counter.

import {CounterAPI} from "counterapi";

const counter = new CounterAPI();

counter.up("test", "test").then((res) => {
    console.log(res)
})

How to use it with Golang?

The Counter API is a powerful REST API that allows developers to store and retrieve count data in a variety of applications. With the Counter API, you can easily keep track of user engagement, website traffic, and other important metrics without the need for a database or server.

The API is available in both Go and CLI programming languages, making it available for a wide range of platforms. The Go library provides a convenient way to integrate the API into your Go projects, while the CLI provides a simple way to manage your count data from the command line. Whether you’re a developer looking to build a custom dashboard or a business owner looking to track their website traffic, the Counter API is the perfect solution for you.

Installation

The fastest way to get Counter API for your project, install it with go itself.

To use it, open up your terminal and run the following command:

go install github.com/counterapi/counter-go@latest

Count Up

You can count up with a given name and the name of the counter is unique. This means that only one person with that name can count up or down at a time. It’s important to note that anyone with the same name can also count up or down, so be sure to choose a unique name for your counter.

❯ counter up --name MyCounter01 --namespace example.com               
{
    "id": 12,
    "name": "MyCounter01",
    "count": 1,
    "created_at": "2021-03-28T21:19:09.450461117Z",
    "updated_at": "2021-03-28T21:19:09.466029457Z"
}

Conclusion

In conclusion, the Counter API is a great solution for developers who want to build applications that require counting without the need for authentication. The API is available in both JavaScript and Go programming languages, making it easy for developers to integrate it into their projects.

The Counter API is a simple and easy-to-use API that allows developers to store and retrieve count data in static applications without the need for a backend. With the Counter API , you can easily keep track of user engagement, website traffic, and other important metrics without the need for a database or server. Overall, the Counter API is a great solution for developers who want to build applications that require counting without the need for authentication.

When we access a website, we anticipate a swift loading experience. If it lags, we tend to navigate elsewhere. Hence, the speed of websites is crucial. Employing a cache is a key method to boost website speed. A cache serves as a brief repository for swiftly accessible data. While many websites utilize CDNs (Content Delivery Networks) to cache static content such as images, CSS, and JavaScript files, what about dynamic content?

Certain queries exhibit varying response times due to disparities in processing power and database access requirements. For queries that don’t necessitate real-time data, we can implement caching to expedite their results.

In this post, we’ll explore the process of configuring Redis caching for Go Gin Tonic, allowing you to optimize your API queries by retrieving cached responses without accessing the database.

Prerequisites

1. Go 1.16 or higher
2. Redis 6.2 or higher
3. Gin 1.7 or higher
4. gin-cache 1.8 or higher

What is Gin Framework

Gin is a popular web framework for building web applications and APIs in the Go programming language (Golang). It’s designed to be minimalistic yet highly efficient, making it a top choice for developers who want to create performant applications with minimal boilerplate code.

The key features of the Gin web framework for Go (Golang) in brief are:

1. High Performance: Known for its speed and efficiency.
2. Lightweight: Minimal overhead, with flexibility to add components.
3. Middleware Support: Easily integrate functionality like authentication and logging.
4. Efficient Routing: Intuitive routing system for URL handling.
5. Validation: Built-in support for data validation.
6. Error Handling: Effective error management.
7. JSON Parsing: Simplified JSON handling.
8. Modular: Use as a standalone framework or integrate with other libraries.

What is Redis

Redis, short for “Remote Dictionary Server,” is an open-source, in-memory data store and caching system. It is often referred to as a “data structure server” because it supports various data structures like strings, lists, sets, hashes, and more. Redis is known for its exceptional speed and is widely used as a caching mechanism and real-time data store.

Getting Started

1. Install Gin Framework

Let’s start by installing Gin Framework. To do so, run the following command:

$ go get -u github.com/gin-gonic/gin

2. Create a Go file

First, create a file called example.go:

# assume the following codes in main.go file
$ touch main.go

3. Let’s create a basic Gin application

Create a basic Gin application in the main.go file:

package main

import "github.com/gin-gonic/gin"

func main() {
	r := gin.Default()
	r.GET("/ping", func(c *gin.Context) {
		c.JSON(200, gin.H{
			"message": "pong",
		})
	})
	r.Run() // listen and serve on 0.0.0.0:8080
}

4. Create Redis Cache configuration

package main

import (
	"fmt"
	"os"
	"time"

	"github.com/counterapi/api/pkg"

	"github.com/chenyahui/gin-cache/persist"
	"github.com/go-redis/redis/v8"
)

// RedisCache is a config struct for redis cache.
type RedisCache struct {
	Store            *persist.RedisStore
	DefaultCacheTime time.Duration
}

// SetupRedisCache sets the redis up.
func SetupRedisCache() *RedisCache {
	return &RedisCache{
		Store: persist.NewRedisStore(redis.NewClient(&redis.Options{
			Network: "tcp",
			Addr: fmt.Sprintf(
				"%s:%s",
				os.Getenv("REDIS_HOST"),
				os.Getenv("REDIS_PORT"),
			),
		})),
		DefaultCacheTime: 10 * time.Second,
	}
}

5. Let’s use the config to cache the response

Use the RedisCache struct to cache the response of /ping endpoint. This will cache the response for 10 seconds.

package main

import "github.com/gin-gonic/gin"

func main() {
	r := gin.Default()
	cacheConfig := SetupRedisCache()

	r.GET(
		"/ping",
		cache.CacheByRequestURI(cacheConfig.Store, cacheConfig.DefaultCacheTime),
		func(c *gin.Context) {
			c.JSON(200, gin.H{
				"message": "pong",
			})
		})

	r.Run() // listen and serve on 0.0.0.0:8080
}

Conclusion

To boost website speed, one of the most effective techniques is the use of caching. Caching involves temporarily storing frequently accessed data so that it can be rapidly retrieved without the need to access the original data source. While Content Delivery Networks (CDNs) are commonly used to cache static assets like images and scripts, the question remains: how can we efficiently cache dynamic content?

This blog post has explored the process of setting up Redis caching for Go Gin Tonic, a popular web framework for building high-performance web applications and APIs in the Go programming language (Golang). By leveraging Redis, you can optimize your API queries by retrieving cached responses, eliminating the need for repeated database access.

By following these steps, you can harness the power of Redis caching to enhance the speed and responsiveness of your Go Gin Tonic applications, ensuring a smoother and more efficient user experience. Caching dynamic content has never been easier, thanks to the combination of Gin and Redis.

A Dockerfile is a document that contains all the instructions to build an image. Basically, you create an image on top of the existing image with given specifications on the Dockerfile. Then Docker will take this file and follow your instructions to create a brand new image on top of the base image.

A base image is an image built by other users. Usually, the base image is a fundamental OS image. For example alpine or ubuntu. The base image gives you a base that you can instruct. Usually, we install our custom packages on top of the base image. However, we need multiple base images based on different needs.

Prerequisites

• docker

What is multi-stage

Say that you have Go project and you need to build it. For this case, you will need some packages only required for the build itself we do not want to keep these packages in our image just for build purposes.

Multi-stage Image Example

That is the reason that we need to use multi-stage to reduce our image size. Let’s create an image for an example:

FROM golang:1.17-alpine3.14 AS builder

WORKDIR /app

COPY ./ /app

RUN apk update && \
  apk add ca-certificates gettext git make curl unzip && \
  rm -rf /tmp/* && \
  rm -rf /var/cache/apk/* && \
  rm -rf /var/tmp/*
  

RUN go build -o my-binary main.go