Sealed warrant backend

The Armory

The Armory is Zipper’s warrant mesh for iOS, Android, and the web. You mint a hatch-bound session, then a warrant that names a rack. A write warrant is a spent cartridge — reuse returns 409. Musters hold sealed documents with revisions — every document is sealed at rest under its own per-muster key (za1), and shredding a muster destroys that key forever: the ciphertext husk remains as tamper-evident proof and a zd.… destruction receipt proves it. Vault seals (zv.…) link into an append-only notary chain. Kit is cordoned by Palace Guard, including JSON bodies. The roll is real SSE on this node: writes publish put/patch/unput. Rotate anon and service keys from the dashboard anytime. Twenty Docker racks isolate duties. Requests run under a 7.5s server budget with Server-Timing, and reads never pay for a vault re-seal. An official client (ArmoryClient) ships with cartridge-safe retries. This is not Firebase, not Appwrite Cloud, not FCM/APNs, and not Kubernetes. Without Docker the same twenty racks run in-process and still fail closed.

In plain English — A ready-made backend for mobile and web apps: sign-in sessions, a database where each collection has its own encryption key, and live updates. Like Firebase, but sealed — and a collection can be crypto-shredded forever.

• ▸ Spent-cartridge write warrants (zw.…)
• ▸ za1 sealed musters — per-collection keys, crypto-shreddable
• ▸ Destruction receipts (zd.…) + append-only notary chain
• ▸ Hatch-bound sessions — Origin is identity
• ▸ Rotate / regenerate anon and service keys
• ▸ Live roll SSE on this node (not FCM)
• ▸ Musters with revision stamps
• ▸ Palace Guard on kit and JSON
• ▸ Twenty Docker racks, one duty each

Auto-provisioned on every new zone. Read the The Armory docs, including use cases and API examples. Manage it from the dashboard after you create an account.