One server. Corporate networking. Controlled egress. An application, a database, ingress, migrations, backups, monitoring, and a deployment path that had to work from staging through production.

This could have become a bespoke server project: install packages, write service units, copy configuration, arrange startup order, add a reverse proxy, improvise database backups, and document which commands an operator must remember.

Instead, years of infrastructure work collapsed into one small k3s installation and a set of Terraform compositions.

That result is why I pride myself on running the things I build. I do not consider an application complete when it works on my laptop or when a container image exists. I want to understand how it starts, how it receives configuration, how it migrates data, how it recovers, and how another person can reproduce the deployment without borrowing my memory.

The deployment was unique; most pieces were not

I did not arrive with a ready-made “Plantronic platform.” I arrived with a portfolio of smaller, declarative parts developed across earlier work.

My public Terraform Modules repository contains modules for web workloads, PostgreSQL, GitLab Agent, monitoring, ingress, cloud resources, secrets, jobs, and related infrastructure. One day before the Plantronic deployment milestone, I committed the initial reusable Kubernetes modules that the project composed.

Plantronic selected and connected those pieces:

• a containerized Phoenix application;
• an explicit migration step;
• a Kubernetes Deployment and Service;
• ingress and TLS integration;
• PostgreSQL with persistent storage;
• scheduled logical backups and retention;
• GitLab Agent for controlled deployment access;
• monitoring and adjacent operational services.

None of these modules was remarkable alone. Their value came from combining them without removing their boundaries.

That is the compounding effect I care about. Knowledge does not compound merely because I remember how I solved a problem before. It compounds when the old solution has a stable interface, remains readable, and can participate in a new system without being copied into it.

Why one server still became a Kubernetes cluster

A single-node Kubernetes installation sounds contradictory to some people. Kubernetes is associated with fleets, autoscaling, and highly available control planes. Plantronic had one machine. Why place a cluster API between the application and Systemd?

Because node count was not the problem I wanted Kubernetes to solve.

I wanted a consistent application runtime and a declarative workload model. I wanted an image, configuration, secrets, migrations, services, jobs, ingress, health behavior, and rollout state to be described with the same primitives in staging and production. I wanted GitLab to interact with the deployment without exposing a raw cluster endpoint through the client’s firewall.

k3s packages the Kubernetes control plane and required runtime components for smaller environments. On one server it remains one failure domain, but it gives me the Kubernetes API and controllers without pretending that I am operating a large managed cluster.

That distinction matters:

• supervision: yes, failed workloads can restart and declared state can be reconciled;
• repeatability: yes, the same resources can be created again;
• host-level high availability: no, one broken server is still one broken server;
• durability: only as good as storage, backups, restore procedures, and host recovery.

I chose single-node k3s for operational consistency, not for an imaginary availability claim.

Systemd is not the loser

The strongest counterproposal is good: build an Elixir release, run it under Systemd, run PostgreSQL as a host service, and keep the deployment small.

Systemd is an excellent process supervisor. It has restart policies, dependency ordering, timers, socket activation, credentials, resource controls, and extensive execution sandboxing. Podman Quadlet offers an appealing middle ground by declaring containers as Systemd-managed units.

Docker Compose in production is another reasonable middle path when the stack is co-located and its lifecycle remains small. It preserves container images and a multi-service declaration without adding a Kubernetes control plane. I prefer admitting when that is enough instead of turning Kubernetes experience into a requirement.

For one application process and one host, I would seriously consider one of those designs. Kubernetes would add an API server, certificates, networking, storage abstractions, controllers, and upgrade work without automatically producing value.

Plantronic crossed my threshold because it was not one process:

• application release;
• migration lifecycle;
• database and persistent storage;
• ingress;
• recurring backup jobs;
• secret and runtime configuration;
• monitoring;
• staging and production workloads;
• remote deployment through a constrained network.

I could model every one of those with Systemd units, scripts, container commands, timers, and proxy configuration. I would then own a Plantronic-specific orchestration system assembled from excellent host primitives.

I already owned the equivalent Kubernetes abstractions as reusable Terraform modules. In my situation, direct Systemd would have been the bespoke choice.

There is another useful truth hiding here: Systemd still supervises k3s. I did not replace it. I moved application orchestration behind a boundary that could remain consistent across hosts and environments. Systemd owns the node service; Kubernetes owns workloads; OTP owns processes inside the Elixir release.

I prefer these nested responsibilities over asking one layer to understand every failure.

Containerizing Elixir without fighting OTP

Elixir already has supervision trees. Kubernetes does not improve a GenServer restart by killing the entire pod, and I do not want it trying.

I divide the responsibilities differently:

• OTP supervises application processes and internal dependencies;
• the Elixir release defines the runnable application artifact;
• the container fixes the OS-level runtime and native dependencies;
• Kubernetes supervises the container and its relationship to services;
• k3s itself remains a Systemd-supervised node service.

Phoenix documents deployment through OTP releases. A controlled build can produce the release, a smaller runtime image can contain it, and runtime configuration can arrive when the container starts. The same image moves through environments; the release tag and configuration identify what actually runs.

For Plantronic, containerization supplied valuable guarantees in an unfamiliar host:

• exact Erlang and Elixir runtime expectations;
• known native libraries;
• explicit listening port and process command;
• reproducible startup behavior;
• one image promoted rather than a host mutated in place.

Database migrations remained an explicit deployment step. I prefer that to hiding schema changes inside normal application startup. The deployment can order migration before the new workload, report failure, and avoid having every replica race to alter the database.

Containerization did not make the BEAM reliable. OTP already did much of that work. It made the boundary around the BEAM release portable.

Twelve-Factor, applied rather than recited

