June 2026 Tech Stack
I like writing these out to see how they change over time. I’ve added a lot of components to them over the years as I learn more about tools. I think I might finally be in a place where I could take something from nothing to deployed without too much click ops, in a way that can grow. And fast, cheaply. I know I better understand each part of the “stack” and tradeoffs made along the way.
The site
I’m mostly building websites, so this section is geared towards that. It’s also the place with the most latitude here… Rails, Phoenix, and Laravel are big players and pretty full featured. I like the idea of Golang for some of my smaller stuff.
Well known route, server rendered
- ruby
- rails (active record, active job, solid queue, etc.)
- hotwire
- omniauth (? for oauth)
Client side rendered
I’d reach for preact or solid if I needed to move fast, but maybe Lit or Svelte if I had a chance to try some new things. I’d only reach for this if I was planning offline functionality a la PWA.
The new hotness – A Golang stack
I think this would be lightweight and fast. It has lots built into the standard lib, pretty well.
- golang - language
- cobra - command line tool, so it could do more than
serve - viper - command line helper
- sqlc/sqlx - start with sqlite
- goose/dbmate - language agnostic migrations, with Go API so the app could actually migrate when starting up
- SQLite via modernc.org/sqlite, unless I go postgres
- backlite - background jobs
- htmx? alpine? - some frontend interactivity
- chi/stdlib - do I need a http framework? Or can I use the standard library?
- templ/stdlib - do I need a templating framework? Or can I use the standard library?
- oauth via coreos/go-oidc/v3 + x/oauth2 - so I can put this behind Authelia and not write auth myself.
Well trodden and quick
I could throw this together in an afternoon and have a demo for you. It wouldn’t scale as well as the Rails app though and probably wouldn’t be as fast the the Golang app
- node
- express
- nunjucks
- sqlite
Packaging / deployment
A brand new section for me, I thought it deserved it’s own section because it sits somewhere between building the app and the infrastructure it runs on. They have different lifecycles, they deserve different sections but bridging the gap in a way that deployment doesn’t have to rely on the app can be a tough problem. It boils down to creating an artifact that your deployment knows how to use. Containers are an easy answer, but for my static sites were actually way overkill. If I were using Kubernetes, that would affect this choice too. But deploying on my own VPS’s had me “go native”
Packaging everything up in a native format for my VPS makes it easier to just copy over and run install from the infra side. Out of band secret management is a different story, it has its own section below.
- buildah - building containers, part of podman the way I use it.
- nfpm - building debian packages
- tar - if all I need is a tarball
(what, I said native but I’m building containers??? See the podman item under infra)
The infra
A completely revamped section. I’ve felt mostly comfortable deploying to my own machine for a while now. Either with Kamal or some bash scripts. But Kamal was a little too constraining and my bash scripts never felt very polished. Recently, I’ve dropped Kamal but it could come back.
- OpenTofu - provisioning infrastructure
- cloud-init - getting my basic packages in place
- mise tasks - uploading/deploying my packages, bash scripts with ways to use flags and envvars effectively.
- systemd - process supervisor, much lighter weight than kubernetes or other options, often built in. Capable of running timers to process backups as well.
- caddy - used as a reverse proxy for my apps, or serving them directly with a caddy file. can be run directly on the VPS as a systemd service. Allows me to reverse proxy or serve static files as I’d like.
- podman - provide a container runtime, running containers as systemd services via quadlets (and their systemd generator).
Secret Management and Sensitive Values
I’m not sure how best I like doing this quite yet. sops is an easy answer for deploying sensitive values. Then age (with ssh) since I’m keeping it low cost for myself. I should probably re-encrypt the sensitive values as part of their deployment. In a case where I was using a KMS it would be a non issue. And a KMS would be an easy sell for business
- sops
- age
- ssh
What Did I Forget?
What about all the things apps need, like a database? high availability? failover? telemetry? auth? uptime monitoring?
Those are great questions. I didn’t include them above, the above allows me to more flexibly deploy any and all of these things. Caddy could give me some HA/Failover I think, but doesn’t the way I’m using it.
- Authelia - oauth provider, I want my users to be able to access all my apps with one log in.
- Victoria Metrics - going to try instead of Prometheus
- Jaeger
- Grafana Loki
- Uptime Kuma
- Tailscale/Wireguard for secure comms
- Zot - container registry, if I need one.
- Seaweed FS - if I need an S3 bucket, or I could use Backblaze
There’s a lot of Golang services in that list, which is a big part of what has me looking at Go. I’m not sure if it’s fortunate or unfortunate that there isn’t a big framework in Go, but a lot of the CNCF projects seem to do great in Go without it.
Dev Tools
Very often these posts list dev tools for me. This section hasn’t changed very much, but let’s list things out again. Commands I run in the course of a day. Apps I use for development.
- ghostty
- tmux
- neovim
- batcat
- eza
- fzf
- git
- mise
- usage
- bash
- curl
- jq
mise has been a huge productivity boost. Along with usage to define flags and envvars and running by default in a known directory are both huge quality of life improvements. I guess I don’t need mise for usage, but the combination has been powerful.