Config Drift Is the Quiet Way Your Self-Hosted Agent Breaks

A self-hosted agent rarely dies in a blaze. It drifts. A model alias gets swapped during a late-night experiment. A cron line gets commented out “just for today.” An environment variable gets renamed in one file and not the other. Nothing crashes. The agent just gets a little worse, then a little worse again, and a week later you are debugging behavior instead of a bug.

The fix is not a smarter agent. It is a boring habit: snapshot the things that define behavior, diff them every day, and read the diff.

Why drift beats bugs

A bug has a stack trace. Drift has a vibe. “It used to answer faster.” “It stopped posting on Tuesdays.” “Costs look higher.” By the time you notice, the change that caused it is buried under a dozen others, and your memory of what you touched is unreliable.

Three things make drift especially common on a home server or Pi:

• You are the only operator. No review, no change ticket, no teammate who says “wait, why did you do that?”
• Config lives in many places. A main config file, an env file, crontab, systemd units, shell rc files, and per-agent workspace instructions all shape behavior.
• Fixes are made under pressure. The 11 p.m. hotfix never gets written down because it worked.

If you cannot answer “what changed since it last worked?” in under two minutes, you have a drift problem whether or not you have noticed yet.

What to snapshot

Snapshot anything that changes behavior without changing code. Start with this list and trim it to your setup:

1. The main agent config. Models, routing, channel bindings, tool permissions.
2. The crontab and systemd timers. Schedules are behavior.
3. Environment variable names, not values. You want to know a key appeared or vanished. You do not want secrets in a diff file.
4. Systemd unit files for the gateway and any helper services.
5. Agent instruction files such as the persona and operating rules each agent loads at startup.
6. Installed package and runtime versions. Node, Python, the agent runtime itself.

Notice what is missing: logs, caches, databases, anything that changes constantly. Snapshot only what should be stable. If a file changes every day by design, it belongs somewhere else.

The minimal implementation

You do not need a tool. You need a directory, a script, and a cron entry.

Keep a plain folder, say ~/config-snapshots/, and make it a git repository. Each day, a script copies the watched files into the folder (redacting secret values from env files so only the key names remain), then runs git diff --stat and git diff against the last commit. If anything changed, commit with the date as the message and post the diff summary to wherever you actually look, such as a chat channel or a daily brief. If nothing changed, say nothing.

That last rule matters. A drift report that fires every day with “no changes” trains you to ignore it. Silence should mean stable, and a message should mean look.

Git gives you the rest for free: history, blame, and git log -p -- path/to/file when you need to find the day a setting flipped.

Redact on the way in

The one real risk of this system is leaking secrets into a snapshot repo. Handle it at copy time, not later. For env files, strip everything after the first equals sign and store only KEY=<set> or KEY=<empty>. Distinguishing set from empty catches a surprisingly common failure: a key that exists but has been blanked out.

Never push the snapshot repo to a public remote. If you want an offsite copy, use a private repository or an encrypted backup, and check the first few diffs by eye to confirm no value slipped through.

Reading the diff like an operator

A daily diff only helps if you triage it fast. Sort changes into three buckets:

• Expected. You made it on purpose, today. Acknowledge and move on.
• Explained. You did not do it today, but the cause is obvious: a package update, a scheduled job that rewrites a file. Note the cause once, and consider excluding that file if it is noise.
• Unexplained. You do not know why this changed. This is the only bucket that deserves real attention. Treat it like a smoke alarm: find the cause before anything else.

An unexplained change in a self-hosted setup has only a few possible origins: you forgot, a tool rewrote it, an agent edited its own config, or someone else has access. Every one of those is worth knowing about the same day.

The agent-edits-its-own-config case

This deserves a specific callout. If your agent has file write access to its own workspace, it can and sometimes will change its own instructions or config while “helping.” Usually it is harmless. Occasionally it quietly loosens a rule you set on purpose.

A snapshot diff catches this without any special monitoring. The change shows up as a modified instruction file with a timestamp, and you decide whether to keep it. You get the benefit of an agent that can improve itself, with a human review step that costs thirty seconds a day.

Pair it with a known-good tag

Once a week, or after any change you have verified works, tag the snapshot repo: git tag good-2026-10-26. Now “what changed since it last worked” becomes a single command, git diff good-2026-10-26, and rollback means restoring specific files from that tag rather than guessing.

This is the same logic as a deployment receipt: a fixed reference point makes every later question cheaper to answer.

What it costs and what it buys

Setup is about twenty minutes. Running cost is effectively zero: a few kilobytes of text per day and one short message when something changes. On a Raspberry Pi with an SD card, that write volume is negligible, though you should still keep the snapshot directory small and avoid copying anything large.

What you buy is the end of mystery regressions. The next time the agent behaves oddly, you open the last few diffs and usually see the cause on the first screen. Even when the answer is “nothing changed in config,” that is useful: it tells you to look at the model provider, the network, or the data instead, and it saves you an hour of chasing the wrong layer.

Start today

Pick five files. Make the folder a git repo. Write a script that copies, redacts, diffs, and only speaks when something changed. Add it to cron for early morning, before you start your day. Tag the current state as known good.

Then forget about it until the day it tells you something you did not know. That day always comes, and it is much cheaper to learn about it from a diff than from a customer, a missed post, or a bill.