The Twelve-Factor App is sometimes invoked as a cloud slogan. I find it more useful as a set of pressure tests.

Config

Environment-specific values should not be compiled into the release. Kubernetes configuration and secrets let the same image receive the database address, runtime identity, and deployment-specific values at startup.

Backing services

PostgreSQL is attached infrastructure, not a hidden directory inside the application container. That separation makes its persistence, backup, monitoring, and recovery responsibilities explicit.

Build, release, run

The image is the build artifact. A tagged image plus runtime configuration forms a release. Kubernetes runs that release. Terraform describes the desired resources around it.

Processes and disposability

The Phoenix application should start predictably, handle termination, and recover without depending on writable container-local state. Kubernetes can replace the process because durable state lives elsewhere.

Dev/prod parity

I do not need every developer laptop to run a production cluster. I do want staging and production to share image, configuration, migration, service, and job concepts. That parity catches deployment mistakes before production without pretending environments are identical.

None of these factors requires Kubernetes. That is important. Kubernetes was useful because my existing modules already expressed these properties coherently.

Terraform all the way up to the application

I want infrastructure changes to look like code changes: proposed, reviewed, planned, applied, and recorded.

The Plantronic composition referenced reusable modules rather than copying their resources. The application module owned common deployment behavior. The PostgreSQL module owned the database chart and persistence interface. The GitLab Agent module owned its Helm release. Project-level Terraform supplied the choices that were genuinely specific to Plantronic.

This creates two useful levels of change:

1. improve a reusable module when several applications need the same capability;
2. change the Plantronic composition when the requirement belongs only to Plantronic.

That boundary prevents two failures I see often. A giant universal platform makes every application wait for abstractions it does not need. Fully bespoke Terraform makes every project rediscover secrets, rollouts, services, and jobs.

I prefer small modules with boring inputs. Composition is where client context enters.

The initial server bootstrap still established the substrate: operating system preparation, k3s, certificates, registry access, and network integration. I do not want to pretend a few documented host steps are already Infrastructure as Code. My direction is to push stable host knowledge into declarative automation while keeping credentials out of code and state exposure under control.

Above that substrate, application infrastructure belonged in Terraform. No hand-maintained Deployment YAML, no deployment recipe that existed only in shell history.

GitLab Agent across a controlled boundary

Traditional CI deployment often assumes that a runner can reach the Kubernetes API directly. That is uncomfortable in an on-premise network and frequently incompatible with firewall policy.

The GitLab Agent for Kubernetes changes the direction. The cluster-side agent opens a bidirectional channel to GitLab’s agent server, KAS. GitLab documents this as a way to communicate with clusters behind firewall or NAT.

That fit Plantronic’s egress-controlled environment. I could define a narrow outbound path instead of publishing the cluster API for inbound CI traffic. The same Terraform composition installed the Helm release and connected deployment automation to the cluster.

I use “air-gapped” carefully. A truly air-gapped network cannot talk to GitLab.com; no agent changes that fact. It needs mirrored images and artifacts, a reachable self-managed control plane, or a controlled transfer process. k3s documents air-gap installation, which makes the substrate adaptable, but egress-controlled and air-gapped are different operating modes.

I value the architecture because it crosses organizational boundaries cleanly. Client networking can remain restrictive. Deployment can remain automated. The interface between both concerns is explicit.

A practical guide to deciding

I would not recommend single-node k3s merely because a project uses containers. I would ask these questions.

Choose direct Systemd or Quadlet when

• there is one host and only a few processes;
• host-specific integration is desirable;
• the team knows Systemd better than Kubernetes;
• staging/production Kubernetes parity has little value;
• container networking, jobs, secrets, and ingress remain simple;
• no reusable Kubernetes platform already exists.

Consider single-node k3s when

• the application includes several independently managed workloads;
• images and Kubernetes resources already exist elsewhere;
• jobs, migrations, services, ingress, secrets, and health behavior need one declarative model;
• controlled deployment access benefits from an in-cluster agent;
• staging and production should share orchestration primitives;
• the team can operate and upgrade the cluster;
• one host failure domain is acceptable and honestly documented.

In either case

• make backups and test restores;
• keep credentials out of repositories;
• pin and plan runtime upgrades;
• document substrate recovery;
• monitor the host, not only the application;
• define who owns the deployment after handover.

Technology choice cannot compensate for missing operational ownership.

What I bring when I bring infrastructure

The Plantronic deployment did not prove that Kubernetes belongs on every server. It proved something more useful to me: a broad portfolio of composable infrastructure can make an unfamiliar boundary feel familiar without erasing what is different about it.

I brought lessons from cloud orchestration, container builds, Kubernetes resources, Terraform modules, Elixir releases, database operations, and constrained networks. I did not combine them into a private platform that only I could operate. I assembled public, declarative modules into a client-specific composition from staging to production.

That is the compounding effect I want from experience. Every project should leave behind more than memories and copied snippets. It should sharpen a module, an interface, a runbook, or a decision rule that improves the next project.

I pride myself on running what I build because deployment is where architectural claims meet reality. Configuration must arrive. State must survive. Processes must restart. Networks must permit exactly enough. Another person must be able to see what exists.

One server was enough to make all of those concerns concrete. Years of cloud work were what made one server feel small.

I wanted the choice to be a program.

My eventual URL path became:

macOS URL handler → Finicky → JavaScript rule → executable → destination

I like this chain because each arrow leaves me a seam I can understand and replace. macOS owns dispatch. Finicky owns URL parsing and routing policy. A normal executable owns the final effect. In my case, that executable forwards unknown URLs to a browser running outside my work machine.

This is exactly the kind of arrangement I want in dotfiles: visible, scriptable, composable, and replaceable one layer at a time.

Finicky is a programmable default browser

