The AWS console is great until you want to give someone a read-only link to a single bucket. Then it’s terrible: you have to mint an IAM user or a federated role, walk them through the console, scope it down, deal with their MFA, and so on. All they wanted was to browse a folder.

s3xplorer started as a weekend POC to play with the AWS Go SDK v2 and the minio client, and turned into the tool I now use to expose a bucket to humans without giving them AWS credentials.

Go doesn’t enforce a project layout. That freedom is powerful but requires discipline — start simple and let structure emerge as complexity grows.

When your Go project depends on an internal library living in a private GitLab repository, a plain go get will fail — GitLab doesn’t know who is asking, and Go doesn’t know the repository is private. Fortunately, a handful of configuration steps sorts everything out, both locally and in CI.

gitlab-backup: Back Up and Restore GitLab Projects from the Command Line

Source code: github.com/sgaunet/gitlab-backup

When you self-host GitLab or rely heavily on gitlab.com for your projects, having an independent backup strategy is essential. GitLab’s own backup mechanism works well at the instance level, but sometimes you need something more surgical: back up a single project, or an entire group, on demand, and store the result locally or in S3. That’s what gitlab-backup does.

I’ve been maintaining perplexity-go for a while now — a small Go client for the Perplexity AI API. It started as scratching my own itch (I needed a CLI to query Perplexity from scripts) and grew into a library I now reach for whenever a Go project needs real-time, cited answers from the web.

This post is a tour of what it does, why it exists, and how to use it.