Securityencryptionhomelabzfsself-hosting
Julio Merino's ZKeys Keeps Half of Your Disk Passphrase Off-Site and Locks It Once Your Home Server Stops Checking In
Merino built it for his FreeBSD home NAS with an encrypted ZFS pool, and runs it free with "no promises" about uptime. The catch is that you back up the full key yourself, and the post gives no timing for the lockout.
Julio Merino was reinstalling his FreeBSD home NAS with an encrypted ZFS pool when the usual problem showed up. An encrypted disk needs its passphrase at boot, and a NAS that waits for someone to type one is a NAS that stays down through every power blip. Leaving the key in a file on the same machine defeats the encryption, as the box and its key would walk out the door together.
His post, dated November 7, 2026, describes the answer. The server holds only half of the passphrase, and the client holds the other half. The zkeys client combines them. The half on the server is also encrypted at rest with a password the client supplies over HTTPS, so, by the post’s account, a compromise of the server alone is not enough to rebuild a key.
The lock is the clever part. The client keeps the key unlocked by sending periodic keepalive messages. When the server stops hearing them for a long period, it locks the key automatically and refuses future retrievals. A manual lock exists too, and the demo shows a Fedora machine refusing to reboot while the key is locked. The post doesn’t give a specific interval, so the length of “long” isn’t something a reader can plan around yet.
The threat is a break-in where somebody carries the machine away and plugs it in somewhere else. A thief with the hardware but no network path to the key server gets an encrypted disk. A thief who can reach it before the lock engages might get further, which is why the post says the protection depends on the key being locked before retrieval. Merino’s stated goal is to “protect against real incidents” while keeping reboots automatic. Manually wiping a remote key after you notice the theft can be too late, especially if you are away for weeks.
The tool is open to read. The GitHub repository describes the client as a command-line tool for accessing secrets managed by a ZKeys server, built to “facilitate unlocking encrypted pools and file systems in an unattended fashion.” It is a Rust program under a BSD-2-Clause license, with install steps that use configure and make. The README says keys are “never stored on the machine where they are used.” It leaves key management out of the client on purpose, so the admin keys don’t end up on the box by accident. Those features live in the web interface.
The service is free, with a warning. Merino says he makes “no promises about its reliability, availability, or anything else” and may re-evaluate if support or load becomes a burden. There are two instances, US West and EU West, and they aren’t replicated. He recommends the US one, citing power problems at the EU deployment. Setup is manual: no upstream OS ships packages, and the integrations that exist cover FreeBSD (rc.d) and Fedora (systemd and dracut).
The open item is the one the post is blunt about. You have to back up the full encryption key yourself. If ZKeys goes down or you lose the remote key password, Merino can’t help you recover the data. A free service with no availability promise, holding half of what unlocks your disk, is a fine arrangement as long as you keep a complete copy of your own. Nobody on the other end is going to dig it out of a drawer for you.
One hosted service probably won’t be the only one doing this. The pattern, a machine that proves it is still where it belongs before it gets its secret, is simple enough that home labbers can rebuild it on a cheap VPS, and the variations that matter will be about the timer: how long before a quiet server counts as a stolen one. That number decides whether anyone trusts the scheme with data they can’t replace.
Half a key opens nothing, which is the point.