Finicky is an open-source macOS application that registers as the default browser. It does not need to render pages. It receives a URL, loads ~/.finicky.js, evaluates matching and rewrite rules, then opens the selected browser or application.

A basic configuration can route work domains to one browser and personal domains to another:

module.exports = {
  defaultBrowser: "Safari",
  handlers: [
    {
      match: finicky.matchHostnames(["github.com", "gitlab.com"]),
      browser: "Firefox",
    },
  ],
};

The JavaScript configuration is the attraction. Rules can be functions. URLs can be rewritten. Hostnames can be matched through Finicky’s parsed representation instead of fragile string slicing. The file can live beside shell functions, editor configuration, and the rest of my workstation policy.

I could have used a GUI router, and that would have been easier to start with. I know myself well enough to know where that ends: sooner or later I want to review a rule in Git, generate part of it, share it between machines, or make the destination something other than an installed browser.

I did not want another browser destination

My unknown-link policy required a command called SafeBrowser. Finicky should select it just as it selected Safari, then pass the URL as one argument.

At the beginning of 2025, the version I was using modeled destinations as application names, bundle identifiers, or application paths. That was sensible for a browser picker. It stopped one layer short of the composition I wanted.

So I forked Finicky at Overbryd/finicky and added a command application type. The public implementation commit is e380acbf01c….

The configuration schema gained appType: "command" and a command path. The native side carried that option into its browser descriptor. When selected, Finicky constructed an argument array containing the executable path and URL.

One implementation detail mattered enough to me not to compromise on it: the URL must remain data. The implementation does not produce one shell string such as:

/Users/me/.bin/safebrowser "${url}"

It uses Process, invokes /usr/bin/env, and supplies the command and URL as separate arguments. Shell metacharacters inside an attacker-controlled URL do not become shell syntax. My configuration also uses an absolute executable path, avoiding a PATH lookup for the security boundary.

I treat a command destination as privileged configuration. Whoever can modify .finicky.js or the target executable can redirect every external link or run code whenever one opens. I therefore keep both files under my ownership and out of reach of less-trusted processes.

Default to the script

The resulting configuration reverses the usual browser-router pattern. Instead of making Safari the default and adding special cases, I make SafeBrowser the default and add narrow local exceptions:

module.exports = {
  defaultBrowser: {
    name: "SafeBrowser",
    appType: "command",
    command: "/Users/me/.bin/safebrowser",
  },
  handlers: [
    {
      match: finicky.matchHostnames([
        /.*\.?github\.com$/,
        /.*\.?example-work-service\.com$/,
      ]),
      browser: "Safari",
    },
  ],
};

I like the failure direction of this policy. A new domain does not accidentally open in my work browser because I forgot to classify it. My omission produces less trust, not more: the URL follows the unknown route.

I review these rules as if the input were trying to fool them—because sometimes it is. I anchor patterns and match parsed hostnames rather than searching arbitrary strings. A rule matching github.com anywhere in the full URL could be fooled by a hostname such as github.com.attacker.example or by placing the trusted text in a query parameter.

I also keep the allowlist small. If my configuration contains half the internet, then I have not written a trust policy; I have built an unmaintainable alternate browser history.

The script is an adapter

SafeBrowser is deliberately ignorant of Finicky. It accepts one URL and arranges for another machine to open it:

#!/usr/bin/osascript

on run argv
  set remoteMachine to first item of ¬
    (read (POSIX path of (path to home folder as string) & ¬
    ".config/vm1.local/eppc") using delimiter "\n")

  tell application "Finder" of machine remoteMachine ¬
    to open location (item 1 of argv)
end run

The destination address lives outside the public dotfiles. The script uses Remote Apple Events to tell Finder in a macOS browser VM to open the URL.

I like this adapter because no layer knows too much:

• Finicky does not know how the VM is reached.
• SafeBrowser does not know why this URL was selected.
• the VM does not need Finicky installed;
• macOS does not need to know that its “default browser” is a policy engine.

I can replace Apple Events with SSH without rewriting matching rules. I can replace the VM while keeping the script’s one-URL contract. I can test the script directly from a terminal. I can point one rule at a different command for a temporary experiment.

I prefer composition over tight vertical integration. It lets me defer decisions, replace one layer, and hack on a new transport whenever I want. If a group of these pieces eventually stands the test of time, I can still compress them into one vertically integrated application, bundle it, and package it. I prefer that compression to be the last step, earned by experience, rather than the first architectural decision.

A URL is an argument, not a command

Arbitrary command support introduces a sharp edge, so the contract should stay narrow:

input: exactly one absolute http or https URL
output: destination receives that URL, or the command fails visibly

For my adapter, I want a deliberately unforgiving contract. It should reject missing arguments, extra arguments, unsupported schemes, unreasonable size, and invalid URL syntax. I do not want it logging query strings because they may contain tokens or recipient identifiers. I want a timeout when contacting another machine and a non-zero status when delivery fails.

My hard line is that the adapter must never interpolate the URL into shell source. This applies locally and across SSH. The following shape is dangerous:

ssh browser-vm "open '$url'"

Quoting untrusted data across two shell parsers is easy to get wrong. A forced remote command reading an encoded value from standard input, or a small protocol that keeps data separate from command text, is safer.

The AppleScript version also needs operational hardening. Remote Apple Events credentials are sensitive. Network access to the guest should be restricted. Failure must not silently fall back to opening the URL locally, because that would erase the policy exactly when isolation is unavailable.

Configuration as code is the real feature

The important part of this setup is not JavaScript as a language. It is that the routing decision is text I own.

A dotfiles-native policy gives me:

