One vault.
Every machine you admit.
A hosted vault serves a signed catalog over HTTPS. You pair each machine with a short code, admit it from the browser, and from then on it pulls skills and verifies every release against a key it pinned when it enrolled. Signing stays on your machine. Cloud never holds a signing key.
Pair a machine
Run this on the machine you want to sync. No argument: the slug is something the machine learns, not something you type.
$ autovault linkBKDF-QMTW: eight characters from a 20-letter alphabet with no vowels, so a code can never spell a word./cloud/pair. Check the fingerprint on screen against the one in your terminal, then confirm. Confirming is the admission here: the machine comes back active, with no second step on the dashboard.autovault link again to mint a new one. A single key may hold 5 live pairings at once, which is a guard against runaway retries rather than a rate limit. Admit and revoke
Every machine is listed under Machines on your cloud dashboard, identified by fingerprint. A fingerprint is the first four and last four characters of the machine's public key. The console never renders a full key.
pending to active. This is for a machine enrolled with autovault link <slug>, which lands pending. Confirming a pairing code already admitted that machine.RevokeMoves it to revoked, effective on that machine's next request. This needs no active subscription, so a lapsed account can still remove a machine it no longer controls.DenyRefuses a waiting pairing code. It writes a tombstone rather than deleting the record, so the CLI is told it was refused instead of timing out against a 404.Re-admitting a revoked key is deliberately not possible from the console. Pair that machine again from the machine itself.
What a machine may read
Access is scoped by enrollment status, and the catalog and the bundles are gated differently.
pendingcatalog.json, its own device recordBundlesactivecatalog.json, bundles, its own device recordNothing withheld while the subscription is liverevokedIts own device record, so the CLI can report it and exitcatalog.json, bundlesThe catalog being readable at pending is deliberate rather than an oversight. autovault link reads it the moment it enrols, to pin catalog.public_key before you have admitted anything. Bundles are where skill content actually lives, so they need active status and a live subscription.
How a request is signed
Every request under /v/<slug>/ is signed. There are no bearer tokens and no cookies.
X-AutoVault-Device base64url Ed25519 public key X-AutoVault-Timestamp whole seconds since epoch X-AutoVault-Signature base64url Ed25519 detached signature
The signed message is three lines: the HTTP method, the request path, and the timestamp.
<METHOD> <pathname> <unix-seconds>
Timestamps outside a 300 second window either side are rejected. That bounds replay rather than preventing it, and a seen-nonce store is deliberately out of scope for the beta.
Enrollment is self-attested: the request that enrols a key is signed by that same key, and the body has to repeat it. Admitting is what grants access, not enrolling.
How content lands in your vault
This is the part most people assume works differently, so it is worth being blunt about.
There is no publish API, and the CLI has no publish command. AutoVault is a consumer of the catalog, not a producer of it. The key that signs a release lives on the owner's machine and never reaches Cloud, which is the property that makes a signature worth checking in the first place. Signed catalog and bundle objects are therefore placed in your namespace out of band while this is in private beta.
404 until the first release is published to it. Your machine will pair and be admitted normally, then report an empty catalog. That is the expected state, not a fault in your setup. Limits worth knowing
All of these are current beta behaviour, and each one is a thing the product does rather than a thing it plans.
Key rotation breaks enrolled machines
Each machine pins catalog.public_key when it enrols, so changing that key hard-fails every one of them. There is no rotation flow that avoids this.
Scope is machines, not people
There are no seats, roles, or invitations. Adding a colleague means admitting their machine to your vault.
One vault per account
Namespaces cannot be renamed, transferred, or deleted once reserved.
Skill drafts are stored, not read back
Drafts submitted from the dashboard are written down and go nowhere. There is no review queue behind them yet.
The protocol underneath
Hosted sync is one transport for something smaller and more boring: a signed catalog of releases, and a bundle per release. Cloud is a convenient place to put those files. It is not where their trustworthiness comes from.
A catalog is one JSON document. Every release inside it carries its own detached signature, so the catalog is a manifest rather than an authority. Verification happens on your machine, against a key your machine pinned.
catalog.json schema_version 1 id vault identifier name display name public_key base64url Ed25519, pinned by each machine releases[] one entry per publishable thing releases[] kind skill | agent | mcp_server | collection name stable identifier version semver, compared on every check channel stable, beta, or your own publisher who signed it policy auto_apply | user_approve | admin_hold capabilities network, filesystem, tools[] breaking refuse a silent upgrade file_hashes[] path plus sha256, per file bundle_hash sha256 of the bundle bundle_path bundles/<bundle_hash>.json signature ed25519 over the release, domain-separated
Two fields do more work than the rest. policy decides what may happen without a human.
capabilities is the other one. It travels with the release, so what a skill is allowed to reach is part of the signed payload rather than a claim made after installation.
autovault-sync-release-v1, so a signature minted for some other purpose cannot be replayed as a release. Changing that string invalidates every signature ever issued. bundle_path is inside the signature and the client re-derives it as bundles/<bundle_hash>.json relative to the catalog. Bundles cannot be renamed, moved, or redirected, and the bundle you receive is checked against both bundle_hash and the per-file file_hashes before a single byte reaches the vault.
Upstreams
A vault holds a list of upstreams, and each one records where a catalog lives, the public key pinned for it, and this machine's own enrollment. autovault link is how one gets added.
There are two kinds, and the difference is only transport.
https
Points at a catalog URL. Requests are device-signed, which is what enrollment and admission exist for. AutoVault Cloud is one of these. So is any HTTPS host you run.
file
Points at a catalog path. A directory, a network mount, a checkout on disk. No server, no enrollment handshake to wait on, no account.
Both go through the same verification. A file upstream is not the trusting option: the release signature is checked exactly as it is over HTTPS, because a shared drive is not a trust boundary either.
$ autovault link acme-skills # a Cloud slug $ autovault link https://skills.acme.dev/catalog.json # your own host $ autovault link ./team-catalog # a directory
The argument decides the kind, and nothing else does.
., ~ or /, or a .json ending.slugA bare lowercase word, expanded against autovault.dev.Slugs are lowercase. A capitalised one is rejected with the lowercase spelling rather than quietly downcased.
Self-hosting a catalog
A catalog is a static file tree. Anything that serves JSON over HTTPS can host one.
your-catalog/
catalog.json
bundles/
3f1a...c92e.json
a704...11bd.jsonPoint a machine at it with autovault link https://your-host/catalog.json. Self-hosted catalogs carry no device enrollment, so there is no admit step and no console: access control is whatever your host already does, and the signature is what makes the content trustworthy either way.
autovault link, add, and sync-profiles all read; nothing signs a release. The signing primitives exist in the source and are reachable from the test helpers, not from a terminal. So today, hosting your own catalog means generating and signing it yourself against the shape above. That is a real amount of work, and it is the honest answer rather than a link to a command that does not exist.
Which makes the choice narrower than it looks. Cloud gives you enrollment, per-machine admission, and revocation, and publishing is hands-on. Self-hosting gives you the same verification with no account and no per-machine gate, and publishing is hands-on there too. Neither one has a publish button yet.
Where next
The quick start covers the local CLI, which is where skills are validated and signed. Security and provenance covers the gate a skill passes through before it is ever signed, hosted or not.