If you’re connecting from a system that’s a long distance away from your server in terms of latency, mosh can be more comfortable to use than ssh.

Maybe a bit more on the overkill side, but I use Talos Linux (declarative K8s distribution), then Terraform for initial setup and FluxCD for everything else (including VMs via Kubevirt). It’s a hell of an initial learning curve, but afterwards I just do my talosctl upgrade and upgrade-k8s from time to time, and don’t have to worry about anything else. Upside is, Kubernetes provides a unified, extensible API for everything, for example:

• reverse proxy via Ingress or Gateway-API
• firewall via NetworkPolicy
• even databases like Postgres through an Kubernetes Operator like CNPG, with a similar simplicity as with the big cloud providers (just a single yaml file with the specs like storage capacity, CPU and memory limits, backup target and schedule etc.)
• it is very scriptable (everything is managed via the API)
• automated image updates via either FluxCD itself or just dependabot/RenovateBot creating PRs to your GitOps repo

Downsides:

• you have to figure out persistent storage (CSI), which is slightly more complicated than just a single filesystem and manually specifying volume mounts like with docker, but if done right, you have a simple interface with powerful capabilities via the Kubernetes API
  • there are simple CSI implementations that just expose node local disks via LVM or ZFS, so if you just have a single node, or don’t care about replication, it’s fairly easy to get started
• initial learning curve is quite high, especially if you have no prior experience with container orchestration in general
• definitely overkill if you just want something simple that “just works”

Local ansible playbook, easily replayable and documented. This in a git repo and you’re fine.

Tailscale service configs for HTTPS ingress and DNS resolution. Podman quadlets / podlets for everything except backup software and tailscale itself. I use the open version of VS code to edit config files in place, but I push them to a private git as well as having them backed up. Storage for app data, media, and configs (everything but OS) is via NFS shares from my gaming PC’s RAID volume. I can run a plenty of apps on an old thinkpad this way. After you configure the first few quadlets with tailscale, it gets real straightforward, but there is a learning curve. Yes, I use SSH, but it is the remote conmection and terminal in Code.

Premise: most, if not all, of my services run in containers.

I have recently moved to docker context. It’s a pretty cool feature that I don’t see mentioned that often. Essentially it allows to run docker commands from your machine and tunnel them via SSH to your server. What I like about this is that I need all the compose file in my main machine and structure them into a repository so that I don’t have everything scattered around. The new approach I have implemented very recently is this.

One monorepo with one folder per server and in each one a folder per service containing docker compose and .env files. With dotenv I sent the docker context whenever I enter a specific folder, so as soon as I cd into that folder, any docker command I run from there would be tunneled to the correct server.

For everything that does not run in docker, which is not much I think at the moment only vector to collect metrics and logs, I use Ansile. In this case the need is that I want Vector to run on all servers so Ansible is the better choice here.

I wait for something to break. Then I yell “God fucking dammit, I don’t have time for this right now!” and spend an hour triaging things before I just try docker down, pull, up and everything works.

Poorly.

I just use ssh and manually type commands. Keep doing it and you will get good and it will become second nature.

No need to burn tokens on basic tasks.

Master your tools. Learn awk, sed, just, etc.

Some shell customisation can help. For example I’m fond of zsh-auto-suggestions and skim. Makes me quicker.

Ansible is one way to “code local, push to remote(s)”. Can define so-called playbooks, which is basically just a script, to do reoccuring tasks like e.g. updates.

“code local and push remote” is only more efficient if you have a faulty connection with ssh or want to use a GUI editor that doesn’t support remote connections. What you’re doing is good. You can scoure for more “modern” ways that might have more glimmer and sparkly lights, but it won’t improve efficiency.

I write my NixOS configs in my PC, commit to the repo, then push it to the server. Then SSH in, and apply it. Or more likely, MOSH in.

I created git repos on my main workstation for each homelab server/service I maintain that keeps:

• documentation
• notes
• lessons learned
• scripts, configs
• runbooks
• backup details
• security audit details
• log items that need attention
• infrastructure

I just point a local LLM (offline model that runs on my workststion) into those repos and ask it to perform certain things on those servers. It can do things like update packages, install packages, make config changes, set/check permissions, read logs (and fix errors in real time), and check the health of the overall system.

I have it run pre backups before making changes, then post backups once its done.

Once changes are in place and everything is running okay, I ask it to update documentation in the repo and tag the release.

I use opencode that connects to a llama.cpp service. opencode lets me gate the AI so that any elevated commands that it needs to run (e.g. sudo or ssh), I have to approve it. It cant just go around making changes without permission.

A mix of prayer and bash scripts.

It’s good to get comfortable in the command line, including over ssh.

Especially considering ai and documentation along the way?

If I am going to ask AI or Google about something, I just do that to help me find the answer and then apply the answer myself. That way I learn, and can double check the AI isn’t hallucinating, at least on in obvious ways.

As for documentation, I keep a notes folder with detailed notes on manual configuration I’ve done, how and why, and the things I’ve learned along the way. I’ve found it’s both useful to help remember the things I’ve learned, and it is useful to go back to refer to.

Nothing wrong with good old ssh. My VMs are different enough that building and maintaining ansible playbooks or something similar would be a bigger task than actually doing it in the traditional way. Maybe I could benefit by building simple playbooks to populate user accounts, ssh keys, smtp relay settings and other common things, but I don’t really set up new servers that often that it would justify spending time to set up tools for that.