• history — I can see when a domain became locally trusted;
• review — a broad regular expression appears as a diff;
• reproduction — a new Mac receives the same handler and scripts;
• composition — rules can target browsers, profiles, applications, or commands;
• rollback — a broken policy is one Git operation away from its prior state;
• portability — the command behind a rule can evolve independently.

It also removes mystery. When a link opens in the wrong place, I inspect one rule file and one executable. I do not search preference panes, browser extensions, and remembered prompt choices.

I do not mistake configuration as code for automatic security. Finicky executes JavaScript, so my config is executable policy. My regexes can be wrong. My script can leak URLs. My public dotfiles can expose private hostnames or machine details. What I gain is not perfection; I gain the ability to inspect, review, and correct those risks.

Test the whole chain

I do not consider a URL router finished after clicking one familiar link and watching the right browser open. I want examples for each decision:

• an exact allowlisted hostname;
• a legitimate subdomain;
• a deceptive suffix such as trusted.example.attacker.invalid;
• an unknown HTTPS domain;
• plain HTTP;
• a URL with spaces or encoded characters;
• a query string containing shell metacharacters;
• a URL shortener;
• a non-web scheme;
• an unavailable browser VM.

The expected destination should be explicit for each case. Testing only the JavaScript match misses command dispatch. Testing only the script misses policy errors. The useful test crosses the same boundary as a real click.

I also want failure to remain safe. If Finicky cannot load its configuration or SafeBrowser cannot reach the guest, the result should be a visible failure—not an automatic local-browser fallback.

Keep the layers boring

“URL handler to Finicky to a script” sounds more complicated than choosing Safari in System Settings. Internally, each layer is simpler than a monolithic tool that parses URLs, manages every destination, authenticates to a VM, and opens a remote browser itself.

macOS already knows how to dispatch URLs. Finicky is good at programmable routing. A script is good at adapting one selected URL to a local environment. The guest is good at containing a browser.

That division is why the setup feels hacker-friendly rather than merely clever. Every piece has a small interface. Every policy lives in a file. Every implementation can be replaced with another command.

Finicky gave me control of the decision. My command extension kept the destination open-ended. Putting both pieces in public dotfiles made the setup durable without pretending it had reached its final form—and that is exactly how I prefer my tools.

That last change is the one I keep wondering about. Why is everyone who takes workstation hardening seriously not also taking ownership of URL handling?

Think about how many incursions begin on a work computer. A message arrives. It contains a link. The domain looks plausible, the sender appears familiar, or the subject creates just enough urgency. One click transfers an attacker-controlled string through the operating system into a large, networked application containing authenticated sessions, saved permissions, extensions, downloads, and access to local files.

MITRE ATT&CK calls this User Execution through a Malicious Link. A related path, Drive-by Compromise, begins when a browser visits an attacker-controlled or compromised website. CISA’s phishing guidance treats the link as a central initial-access mechanism.

For years, that path nagged me. In February, I finally dealt with it at the point before a browser opens: OS-level URL handling.

A click is a dispatch decision

On macOS, applications hand URLs to the operating system. Launch Services resolves the registered handler for a scheme such as http or https, then delivers the URL to that application. Normally, the handler is Safari, Firefox, Chrome, or another browser.

That default optimizes for convenience. It assumes that every link arriving from Mail, Messages, Slack, a terminal, a PDF reader, or a password manager should immediately enter the same browser environment.

My browser is not an empty document viewer. It carries work sessions. It can reach administration panels, source hosts, cloud consoles, invoicing, internal tools, and identity providers. Even with MFA, a live browser session represents authority. Sending every unknown URL directly into that context is an unnecessary default.

I consider the OS-level handoff a trust boundary. Before dispatch, the URL is data. After dispatch, a browser begins resolving, connecting, parsing, rendering, and possibly downloading. I want my own policy between those states instead of accepting one global browser choice as permanent.

One important limit: this boundary governs links handed to macOS. It does not intercept every navigation after I am already inside a browser. A malicious page opened from an allowlisted local page can still navigate elsewhere. URL brokering reduces one exposure path; it does not turn the browser into a safe viewer.

What can go wrong after default dispatch

A routing layer cannot know whether a page is benign. It can still reduce several kinds of risk.

Phishing meets an authenticated session

The most common danger is not a browser sandbox escape. It is a convincing login page, consent screen, OAuth flow, or support prompt opened in exactly the environment where I normally authenticate.

Separating unknown links from my work browser removes familiar cookies and active sessions from the first interaction. The isolation browser can still be phished, but it begins with less authority. A fake page also looks less natural when it appears in a deliberately untrusted environment.

Browsers process hostile input

A URL can lead to exploit code, a compromised legitimate site, malicious advertising, or a download crafted for the next stage of an attack. Modern browsers have strong sandboxes, and macOS adds quarantine, Gatekeeper, and notarization checks. None of these controls is a reason to place the browser next to every valuable host resource if I can avoid it.

Moving unknown browsing into a VM adds another containment boundary. A browser compromise must then escape both browser and guest—or abuse an integration channel—before reaching the work host.

Links can cross application boundaries

Web pages and messages may point to non-web schemes that launch other applications. URL-scheme handling has a long history of surprising behavior because the receiving app decides what the payload means.

A broker can reject schemes it does not expect and ensure that its fallback only forwards http and https. This does not secure every registered macOS handler; it narrows what this particular path accepts.

The URL itself leaks information

Tracking parameters can identify the recipient, campaign, account, or document. Some routing tools can remove known parameters or rewrite hosts before opening. That is primarily privacy hardening, but less unnecessary context reaching a remote server is also useful security hygiene.

Profiles collapse trust zones

Personal browsing, client systems, development tools, and privileged administration do not need the same browser profile. Routing known domains into deliberate profiles reduces accidental credential use and keeps extensions, cookies, and history from becoming one large trust zone.

