Build it on your computer. Run copies of it on your servers.
Quantize gives you a small Linux machine on your Mac or Windows PC — a real one, with a console. You install, configure and test on it. When it is right, Quantize reads the machine back into a signed, encrypted bundle, and a server of yours rebuilds it from that bundle and runs it as microVM copies behind one door. What runs on the server is the machine you built, not a description of it.
Three pieces, one direction
A machine on your computer, a bundle that is the machine written down, and a server that turns the bundle back into running copies. Everything flows one way: from the computer you build on to the servers that serve.
The Lab Machine
A small Alpine Linux server on your own computer, on the hypervisor the computer already has: Apple's Virtualization framework on a Mac (Apple silicon and Intel), WSL 2 on Windows. Nothing is downloaded to make one — the Linux it boots ships inside the app. It has a console, packages from apk, services, a firewall of its own, and a Files channel the app talks to. You work on it as on any server you own.
The bundle
What the machine is, read from the machine itself: the packages at their exact versions, the services at boot, /etc whole, every file on the disk that no package put there, and the folders synced from your computer. Signed with this computer's Ed25519 key, then sealed for one server — X25519 with that server's identity, AES-256-GCM in chunks bound to their place. Opened by that server, by nobody else.
Quantize Server
One static binary on a Linux server with KVM, installed by one command. It opens the bundle with its own key, checks the signer and the signature, rebuilds the machine into a sealed base disk, and runs copies of it as Firecracker microVMs — each in the jailer's cage, under its own user, behind one door on the service port. Every version is kept sealed; a rollback is a start of the one before.
How it works
The whole trip, from the console on your computer to the copies on the server, in the order it happens. Nothing here is a template you write; every step reads what is actually there.
You build on the machine
apk add what you need, start the services, drop your site in /var/www or your app in /opt, edit /etc until it is right. A folder of your computer can be kept inside the machine as it changes — Local Sync — so you edit where your tools are and the machine sees it at once. The machine's address works only on this computer; nothing of it is sent anywhere until you decide to deploy.
Quantize reads the machine
The recipe is taken from the machine, never from a file you maintain. Packages come from apk's own database at the versions installed. Services come from the runlevel. /etc is packed whole, less Quantize's own files and the machine's identity. Then the diff: every path on the disk that no package owns — a site, an app, a tool in /usr/local/bin, a git clone, an npm -g install — found by walking the disk against the package database, packed with owners and modes kept. The machine's own runtime (/proc, /run, /tmp, caches, logs) never goes; data folders, synced folders and what you chose to leave out go another way or not at all.
Before you deploy
What the machine says of itself is checked against what the server will do with it, and each finding comes with its one-click fix: a service running here but not at boot, so it would not start there; something listening on a port no setup names; a web server whose config answers to names the machine is not a site for; a service that keeps data in a folder nobody marked as data, so every deploy would start it over empty; a 600 MB folder of downloads that would ride along. Warnings, never blockers — you decide.
Sign, seal, send
The bundle is one file: the recipe, the trees, the setup for the server (processors, memory, service ports, firewall rules, the site). It is signed with your computer's Ed25519 key, then sealed for the server it is going to with that server's X25519 identity and AES-256-GCM, each chunk bound to its position. It travels over your own SSH login to the server. A bundle sealed for one server opens on no other, and the server refuses a bundle from a key it was not told to trust.
The server rebuilds the machine
In a build root of its own, on a network namespace of its own, Quantize Server lays out Alpine's minirootfs for the recipe's release — fetched once from the mirror and checked against the sum known for it — and runs apk add inside it for the recipe's packages at their pinned versions, saying so when the mirror has moved on and one came newer. Then /etc and the diff tree are laid over the result at the same paths with owners and modes kept — links made last, no path ever followed through a link — and ownership is shifted into the machine's own user range. The base disk is sealed with AES-XTS and its sum kept beside it. Every version of every machine is stored sealed, so the server has the history and can open none of it without its keys.
Copies run
Each copy is a Firecracker microVM — its own kernel, its own memory — booted from the sealed base in the jailer's cage: a chroot, a user of its own, the device nodes it needs and no others, seccomp on, no core files ever written. The base is mounted read-only under an overlay in the copy's own memory, so a copy keeps nothing of its own; what the machine wrote to disk on your computer is there, what a copy writes at run time is gone when it stops. A copy is reached through the door: the service ports of the setup, forwarded by nftables and shared between the copies. The firewall rules you set on the machine become the copy's own nftables, applied inside, and the copies of one machine can see each other. A machine that keeps data runs one copy; one that keeps none runs as many as its setup says.
A site, with its certificates
Name the domains the machine serves and it becomes a site. Quantize Server then listens on 80 and 443 for it, routes by name — SNI on 443, the Host header on 80 — to the machine's copies, and gets its certificates from Let's Encrypt by TLS-ALPN-01, kept 0600 on the server and renewed thirty days before they expire. HTTP is sent to HTTPS with a 308 when you ask, and a rehearsal mode uses Let's Encrypt's staging CA while you are still testing. The web server inside the machine stays plain; the front is the one thing on the server that speaks TLS.
Data stays, versions change
A folder you mark as data — /var/lib/mysql, /srv/uploads — becomes a volume: a disk of its own on the server, encrypted inside the copy, kept from one run to the next and from one version to the next while the machine around it is rebuilt. Backups are of these folders alone, taken with the filesystem frozen for the moment it takes, written as one encrypted file you can keep anywhere. Everything that is not data is disposable by design: stop a copy and it is gone; deploy again and it is back exactly as the machine was.
Next to containers
Quantize does what people reach for containers to do — build once, run the same thing everywhere — with a machine as the unit instead of an image, and with the trust questions answered by the server rather than by a registry.
| Question | Container images | LockFlare Quantize |
|---|---|---|
| What is the unit? | An image: a stack of filesystem layers built from a file of instructions, run as a process that shares the host's kernel. | A machine: a whole small Linux server with its own kernel, built by hand on your computer and read back into a bundle. Copies run as microVMs, each with a kernel of its own. |
| What do you write? | A build file and a compose file, kept in step with what you actually did to make the thing work. | Nothing. You work on the machine; the recipe is read from the machine — apk's database, the runlevel, /etc, the files no package owns. |
| What travels? | Layers to a registry, pulled by the host; what is in them depends on how the build file was written. | One file, signed by your key and sealed for one server, carried over your own SSH login. No registry, no third place where it rests. |
| Who may run it? | Whoever can pull from the registry; signing is an add-on. | The server opens only a bundle from a key it trusts, and only one sealed for it. Its own keys are sealed to the TPM where it has one, so a copied disk opens nothing. |
| How is it isolated? | Namespaces and cgroups on a shared kernel. | A Firecracker microVM in the jailer's cage per copy: own kernel, own memory, own user, seccomp, nftables. The host's own firewall stays the host's. |
| What persists? | Named volumes and bind mounts, declared in the compose file. | Data folders you mark on the machine's record, each a disk of its own kept across versions, encrypted inside the copy, backed up as one encrypted file. |
| How does it get TLS? | A proxy container and its own configuration, or the application does it. | Name the domains; the server's front gets the certificates from Let's Encrypt and renews them. The web server in the machine stays plain. |
| What does it tell its maker? | Depends on the engine and the registry. | Nothing. The app talks to your servers; the server talks to its copies, to apk's mirror when it builds, and to Let's Encrypt when a site asks. Neither one talks to LockFlare. |
What the server holds itself to
Quantize Server runs other people's machines on a box you own, so most of its engineering is about what it refuses. These are the mechanisms, not the promises.
Trust is a list, not a login
The server keeps the public keys it was told to trust. A bundle is opened with the server's own key, its signer looked up on that list and its Ed25519 signature checked before a byte of it is used. The install prints the server's identity; the app learns it over SSH and seals every bundle to it.
Keys sealed to the hardware
Where the server has a TPM 2.0, the key that protects the store is made from the server's own random numbers and sealed as a TPM object under its storage root: it unseals in that TPM and nowhere else. A disk image copied or backed up elsewhere opens no machine, no version, no base. Without a TPM the keys stay in the clear and the install and the doctor say so plainly.
A cage per copy
Firecracker and its jailer, fetched at install and checked against known sums. Each copy is a chroot under a user of its own, with /dev/kvm, /dev/net/tun and nothing else made inside, seccomp on, a tap of its own on the bridge, and core files off. A copy's volumes are bound in and owned by that user.
The host's firewall stays the host's
Quantize Server keeps nftables tables of its own for the door, the front and the copies' way out. The one thing it writes into anyone else's chain is a passage: a single accept for what comes from or goes to its own bridges, at the top of a chain that would otherwise drop it, commented as such, remade when a firewall reload flushes it and taken out by uninstall. What the server shows the outside is as it was. The daemon itself listens on a unix socket alone, never on a port: it is reached over SSH, by the app as by you.
Trees laid over, never through
When a bundle's trees are written into a build, every path is checked to land under the build's root, links are made last so nothing is written through one, and a link where the tar put a folder with files is refused. Owners and modes are the machine's, shifted into the copy's user range.
The gate at install
quantize-server install and the daemon's start refuse a server that lacks what the cage needs: x86-64, hardware virtualization with KVM, SMEP and SMAP, user namespaces, a ptrace scope of 3, nftables and iproute2. quantize-server doctor reads the same list any day after, with the state of the keys and of every machine.
What runs where
On your computer
The Quantize app, for macOS (Apple silicon and Intel, on Apple's Virtualization framework) and Windows 10 or later (on WSL 2). The Lab Machines live in the app's folder, each with its console, its record and its Local Sync rules. Your signing key and your servers' logins are sealed in that folder under a key of their own. Nothing of a machine leaves the computer until you deploy it, and then it leaves sealed, over your own SSH.
On the server
Quantize Server, one static binary, on a Linux server on x86-64 with hardware virtualization and KVM — a bare machine or a VM whose provider passes virtualization through. It brings Firecracker and its jailer with it, wants nftables and iproute2, and uses a TPM 2.0 when the server has one. It runs as a system service, keeps its store sealed, and comes back on its own after a restart with the machines that were running.
Questions
What is a Lab Machine?
A small Alpine Linux virtual machine that runs on your own computer, with a console, apk packages, services and a firewall of its own. It runs on the hypervisor the computer already has — Apple's Virtualization framework on a Mac, WSL 2 on Windows — and the Linux it boots ships inside the Quantize app, so nothing is downloaded to make one. You build on it exactly as you would on a server you own, and Quantize reads it back into a bundle when you deploy.
What goes into a Quantize bundle?
The packages at their installed versions, read from apk's own database; the services at boot, read from the runlevel; /etc whole, less Quantize's own files and the machine's identity; every file, link and folder on the disk that no package owns, with owners and modes kept; the folders synced from your computer; and the setup for the server — processors, memory, service ports, firewall rules and the site. The machine's runtime (/proc, /run, /tmp, caches and logs) never goes, and neither does anything you leave out or mark as data.
Is Quantize a container platform?
No. The unit is a machine with its own kernel, not an image run as a process on a shared one; the recipe is read from the machine rather than written as a build file; the bundle is signed by your key and sealed for one server rather than pushed to a registry; and each copy runs as a Firecracker microVM in the jailer's cage. It is for the same job — build once, run the same thing on your servers — done with a machine as the unit.
What happens to my database when I deploy a new version?
If its folder is marked as a data folder on the machine's record, it is a volume on the server: a disk of its own, encrypted inside the copy, kept from one version to the next while the machine around it is rebuilt from the new bundle. Quantize warns you before a deploy when a running service keeps data in a folder that is not marked, because without the mark every deploy would start that service over empty. A machine that keeps data runs one copy.
How does TLS work?
You name the domains the machine serves and it becomes a site. Quantize Server listens on 80 and 443 for it, routes by name to the machine's copies, and obtains the certificates from Let's Encrypt with the TLS-ALPN-01 challenge, renewing each one thirty days before it expires. The certificates and their keys stay on the server, readable by the daemon alone. The web server inside the machine serves plain HTTP on its own port; the server's front is what speaks TLS to the world, and it can send HTTP to HTTPS with a 308 when you ask. A rehearsal mode uses Let's Encrypt's staging CA while you test.
Does Quantize connect to LockFlare?
No. The app talks to your Lab Machines on your computer and to your servers over your own SSH logins. Quantize Server talks to the copies it runs, to apk's mirror when it rebuilds a machine, to GitHub once at install to fetch Firecracker and its jailer, and to Let's Encrypt when a site asks for a certificate. Nothing checks a license, reports a crash or counts your machines. Licensing is announced with the release.
What does the server need?
Linux on x86-64 with hardware virtualization and KVM — a bare machine, or a VM whose provider passes virtualization through — with SMEP and SMAP, user namespaces, a ptrace scope of 3, nftables and iproute2. A TPM 2.0 seals the server's keys when there is one; without it the keys stay in the clear and the install says so. Quantize Server is one static binary installed by one command, which fetches Firecracker and its jailer and checks them against known sums.
When does it ship?
Quantize is coming January 2027. Write to [email protected] with what you would move onto it and we will tell you the day it is out.
Coming January 2027
Quantize is in its last months of building. If you run things on Linux servers that you would rather build and test on your own computer first — a site, an API, a worker, a database with its data kept — write to us with what you would move onto it, and we will tell you the day it ships.