An Ansible playbook, or more specifically, ansible-playbook, runs from whatever Python, collections and system packages happen to be on the control node. That works when one person owns the environment or when a bastion is already pinned. It's a weak team contract: versions drift across laptops, CI runners, and shared hosts.
Ansible Navigator adds execution environments (container images for the control plane), a TUI for inspecting runs, and CLI behavior that lines up with AWX and Ansible Automation Platform (AAP). It runs and inspects the same playbooks and inventories when you want the runtime declared in an image tag instead of implied by the local machine.
This post covers installation, a first playbook, interactive vs stdout mode, custom images, configuration, and a CI-shaped workflow.
The best development machine isn't always the one under your hands. Laptops are great daily drivers, but they're also thermally constrained, battery-bound, and constantly moving between networks. For serious build and test work, especially on Go projects that need real Linux, Windows, and macOS coverage, I keep the compute somewhere stable and let my laptop act as the control plane.
With VS Code Remote Tunnels, you run the VS Code CLI on a remote machine, authenticate it with your GitHub account, and connect to that machine from VS Code or vscode.dev without opening inbound firewall ports, maintaining a VPN profile, or teaching dynamic DNS yet another way to disappoint you.
Remote development used to mean one of two things: SSH into a server and live in a terminal, or carry around a fragile stack of VPNs, jump boxes, port forwards, editor extensions, and local configuration. That worked, but it made the developer's laptop the place where every concern collided.
Modern remote development is a cleaner architectural split:
The laptop is the interface. It provides the screen, keyboard, editor, and whatever local ergonomics make you productive.
The remote node is the execution environment. It owns the CPU, memory, disk, operating system, SDKs, build cache, test dependencies, and long-running processes.
The identity provider brokers access. With Remote Tunnels, GitHub authentication gives you a familiar access path without requiring a public SSH endpoint.
That split lets you treat development environments more like durable infrastructure and less like whatever happened to be installed on the laptop.
For my open source work, the benefits are immediate. The builds are fast, but fast is relative when you're compiling repeatedly, running integration tests, linting large module graphs, or validating cross-platform behavior against platform-specific dependencies. A headless machine with more cores, more memory, a warm module cache, and a stable network turns the edit-build-test loop into something predictable. The laptop stays cool. The battery lasts longer. The build cache stays where the builds happen.
For most of my life, I thought everybody's brain was about like mine. Loud, busy, and hard to steer.
I figured other people were just better at keeping theirs in the lane. That was the story I had.
They could sit still. They could start the thing they didn't want to start. They could schedule the appointment, make the call, answer the email, finish a small task, then move on with their day like it hadn't cost them anything.
I thought I was lazy. Or weak in some way nobody had named out loud yet.
School taught me how to fake my way around it.
I could read a chapter three times and come away with almost nothing. Then a teacher would tell some sideways story in class, not even part of the lesson, and I'd remember the whole thing years later in detail. I could put off a paper until the night before, write it half-crazed at the kitchen table, and get a better grade than I did on the one I had tried to do the right way.
Nobody called that a pattern, not then.
Teachers said I was bright but scattered. Smart but unfocused. Capable of more, if only I would apply myself.
I heard that enough times that it stopped sounding like an opinion. It sounded like a verdict.
Free trials pile up. Side projects die. Shopping sites you used once still have your card on file. After a few years, you end up with a lot of accounts you don't remember creating and even less confidence in how they're secured.
Most online accounts don't disappear just because you stop using them. They can still hold your data, old passwords or recovery factors, and sometimes your payment details. Every forgotten login is another door you left unlocked.
Breach Exposure: forgotten accounts often still have weak or reused passwords, and many either don't support MFA or have it available but not enabled.
Privacy Leakage: abandoned accounts can keep personal data, billing details, and usage history long after you stop using the service.
Recovery Pain: if one gets hijacked, recovery can fail fast when the old email address, phone number, or other method is no longer yours.
Before deleting any account, confirm you no longer need access to purchased content, invoices, or exported data from that service.
Regular audits aren't exactly fun, but they keep your account footprint smaller and easier to defend.
I used to clean this up in occasional panic sessions. It never stuck. What finally worked was a simple lifecycle: inventory, classify, decommission, and monitor.
For a long time, publishing this site was simple in the best possible way. ProperDocs built the HTML, MaterialX handled the presentation, and a GitHub Actions workflow ran properdocs gh-deploy through task deploy. That command force-pushed the rendered site to a gh-pages branch, then GitHub's Pages backend quietly noticed the branch update and published it.
That model still worked, but the warning lights started blinking in the generated pages build and deployment job. GitHub was warning about Node.js 20 deprecation inside the Pages deployment path.
The noisy warning was only the symptom. The deeper problem was architectural: the deployment was still using a Git branch as an artifact transport.
The fix was to stop publishing a branch at all. The GitHub Action now builds the content, uploads the contents as GitHub Pages artifacts, and then actions/deploy-pages publishes it through GitHub's modern Pages deployment path.
Ansible runs need secrets at runtime: passwords, API tokens, private keys, TLS material, and cloud credentials. You don't have to keep those in Git. External stores, CI variables, and untracked local files are all valid patterns. Ansible Vault is for the case where you want encrypted variables and files versioned next to the playbooks, roles, and inventory that use them, with the vault password kept out of the repository.
This post walks through ansible-vault and the runtime flags that unlock encrypted content during a run: create and edit vaulted files, wire passwords from files or prompts, use vault IDs, and avoid the mistakes that still leak secrets after decryption.
Vault is built into Ansible. It's not a centralized secrets manager, and it doesn't replace runtime discipline around logs, registers, and task output.
A lot of what lands in an issue tracker isn't work. It's a question filed as a bug, a feature pitch that belongs in an Ideas thread, or an install problem with no version anywhere in the body. Each one gets read, relabeled, and pointed somewhere else, and none of that moves the backlog.
My answer is a discussions-first policy. Questions, ideas, and suspected bugs start in GitHub Discussions and get triaged in public. An issue gets opened once there's confirmed work to track, and not before.
It takes five pieces: issue chooser routing, a reserved issue template, discussion category forms, CONTRIBUTING.md, and a pinned rules thread. The forms have their own post, How to Write Effective GitHub Discussion Templates, with the YAML and the Ideas and Community Help examples. This one covers the policy and the wiring, including what happens when someone clicks New issue anyway.
I'm wiring up community intake for an upcoming open source project. Issue forms and a pull request template were the easy parts. Community discussions were what I hadn't nailed yet.
I wanted a public place for questions and early ideas without Issues turning into a pile of one-liners. I've set up GitHub Discussions on other repos before; this time I wanted the same structured intake issue forms already give you.
So I used discussion category forms: YAML on the same schema as issue templates, with required fields, defaults, and labels on create, tied to a category instead of an issue chooser. Questions stay in the forum. Work that needs a tracker still opens an issue.
If you've shipped issue templates before, the field types won't surprise you. What's different is the plumbing: .github/DISCUSSION_TEMPLATE/, one YAML file per category, and a filename that must match the category slug, not bug.yml copied from Issues.
GitHub Container Registry ("GHCR") is GitHub's OCI-compatible container registry at ghcr.io. If your source code, releases, issues, permissions, and automation already live in GitHub, publishing container images to GHCR keeps the distribution path close to the repository that produced the image.
In this post, we'll publish a Docker image two ways: first manually from a local terminal, then automatically from GitHub Actions whenever a GitHub Release is published. Along the way, we'll cover image naming, authentication, permissions, release-driven tags, OCI labels, and the small details that make GHCR feel predictable instead of mysterious.
GHCR differs from a generic public registry when your project is already GitHub-centered:
Images can be associated with a repository.
Repository permissions can be used for package access.
GitHub Actions can publish with the built-in GITHUB_TOKEN.
Images can be public or private.
Tags, labels, and package metadata sit near the release and source history.
The registry supports standard Docker and OCI tooling.
Python packaging has needed a reset for years, and uv is the first tool in a long time that feels like a real one. It's fast, opinionated in the right places, and broad enough to replace an entire pile of Python tooling with a single binary that actually makes the day-to-day workflow simpler.
The official uv docs lead with the claim that it's 10-100x faster than pip, and that number doesn't feel like marketing fluff once you use it for real work. uv gets there by doing something the older Python toolchain never pulled together cleanly: it treats dependency resolution, environment management, Python installation, and tool execution as one system.