What a URL broker can—and cannot—prevent

A broker can block an unexpected scheme, prompt before dispatch, rewrite a URL, route a known domain to a specific browser profile, or send everything unknown to an isolated machine. It replaces one global default with an explicit policy.

It cannot inspect a page and declare it safe. It cannot guarantee an allowlisted domain has not been compromised. It cannot stop a phishing link clicked from inside an already-open browser. It cannot compensate for an unpatched browser, weak identity controls, or a VM configured with broad host access.

The claim I am comfortable making is smaller: taking ownership of URL dispatch can reduce my exposure and the possible blast radius. More importantly for me, it turns “open every link here” from an ambient assumption into a decision I can inspect and change.

The macOS URL-router landscape

There are many browser pickers and routers. This is the credible landscape I found while revisiting the setup, not a claim that no small utility exists outside the list.

I also found smaller open-source implementations including Bowzer, multi_browse, Punt, LinkGate, and Usher. Their maturity, maintenance, and licensing vary. Browser routers are popular small projects; evaluate the code that will receive every external URL on your machine.

I could have stopped at a graphical picker if I only wanted to choose between browsers. I wanted the policy in my dotfiles, and I wanted an arbitrary command to be a valid destination. Finicky gave me the useful base without forcing the final shape of the solution.

My policy: known local, unknown elsewhere

I made Finicky the default http and https handler. Its rules send a small set of expected work destinations to local Safari. The default route does the opposite of a normal browser configuration: everything not explicitly matched goes to SafeBrowser.

A simplified version looks like this:

module.exports = {
  defaultBrowser: {
    name: "SafeBrowser",
    appType: "command",
    command: "/Users/me/.bin/safebrowser",
  },
  handlers: [
    {
      match: finicky.matchHostnames([
        /.*\.?github\.com$/,
        /.*\.?example-work-service\.com$/,
      ]),
      browser: "Safari",
    },
  ],
};

I care more about the default than the allowlist. New and misspelled domains should not silently inherit local trust just because I have not classified them yet. I prefer them to leave the host until I deliberately add a rule.

I do not trust loose hostname matching here. A substring test for github.com could also match github.com.attacker.example. Finicky parses the URL and provides hostname matchers, but I still anchor and review my patterns. Internationalized domains, redirects, URL shorteners, and compromised subdomains are why I never want a matching hostname to become synonymous with safety.

Do not run the untrusted browser on the work machine

I considered a separate local browser profile, and for many workflows that may be enough. It still shares the kernel, filesystem permissions, browser installation, and many host integrations. For unknown links, I prefer paying the extra operational cost of a VM in exchange for a stronger boundary.

My fallback browser runs on another macOS machine represented as a VM endpoint. SafeBrowser is a short AppleScript executable:

#!/usr/bin/osascript

on run argv
  set remoteMachine to first item of ¬
    (read (POSIX path of (path to home folder as string) & ¬
    ".config/vm1.local/eppc") using delimiter "\n")

  tell application "Finder" of machine remoteMachine ¬
    to open location (item 1 of argv)
end run

The script reads the Remote Apple Events address from a private file and asks Finder in the guest to open the URL. The address and credentials do not belong in dotfiles or logs.

There are other ways to deliver a URL to a browser VM:

• SSH with a forced guest command that validates one URL argument and calls open or xdg-open;
• an authenticated listener on a host-only network;
• a one-way queue consumed by the guest;
• a hypervisor guest-control command.

If I replaced Remote Apple Events today, I would probably begin with SSH because it is portable and already understood. I would not construct ssh guest "open $url" and let an attacker-controlled URL become shell text. I would pass encoded data or a separate argument into a narrowly constrained command, validate the scheme and length, and avoid a general-purpose remote shell key.

I am willing to sacrifice convenience to preserve this boundary. Shared clipboard, drag-and-drop, mounted host directories, saved work credentials, broad Remote Apple Events access, and guest-control tools all create paths back toward the host. I disable what the browser does not need, keep the guest patched, and prefer snapshots or disposable instances when practical. I treat the host-to-guest opener as security-sensitive software, not harmless desktop glue.

The practical hardening checklist

My implementation is small, but its policy is explicit:

1. Register a broker—not a browser—as the macOS handler for http and https.
2. Keep local routing rules narrow and anchored to parsed hostnames.
3. Make the unknown case the isolated case.
4. Accept only intended schemes at the forwarding boundary.
5. Pass URLs as arguments, never interpolated shell code.
6. Keep router configuration and scripts versioned in dotfiles.
7. Protect the router config, executable, and remote-control credentials from untrusted writes.
8. Remove VM integrations that contradict the isolation goal.
9. Do not place valuable authenticated sessions in the untrusted browser.
10. Test known, unknown, malformed, shortened, and non-HTTP URLs.

There is still judgment in the allowlist. A locally opened service can link to the rest of the web. A trusted domain can be compromised. The configuration is a reduction of implicit trust, not a declaration that certain hostnames are permanently harmless.

Take ownership before the browser starts

The security industry spends enormous effort hardening browsers after they receive a URL. That work is essential. I had paid far less attention to the decision that sends a URL into a particular browser in the first place.

Making Finicky the OS handler gave me a policy point. Adding a script destination let that policy cross the machine boundary. Running unknown links in a VM kept routine convenience while moving hostile parsing and low-trust sessions away from my work environment.

A link is not harmless because it is small enough to fit in a message. It is an instruction to begin a network interaction in some security context. The operating system already asks which application should receive that instruction. I would rather answer with code than with one global default I stopped questioning years ago.

The earliest visible milestone in 2025 is almost comically small: references in the project wiki changed from an earlier working name to Plantronic. No scheduler became faster. No factory data was imported. No user got a new screen. Yet the rename marked an important transition.

