Tools on hxmn.dev

My Networking Setup

Thu, 16 Apr 2026 10:00:00 +0300

I run machines in a few different places — a home lab, a cloud VPS, a laptop that travels with me. Keeping them all on one coherent private network, with stable names and encrypted transport, is the thing I did not want to think about every day. This page collects the pieces I landed on.

Service Connectivity

For the private network I use headscale — an open-source, self-hosted implementation of the Tailscale control server. Clients are the unmodified Tailscale clients; only the coordination server is mine.

flowchart LR
 HS[Headscale
control server]

 subgraph tailnet [Tailnet]
 L[Laptop]
 V[Cloud VPS]
 R[Subnet router
home lab]
 end

 DB[(Postgres
10.0.0.5)]
 D[DERP relay]

 L -. keys / ACLs .-> HS
 V -. keys / ACLs .-> HS
 R -. keys / ACLs .-> HS

 L <== WireGuard ==> V
 L <== WireGuard ==> R
 R --> DB

 L <-. fallback .-> D
 V <-. fallback .-> D

The control plane (dotted lines) only hands out keys and policy; all service traffic (thick lines) is direct WireGuard between peers. DERP is a relay used only when a direct path cannot be established.

Why headscale

Sovereignty. Account, keys, and ACLs live on a box I control. No SaaS account to expire, no per-device limits, no upstream outage breaking my mesh re-keying.
Zero-config client side. Every node — macOS, Linux, iOS, router — runs the same Tailscale client I would use anyway. No custom builds.
WireGuard underneath. Fast, modern, encrypted by default. I do not run a classic VPN gateway.

Typical deployment

The server is a small VPS with a public IP. A single Go binary (headscale serve) listens on localhost:8080 and a reverse proxy (Caddy, in my case) terminates TLS for https://headscale.example.com. Configuration lives in /etc/headscale/config.yaml — the defaults are close enough that I only touched a handful of fields:

server_url — the public URL.
listen_addr — loopback, since Caddy fronts it.
ip_prefixes — the CGNAT range for the tailnet (the default 100.64.0.0/10 is fine).
dns.magic_dns: true — so every node gets a stable DNS name inside the tailnet.

State is a single SQLite file; backing it up is cp.

Onboarding a node

Create a user on the control server: headscale users create ilya.
Issue a short-lived pre-auth key: headscale preauthkeys create -u ilya --expiration 1h.
On the new node: tailscale up --login-server https://headscale.example.com --authkey <key>.

That is the whole provisioning flow. The node joins the mesh, picks up its tailnet address, and is reachable by MagicDNS name from every other node.

Reaching services

With the mesh in place, service connectivity becomes boring in the best way:

Stable names. A Postgres instance on a home-lab host is just homelab-db:5432 from anywhere on the tailnet.
ACLs. Headscale supports Tailscale-style policy files. I scope which tags can reach which ports — the laptop can reach tag:dev, CI runners can reach tag:infra, nothing else.
Subnet routers. A single node advertises 10.0.0.0/24 from the home lab so I can reach devices that do not run Tailscale (a NAS, a switch’s management interface).
No inbound ports. Services never need to be reachable on the public internet. WireGuard punches out; the control server only coordinates.

DERP

Two nodes that cannot reach each other directly (both behind strict NATs) fall back to a DERP relay. I use Tailscale’s public DERP pool for this — headscale lets me mix in my own later if I ever need guaranteed-path control, but I have not needed to.

My Neovim Setup

Mon, 06 Apr 2026 11:00:00 +0300

I have been using Neovim as my primary editor for several years. The setup has gone through many iterations and landed on something minimal and fast.

Philosophy

Less is more. Every plugin must earn its place. If I can do it with a keymap and a built-in command, I skip the plugin.

Core Plugins

lazy.nvim — plugin manager. Lazy-loads everything.
nvim-lspconfig — LSP configuration for gopls, typescript-language-server, lua_ls.
nvim-cmp — completion engine. Sources: LSP, buffer, path.
treesitter — syntax highlighting, text objects, incremental selection.
telescope.nvim — fuzzy finder for files, grep, LSP symbols.
oil.nvim — file explorer as a buffer. Edit the filesystem like text.

