Every few months I find myself stuck on the same kind of question: what exactly is hitting my service? A reverse proxy is mangling a header, a Kubernetes ingress is rewriting a path, a webhook provider is sending a body in some shape I didn’t expect. The fastest way to answer is to point the traffic at something that will tell me, in painful detail, what arrived.

That’s why I wrote http-echo: a tiny Go server that responds to any HTTP request by dumping a structured, human-readable report of everything it saw.

Hosting a Helm Chart Repository on GitHub with chart-releaser

GitHub Pages plus the helm/chart-releaser-action is the de facto way to turn a GitHub repository into a Helm chart repository. No extra hosting, no separate registry — just a gh-pages branch and a workflow file.

This post walks through the layout I use in practice: one repository for the application, a separate one for the chart.

gitlab-backup2s3: Encrypted GitLab Backups to S3, with Kubernetes Support

Source code: github.com/sgaunet/gitlab-backup2s3 Helm chart: github.com/sgaunet/helm-gitlab-backup2s3

In the previous article, I covered gitlab-backup, a CLI tool for exporting GitLab projects and groups as portable archives. It handles the export, the restore, and supports both local and S3 storage natively.

But for production backup workflows — especially in a Kubernetes environment — you often want more: scheduled execution, optional encryption at rest, and a container image that bundles everything together. That’s exactly what gitlab-backup2s3 brings to the table.