The name was chosen by the client’s project manager, not invented by the software team as a branding exercise. It survived all the way into production and rallied dozens of early adopters behind one recognizable initiative.

A client project often begins as “the tool for this team” or “the new version of that spreadsheet.” Those names are convenient while a problem is still local. They become restrictive once the software starts connecting planning, people, process steps, imports, permissions, and reporting.

A proper name creates a boundary. Plantronic was not the factory, the source system, or a single planning view. It was the application responsible for turning several kinds of operational information into an inspectable planning process.

A working title is already teaching the organization

Introducing software into an organization starts long before production. The name appears in meetings, invitations, tickets, demonstrations, documentation, support requests, and conversations between future users. Every repetition teaches people what the thing is and where it belongs.

That is why I hate working titles that do not make it to production. A working title does not remain an innocent placeholder once people begin using it. It builds a shared mental model. Changing it later means more than renaming modules and links: the organization must unlearn one identity while learning another. For a while, both names coexist, and every conversation must spend time establishing whether everyone is still talking about the same thing.

There are exceptions. A small discovery group may need a disposable label, and confidential work may require a code name. But once a project is introduced to the people expected to adopt, operate, or explain it, the name should be treated as durable.

Plantronic demonstrated the benefit. When someone used the name, there was never doubt about where the project was heading or who should communicate with whom about what. The name gave everyone a stable point of reference while the software itself was still taking shape. It helped materialize an idea into an organizational reality.

Names become architecture

A name alone cannot rescue a muddled design. It can, however, make muddle easier to see.

Once the application had its own identity, questions became sharper:

• Which concepts belong inside Plantronic?
• Which facts remain owned by external systems?
• Which changes are planning decisions rather than imported truth?
• Which reports explain Plantronic’s state, and which merely repeat source data?

Those questions appeared repeatedly during implementation. Task routing, team workloads, process transitions, SAP-facing imports, public views, and reporting all needed boundaries. The project name became shorthand for one side of those boundaries.

This matters especially in consulting work. A code name borrowed from a customer or an existing system quietly encourages accidental coupling. Developers reproduce vocabulary and assumptions without deciding whether they belong in the new product. A distinct name gives the team permission to model the problem deliberately.

Rename while it is still cheap

Renaming later is expensive. The old term spreads into repositories, modules, database identifiers, deployment scripts, documentation, and conversation. Even when a technical rename is possible, the mental model lingers. The social migration is usually larger than the code diff.

January 2025 was early enough. The wiki change preceded most implementation milestones and happened before broad adoption hardened the earlier label. From then on, Plantronic remained Plantronic—from the first adopters to production.

Looking back after the project was completed, I like that its history begins this way. Long projects are remembered through large releases and difficult migrations, but their direction is often set by smaller acts of clarification. Giving the child a name was one of them.

[push]
    autoSetupRemote = true

It removed a small interruption that I had accepted for far too long.

Whenever I created a local branch and pushed it for the first time, Git used to stop and tell me that the branch had no upstream. It also printed the command I was expected to run:

git push --set-upstream origin my-branch

The message was helpful. The repetition was not. Nearly every time, I wanted exactly what Git suggested: publish this branch to my normal remote under the same name, then track it.

Furthermore, it should have also suggested the configuration to adapt the default behavior, rather than the quick fix.

With push.autoSetupRemote enabled, the first plain git push does that setup automatically. Later pushes work as before. This is not an alias wrapping Git and it does not invent a new workflow. It tells Git that, when no upstream exists, my usual intent is obvious enough to act on.

Convention over configuration, configuration over repetition

I am careful about convenience settings that hide meaningful state. Remotes matter. Tracking relationships matter. A push can publish work. I still want to know which repository I am changing.

But typing --set-upstream origin was not making me reconsider any of those things. In repositories with one conventional remote, it was ceremony after the decision had already been made.

That distinction is useful beyond Git. Automate repeated mechanics, not unresolved choices. If I regularly worked with several equally plausible push remotes, I would leave this setting off. Git stopping would then protect a real decision.

In my normal repositories, there is one clear remote and matching branch names are intentional. For me, it is rather the exception to work with multiple remotes.

As we were chatting, he revealed his intentions to become a freelancer to better battle the overhours and pay he was getting from the startup he is working on.

I ended up writing a couple of elaborate answers, here is what I think.

The core to my answers was, that I certainly think that freelancing can give you a good position to negotiate on time and money. And you have to exercise that position, otherwise you end up in a situation that neither you want, nor any client can be happy with.

I see this tightly coupled with some of my best strenghts, that I can bring to any project and differentiate me from others. The most obvious being, my very high level of motivation.

Lets ponder over this a little bit deeper.

The time I have in my life, is my most precious resource. If everything goes well, I think I can do about 80 years. And I choose to live in a society and contribute to it, so work is naturally something that I want to spend time with.

So look at your day, your week and see what portion of time is spent working. I can tell you exactly how much time I have spent working productively, because I meticulously keep track of time. This is due to the fact, that I work based on an hourly rate.

My time entries are exact down to the minute. In an overview, and I can proudly show you weeks I logged 50+ hours. I can also show you, with the same pride, weeks with < 15 work hours or less, even over a couple of months.

There are times, I see myself in need, the project can make use of my skills and I am motivated to be working on it. I will happily contribute my time, skill and motivation.

But I am equally content with times where I can spend most of the day playing with my children, reading books and doing ‘nothing’. ‘Nothing productive’.

So, over the course of the years, I became accustomed to this low- and high tide way of working.

There is a strong relation between these intense, fast and long work sessions and doing nothing. For me, one cannot exist without the other.