LSP Configuration

local lspconfig = require('lspconfig')

lspconfig.gopls.setup({
 settings = {
 gopls = {
 analyses = { unusedparams = true },
 staticcheck = true,
 },
 },
})

lspconfig.ts_ls.setup({})

Key Mappings

vim.keymap.set('n', 'gd', vim.lsp.buf.definition)
vim.keymap.set('n', 'gr', vim.lsp.buf.references)
vim.keymap.set('n', 'K', vim.lsp.buf.hover)
vim.keymap.set('n', '<leader>rn', vim.lsp.buf.rename)
vim.keymap.set('n', '<leader>ca', vim.lsp.buf.code_action)

What I Skipped

No file tree (oil.nvim is better). No status line plugin (the built-in one is fine). No git gutter (I use the CLI). No AI completion (I prefer explicit requests).

Taskfile: A Modern Alternative to Make

Sat, 04 Apr 2026 14:00:00 +0300

Makefiles work. They have worked for decades. But they have sharp edges — tab sensitivity, implicit rules, .PHONY everywhere, and arcane syntax for anything beyond the basics.

Taskfile is a YAML-based task runner that does what most people actually use Make for, without the footguns.

Installation

brew install go-task

Basic Taskfile

version: '3'

tasks:
 build:
 desc: Build the application
 cmds:
 - go build -o bin/app ./cmd/app

 test:
 desc: Run all tests
 cmds:
 - go test ./...

 lint:
 desc: Run linters
 cmds:
 - golangci-lint run

 dev:
 desc: Run with live reload
 deps: [build]
 cmds:
 - air

What I Like

Variables and environment files:

tasks:
 deploy:
 dotenv: ['.env']
 cmds:
 - flyctl deploy --app {{.APP_NAME}}

Task dependencies with parallelism:

tasks:
 ci:
 deps: [lint, test, build]

Dependencies run in parallel by default. No need to wire up & and wait.

Conditional execution:

tasks:
 generate:
 sources:
 - 'proto/**/*.proto'
 generates:
 - 'gen/**/*.go'
 cmds:
 - buf generate

The task only runs if source files are newer than generated files.

When to Keep Make

If your project already has a Makefile and the team is comfortable with it, switching gains you nothing. Taskfile shines on new projects and for teams that are tired of debugging tab-vs-space issues.

Nix for Reproducible Dev Environments

Thu, 02 Apr 2026 10:00:00 +0300

Every project has a list of dependencies: Go 1.22, Node 20, PostgreSQL 16, protoc, golangci-lint. The traditional approach is a wiki page that says “install these things.” It is always out of date.

Nix solves this by declaring dependencies in a file that deterministically provides the exact versions you need, isolated from the rest of your system.

Getting Started with devenv

devenv is a friendly wrapper around Nix for development environments. Install it:

nix-env -iA devenv -f https://github.com/NixOS/nixpkgs/tarball/nixpkgs-unstable

Create a devenv.nix in your project:

{ pkgs, ... }:

{
 languages.go.enable = true;
 languages.go.package = pkgs.go_1_22;

 packages = [
 pkgs.golangci-lint
 pkgs.buf
 pkgs.postgresql_16
 ];

 services.postgres = {
 enable = true;
 initialDatabases = [{ name = "myapp"; }];
 };
}

Enter the environment:

devenv shell

You now have the exact Go version, tools, and a running PostgreSQL instance. No global installs. No version conflicts.

direnv Integration

Add a .envrc file:

use devenv

Now every time you cd into the project, your shell automatically loads the right tools. Leave the directory, and they disappear.

Why This Matters

New team members run devenv shell and they are ready. No setup docs.
CI uses the same Nix definitions, so local and CI environments are identical.
Upgrading a tool is a one-line change in devenv.nix, reviewed in a PR like any other code change.