LZLZL/AI toolchain/Cloud · Discipline
FREEDeep · Hands-on D · Clouddiscipline

Key isolation · monitoring ·
backups · switching off

2026-08-21 · The last page: keeping it alive, and daring to end it

The previous twenty-one pages were about building this. This one is about keeping it alive long-term — and something equally important: being willing to switch it off.

In this pagefour disciplines. Not in this pagemy topology, hosts, key locations or backup scheme. Principles only, no scenes.

1Key isolation: the box with the keys is not the box doing the work

In one line: where the agent is free to make a mess should not be where the credentials that cause irreversible harm live.

RoleHoldsProperty
Working boxCode, data, logs, the agent itselfDisposable and rebuildable — reinstall and move on
Key boxCredentials that can move money, publish, or change productionMinimal surface, minimal things able to touch it

Why bother: page 16's combination risk — read-only tools pull secrets into context, outbound tools send context out. If the secrets are not on that machine at all, the path is severed at the source.

Cannot run two machines? Do three layers instead

Not everyone should buy a second box for this. The fallback costs essentially nothing:

separate files: secrets in their own file (a .env-style one), config elsewhere — so backups can exclude cleanly;
separate permissions: only the user that needs it can read that file, and the agent's deny rules forbid reading it explicitly (page 2);
separate tiers: everyday work uses the least-privileged credential, and the high-privilege one is not kept on that machine at all.

2Monitoring: watch for absence, not presence

This is the formal answer to page 11's fourth trap.

ApproachProblem / benefit
❌ Notify on success tooTrains you to ignore notifications — including the one that mattered
❌ Notify only on failureSounds right, but does not cover "the whole process died and could not even report failing"
Missing-heartbeat alarmStamp a timestamp on every success; have something else check whether it has gone stale

The crux: the checker has to live outside the thing being checked. Anything monitoring itself goes quiet together with itself.

Three more to watchWhy
Restart countPage 21: auto-restart disguises broken as running
Disk usageA full disk breaks everything at once, for reasons unrelated to your work
SpendAn always-on agent spends while you are not looking (page 12, heartbeats)

3Backups: worth as many restores as you have rehearsed

A backup never restored is not a backup

An old truism, but it bites harder in this thread, because so much of the value sits in memory, skills and configuration — things whose location is vague (page 6's list).

There is exactly one real test: can you rebuild this on a fresh machine from your backup and your notes? Do it once. You will find two or three things you missed — and those are what would have hurt.

Back upHow
Config directoriesInto your existing backup, excluding the secrets file
Memory and skillsSame — the least replaceable category
Rebuild notesPage 20's note, steps only, no secrets
The secrets themselvesNot in ordinary backups — a password manager or similar, and only an inventory of what exists

4Switching off: a box with no work left should go

This thread closes on this line, because it is the lesson left by the machine on page 12.

An always-on machine with no work is not free

It still costs money, still waits to be maintained, and still occupies a slot in your head labelled "how is that box doing". And it remains an attack surface — a public machine you have stopped paying attention to is more dangerous than one you use, because it does not get updated and nothing that happens to it gets noticed.

Signals to switch offNote
Its work moved somewhere elseThe most legitimate reason of all — it does not need to have gone bad
The output has no recipientPage 10's test: nobody acts differently because of it
You have not looked at it in a monthIt is not important to you. It remains just as important to an attacker
One thing to do first: archive, do not delete

This is the precondition that made page 14's command useful. Copying the state directory costs a few minutes and may be worth a one-command move months later.

"Can be switched off" belongs in the design from the day you build it, not discovered on the day you want to stop.

5End of the thread

From page 1's "running commands is the phase change" to this page's "be willing to switch it off", one idea ran through the middle — a single base_url, which is what keeps you unbound from any one vendor at every layer.

This thread promises no money. It promises one thing: by the end, the stack in your hands is yours — movable, backup-able, stoppable, replaceable.

Nature of this page All four disciplines are this site's practice and judgement, not a standard or a product document. Specific implementations (monitoring systems, backup tools, secret managers) are neither recommended nor compared here.
Source of the last one On 2026-07-13 I switched off an always-on agent machine because its work had moved elsewhere; the knowledge base was archived in full at shutdown, which later made a migration command usable. See page 12 and page 14.
Not in this page My host topology, key locations, backup scheme, monitoring configuration or schedules. Every example in this thread is a placeholder, not a reproduction of any real deployment.

RelatedRead next

A · Local
What a CLI agent has that a chat box does not
B · Access
What a relay API actually is
C · Always-on
OpenClaw, and why I switched that machine off
D · Cloud
Run it as a service, so it restarts itself
An educational and engineering record — not a review or endorsement of any third-party product. Commands, config keys, prices and terms are per each vendor's official docs; this page states when it was checked and all of them can change without notice — verify before you copy anything. Self-hosting is your own responsibility: keys, accounts and data are on you.