I thrive in critical situations, facing challenging problems. And if I can honestly take a challenge, my whole body and mind are supporting me for the cause. Over the years, I have learned how much energy I can tap into for my work. And with the right amount of downtime, this is a hell lot of energy.

People see me doing 14+ hours a day, three times a week, and for the naive bystander it looks like I am working crazy hard. In reality, I am just very aware of how much of my time I can use for work, and when I need a break.

I need a strong position to negotiate about my own time. I can not, and will not let a company, client or who-ever I am working with dictate how much time I can spend on a cause that I trade my time against money.

Here you have one of my main reasons, I choose to be a freelancer over being an employee.

Conclusion

If you are in a position that someone is ‘using’ you, or sometimes you could even say ‘abusing’ you. Make up your mind, and start deciding for yourself.

• How much of your time are you willing to invest for some other cause than your own?

• How much can you give sustainably, without taking a risk or damaging your health?

• What is really driving your motivation? What do you, expect from yourself at work?

Leave a comment, and subscribe if you like what I am writing about freelancing.

Now I have completely reset my content pipeline. New static site generator. New repository layout. New template.

I have a repository overbryd.github.io. Its first commit dates back to Feb 27, 2009.

I have a number of articles in my pipeline, all waiting to get deployed. Since I started my career, I am now at my 3rd programming language, that I use professionally and have applications running in production.

First, since I am a hacker by heart, I am going to dissect every bit and piece of my new content pipeline, along the way.

Lean back, subscribe, and dive right into my world. I really hope you can enjoy reading my blog.

We are now at 50a875be3eac870121c72c3e0951d8c8257db1fc Initializing master branch for publication.

So much to do, so much to write.

Say you need to consume events and act upon them. There are numerous services that fit this pattern. A recent client of mine wanted just that. In this case it was an API connector, subscribing on events from AMQP, mapping the data to the target API structure and posting to it.

Given the projects deadline and budget, I was tempted to be a little more defensive and have proper errors explaining when things go wrong. Besides full test coverage, of course.

I found Elixir Flow handling that just perfectly well.

The flow must go on

Most of the examples building Elixir flows deal with the ad-hoc/scripting/console usage of Flow. By using Flow.from_enumerable/1 you hook up a flow to some sort of enumerable and with Enum.into/2 you can easily build a nice parallel processing engine.

Taking this a step further, as a forever running application, Flow.from_stage/1 and Flow.start_link are the way to go.

Here is a showcase of the processing pipeline module:

defmodule Pipeline do

  def start_link() do
    pipeline = Flow.from_stage(Pipeline.Dispatcher, max_demand: 100, stages: 10)
               |> flow
    Flow.start_link(pipeline, name: __MODULE__)
  end

  def flow(input) do
    input
    |> put(:item, &Poison.decode/1)
    |> put(:transformed, &transform/1)
    |> put(:response, &post/1)
    |> Flow.each(&report/1)
  end

  def transform(%{item: item}) do
    # returns {:ok, transformed} or {:error, ...}
    TargetApi.object_from_item(item)
  end
  
  def post(%{transformed: object}) do
    # also returns {:ok, ...} or {:error, ...}
    TargetApi.post(object)
  end
  
  def report({:ok, _state}), do: Logger.info("posted successfully")
  
  def report({:error, key, error, state}) do
    Logger.error("processing errored at #{key}: #{inspect error}, #{inspect state}")
  end
  
  defp put(flow, key, fun) do
    Flow.map(flow, fn
      {:ok, state} ->
        case fun.(state) do
          {:ok, result} -> {:ok, Map.put(state, key, result)}
          error -> {:error, key, error, state}
        end
      pass -> pass
    end)
  end

end

I hope you get the idea. There are two nice benefits coming out of this:

1. Testability
2. Error handling

Testability

By having the input of the flow construction as an argument, the flow can be isolated in tests. There is no need to hook up or startup the Pipeline.Dispatcher GenStage. I use Flow.from_enumerable/1 in my tests to provide input, and I append Enum.into/2 to receive output from the pipeline.

My tests look like this:

defmodule PipelineTest do

  test "flow fails when provided invalid JSON" do
    assert {:error, :item, _error, _state} = run("not json")
  end

  def run(data) do
    [{:ok, data}]
    |> Flow.from_enumerable
    |> Pipeline.flow
    |> Enum.into([])
    |> List.first
  end
  
end

And since the pipeline itself mostly calls into other modules, most of the logic is already tested in the respective tests of these modules. And as long as these functions adhere to the :ok/:error tagged returns, the pipeline will deliver. More about that in the next section about error handling.

Error handling

Looking at this flow, it acts as one state transformation. Each result is put in its own key, and can provide input for further actions. This also acts as the protocol between functions that depend on the output of the previous. The return values can clearly being looked up. Errors can clearly be tracked back to where they occured.

But first, a small fundamental discussion about Elixir error handling. It is quite a complex topic, mostly due to the fact that there are so many different ways to handle errors in Elixir. First there is the let-it-crash mentality. Processes isolate the execution, and they stay unaffected by errors from other processes. Then there is the very common :ok/:error construct, tagged return values that indicate whether the called function succeeded in its execution.

Over the course of Elixir development, you will have to pick and choose between them, or mix and match what is best for the users of your application. In this case, my users are of two different kinds.

The first kind is the end user of the application, who should be affected the least by any malfunction. This user will never see any error output, since the whole pipeline is attached to a notification system that triggers events after he has interacted with the front-facing application. Worst case, this user will just never receive the intended consequences of his interaction.

The second kind are the developers of the front facing application. They are maintaining the application the user is interacting with, they are the ones responsible if something along the way fails and the principal users do not get what they want.

So thought mainly about the latter, the developers. I want them to quickly reason about any potential failures that might occur during processing.

I choose to implement :ok/:error for everything that I expect to fail. The main promise there is to quickly get to know what went wrong how.

The second is, that severe crashes happen under supervision, and basic process isolation takes care of keeping the application running and restarts its parts. This good for any unforeseen errors.

Dispatcher

The ever running input provided to the pipeline is a queueing GenStage dispatching on demand. In this case the AMQP consumer forwards incoming events to the Dispatcher like this:

Dispatcher.async_push(Pipeline.Dispatcher, {:ok, data})

For completeness sake, here is the implementation of a queueing GenStage producer, dispatching on demand:

defmodule Dispatcher do
  use GenStage

  def start_link(name) do
    GenStage.start_link(__MODULE__, nil, name: name, id: name)
  end

  def init(_) do
    {:producer, {Queue.new, 0}, dispatcher: GenStage.DemandDispatcher}
  end

  def async_push(name, event) do
    GenStage.cast(name, {:push, event})
  end

  def queue_size(name) do
    GenStage.call(name, :queue_size)
  end

  def handle_call(:queue_size, _from, {queue, _demand} = state) do
    {:reply, Queue.size(queue), [], state}
  end

  def handle_cast({:push, event}, {queue, demand}) do
    dispatch_events(Queue.put_front(queue, event), demand, [])
  end

  def handle_demand(incoming_demand, {queue, demand}) when incoming_demand > 0 do
    dispatch_events(queue, demand + incoming_demand, [])
  end

  defp dispatch_events(queue, demand, events) do
    with true <- demand > 0,
      {event, remaining_queue} <- Queue.pop(queue)
    do
      dispatch_events(remaining_queue, demand - 1, [event | events])
    else
      _ -> {:noreply, Enum.reverse(events), {queue, demand}}
    end
  end

end

1. Implement a handler that has @behaviour :elli_handler

   This is your router/controller. A bare minimum example version of this looks like this:

    # lib/elli_handler.ex
    defmodule ElliHandler do
      @behaviour :elli_handler
      alias :elli_request, as: Request
       
      def handle(req, args) do
        handle(Request.method(req), Request.path(req), req, args)
      end
       
      def handle(:GET, _, req, args) do
        # do something with the request.
        # e.g. you can use Request.get_arg/2 to fetch a query param
        say = Request.get_arg("say", req)
        # Return a tuple with 3 elements
        # status code, list of header tuples, response body
        {200, [], "echo, #{say}"}
      end
       
      # Here you can react to all kinds of events of the full connection/request/response cycle
      # You must implement this, otherwise elli wont function properly, as it evaluates
      # the return value of handle_event/3.
      def handle_event(event, args, config) do
        # Here would be a good point to handle logging.
        # IO.inspect([event, args, config])
        :ok
      end
       
    end
   

2. Lets use an app that starts an elli supervisor

    # lib/elli_supervisor.ex
    defmodule ElliSupervisor do
      use Supervisor
   
      def start_link(ref, options) do
        Supervisor.start_link(__MODULE__, options, name: ref)
      end
   
      def init(options) do
        children = [
          worker(:elli, [options], id: :elli_http_server)
        ]
        supervise(children, strategy: :one_for_one)
      end
   
      def shutdown(ref) do
        case Supervisor.terminate_child(ref, :elli_http_server) do
          :ok -> Supervisor.delete_child(ref, :elli_http_server)
          err -> err
        end
      end
    end
   
    # lib/app.ex
    defmodule App do
      use Application
   
      def start(_type, _args) do
        import Supervisor.Spec, warn: false
        # lets start our elli supervisor, setting its options
        # callback should be set to the elli handler that implements the elli_handler behaviour
        # port will be the port elli is listening on, defaults to 8080
        ElliSupervisor.start_link(__MODULE__, callback: ElliHandler, port: 3000)
      end
   
    end
   
    # in mix.exs
    def application do
      [
        mod: {App, []}
      ]
    end
   

3. Add elli as a dependency to your mix.exs

   Run mix get.deps to install your dependencies. Start your server with mix run --no-halt or in a console using iex -S mix.

    # in mix.exs
    defp deps do
      [
        # elli is our web server layer
        {:elli, github: "knutin/elli"}
      ]
    end
   

… Ballpark would marry mite. These two fabulous web apps would get along perfectly!

I don’t want to ask too much, and I know the feature I’m requesting may fall out of the 80 % category of what the majority wants. But please, dear Ballpark team, consider it. Maybe in a stand up meeting right now!

I think this is actually a business opportunity on both sides.
There would be more potentially interested clients. (Don’t ask me numbers, I don’t run these apps – ask @mite or @metalab.)

For more information about each app, here are the links to their tours:

→ ”Fast input, powerful output: mite lets you track your time in a structured way. Advanced reporting helps you and your team to stay on top of your daily business.”

→ ”Using Ballpark is going to be your daily bottom of the ninth, full count, walk-off home run moment of invoice zen.”

Managing both without pain

It is a lot of work to write invoices or estimates. I do this by hand for about a year now. But the more I think about the process, the more I get the feeling it can be done with less effort.
At the end of each month, I sit down and get this quirky process started:

1. Download the reports for every project of the last month from mite as a PDF.
2. Get the total and write it in the blank with Pages
3. Get the full address of the client and fill it in the blank
4. Save the edited blank as the new invoice
5. Launch Adobe Acrobat
6. Combine those PDFs into one.
7. Send the combined PDF per E-Mail to the client with a few nice words.

This scenario could be cut down:

1. Create a new invoice for the client on my ballpark account.
2. Select the client’s project with all time entries from last month.
3. Add a few nice words and send the invoice to the client via ballpark.

The design outline

References for development

• mite. API documentation
• mite-rb ruby API implementation