Use the AOS Hub web interface
The Hub has two browser surfaces. Public registry browsing and the login, account-security, invitation, and device-approval ceremonies are rendered on the server. Authenticated resource management uses the first-party AOS Hub console and requires JavaScript. Public registry pages can be read anonymously. Account, organization, project, registry, and instance changes require a signed-in account with permission on the relevant scope.
#Browse published data
Registry URLs use the organization and registry name as a slug. For a registry
named cdn in the acme organization:
| Page | Path |
|---|---|
| Registry home | /acme/cdn/ |
| Packages | /acme/cdn/-/packages |
| Package detail | /acme/cdn/-/packages/<name> |
| Native documentation | /acme/cdn/-/docs |
| Native reference detail | /acme/cdn/-/docs/<name>/<version>/<platform>?release=<release>&digest=<sha256> |
| Channels | /acme/cdn/-/channels |
| Channel detail | /acme/cdn/-/channels/<name> |
| Releases | /acme/cdn/-/releases |
| System images | /acme/cdn/-/images |
| Registry health | /acme/cdn/-/health |
Packages, Docs, Images, and Containers show one exact release at a time. The
release selector offers each channel's current target, the newest releases,
and the selected release; the Releases page lists every publication. The jump
field accepts a version, a commit, or a channel name such as stable and
redirects to the exact version, so a copied link never drifts when a channel
moves. Unknown releases are not found rather than falling back to another
release.
The Docs page lists native package, option, and operation references generated from ordinary module declarations. Search by text or select a kind; the page shows up to 1,000 matching entries from the selected release. Each result opens its exact package version and platform with the release and document digest in the URL. Detail pages show option types, descriptions, and mutability, together with operation inputs/results and links between operations and their owning packages or base modules. Each owner lists exposed input/result contracts, handled operations, and consumed operations configured by its effects. Follow these links in either direction to inspect the selected handler owner. Complete input/result contracts retain recursive fields and constraints. Generated options have a dedicated table with owner links, types, descriptions, read-only policy, and extensibility; hidden plumbing is omitted. The package detail page embeds the same native reference.
Interfaces show their package or OS release owner and use that owner's release version. Module requirements link each requesting owner to its dependency package and preserve package version ranges and OS release requirements. These generated declarations describe compatibility requirements; they are not a resolution result or evidence of live execution. Plain module dependencies inherit their package's version requirement; explicit immutable source pins remain valid.
Hub verifies the signed documentation directory and exact options.json bytes
before rendering a detail page. A package without a native documentation
artifact has no reference to browse. Private registry documentation requires
the same access as the registry's other published data.
The /-/ segment keeps human-facing routes separate from the machine facade at
the registry root. Git objects, AOS releases and channels, Nix cache metadata,
and NARs therefore keep their native paths.
The Images page presents signed release encodings as end-user disk downloads, including architecture, format, compatible target, size, checksum, and verification state. Public downloads may use a ready CDN or direct delivery route. Private downloads stay on the Hub origin so the signed-in browser can authorize the exact disk bytes with its session cookie.
The Releases page opens with a support board: one tile per supported train,
newest train first, showing the train's major.minor, its LTS marker, its
newest release (a candidate counts for its train), "Until" and the end date
when the registry states one, and the channels targeting it. Trains that no longer
receive updates are not listed, and a train within ninety days of its end date
is highlighted. The registry's committed [support] policy decides; without
one, the newest two trains and any channel-targeted train count as supported.
Filters narrow the directory by major version, minor version, and status
(stable, candidate, edge, other prerelease, or long-term support when the
registry marks LTS trains).
A release page shows its notes, contents, and rollout. When the registry serves a public release record for it, the page adds a Qualification section: the result and admission time, the release class, the policy and authority, the train's support statement at release, a table of every claim with its required and achieved assurance, and provenance digests. The Hub shows the section only after verifying the record's signed qualification envelope against its trusted keys; the served registry remains the authority.
A channel page shows the target release, the minimum allowed release, and the share of the 256 rollout buckets assigned, then the rollout bar and a colour-coded bucket map. Enter a host's bucket to see which release it gets.
#Review unpublished release candidates
Maintainers with the registry's Publish permission use Publishing at
/<org>/<registry>/-/settings/staged-releases. Its candidate list is separate
from the public Releases, Packages, and Images pages. A candidate is a portable
aos.registry-stage/v1 revision, with an ordinary authoring branch, exact
prepared signed commit, object inventory, and withheld publication pointers.
Open Review candidate to inspect the branch, commit, uploaded bytes, verified complete bytes, and missing-object progress. Readiness requires every object to be verified; partial transfer progress alone is insufficient. Resume the exact APR revision with the displayed command, replacing its registry placeholder with your configured local alias for this Hub destination, or upload an individual small object. A prepared next-revision JSON file can be reviewed and saved with the current revision precondition; concurrent changes require a fresh review.
A ready candidate is already signed. Publish reviewed release freezes the exact revision and its reserved semver identity, then publishes those bytes; the browser never needs a private signing key. Channel assignments remain a separate operation. Discard requires the stage id and exact revision; discarded and superseded candidate roots retain a 24-hour grace period. Released and shared objects keep their other retention roots.
Default public catalogs and channels omit unpublished candidates. Direct refs, digests, cache paths, and CDN URLs may expose uploaded bytes; stage hiding is a publication boundary. See release stages for the common APR, Hub, and filesystem contracts.
#Sign in and administer a Hub
Open /login. A deployment may offer password, passkey, magic-link, or OIDC
sign-in depending on its configuration. Settings pages keep their headings
short; the ? mark beside a section title opens its explanation on hover,
focus, or click. The browser session is separate from
the bearer tokens used by API clients.
After signing in, use:
/-/accountfor the current account;- the organization and instance settings under
/-/for administrative work; /<org>/<registry>/-/settingsfor registry configuration.
The registry settings overview includes Registry details for its committed name, description, homepage introduction, default browser release, and release support policy. The registry needs an indexed publication before these fields can be edited. Changing the committed name does not rename its URL or move it to another organization or project.
Choose Review metadata draft to inspect the exact registry.toml diff,
then Create draft. The console shows the apr change merge command a
maintainer runs with a registry signing key. The published details change only
after that merge is published and indexed. Editing a field invalidates an
earlier review; if another publication changes the indexed commit, reload the
settings before creating a new draft.
An empty introduction or description removes that text. An empty default
browser release restores automatic selection without changing package-manager
tracking. The advanced support-policy editor accepts TOML with [default] and
[trains] tables; keep it consistent with the release qualification contract.
Clearing it removes the explicit support policy.
Edit registry policy manages visibility, crawler policy, llms.txt, and
pinned trust anchors. Enter one public anchor per line as
name:Ed25519:base64-public-key. Review lists the anchors being added or
removed; applying these operational settings takes effect directly. Trust
anchors can also be supplied when creating a registry.
Organization resource inventories keep creation separate from browsing:
/-/org/<org>/projects/new, registries/new, caches/new,
bindings/new, domains/new, network-policies/new,
endpoints/new, and gateways/new open focused reviewed-
creation workflows below the same organization root. The inventory pages link
to those routes and do not mix full create forms into the resource list.
Deployment-wide domain, network-boundary, delivery-endpoint, and
storage-gateway inventories use the same pattern below /-/instance, with a
new route below each collection. A create action is shown only when the live
scope grants the API permission required by that resource; organization
creation remains governed by the instance signup policy.
The management console uses the same aos.hub.v1 Connect API, reviewed
plan/apply mutations, and IAM checks as the CLI. It exchanges the HttpOnly
browser session and page CSRF proof for a five-minute bearer held only in
memory; it never stores that bearer in local storage or IndexedDB. Canonical
management deep links therefore load the same client application, while login
and account-security ceremonies remain ordinary server-rendered pages.
The console uses the same IAM roles and scope inheritance as the API. Its navigation is filtered using live permissions evaluated by the Hub for the exact current resource; typing a sensitive deep link directly does not reveal the page when that permission is absent. Permissions inherit down the scope tree, from the instance to an organization, project, and registry. Roles are task-oriented rather than a simple ladder: Admin manages organization settings, while Maintainer owns publishing, channels, and keys. Owner has both sets of permissions; Developer and Viewer are narrower roles.
Registry and cache settings start with effective configuration. Delivery
shows selected client destinations and offers a coordinated setup workflow.
Storage & replicas shows effective read and write locations before offering
storage setup and replication. Advanced policies and diagnostics load when
opened; per-location controls retain desired state, controller observations,
and reviewed promotion, drain, and deletion. The request
explainer tests an absolute URL, optional machine-path override, and web,
git, or nix_cache access class against the live simultaneous route set. The
object-presence lookup shows the reported digest, size, and state at every
placement. Cache administrators with GC execution authority can review a
physical placement eviction from the placement card; this is distinct from
logical cache garbage collection and starts a durable evacuation operation.
The cache Objects page accepts a canonical machine path and exact file. The Hub admits either a short-lived direct-origin upload or an authenticated same-origin proxy upload. Large files automatically use the Hub's multipart protocol, and a failed part aborts the durable upload. The browser never sends its Hub bearer to a direct storage URL.
The organization's Members page includes member and invitation inventory. Invite a member creates a reviewed pending invitation and shows its acceptance link after apply; it does not pre-create an account or membership. Deliver that link only to the intended email. The invitee signs in as the exact matching address. The first visit exchanges the URL credential for a short-lived, HttpOnly browser handoff and redirects to a clean URL before showing navigation or login. Password, magic-link, passkey, and SSO login all return to that clean acceptance page. The invitee reviews and accepts it; the Hub then consumes the invitation and creates the membership atomically. Member managers can cancel a pending invitation from the same page. Accepted, cancelled, and expired invitations remain visible as history.
The organization SSO page manages one OIDC identity provider and its email domains. Provider reads are redacted to a “client secret configured” state. Saving or removing a provider first shows an immutable effects review and then applies the exact reviewed revision. A blank client-secret field preserves the current credential; the explicit clear checkbox removes it.
Claiming a domain returns the TXT value to publish. Verify DNS also uses a reviewed plan and performs the DNS lookup in the Hub; it cannot mark a domain verified merely because an administrator clicked the button. Only a verified domain participates in email-first SSO routing. Domain release is separately reviewed and stops that routing. Rotating a challenge returns the domain to pending state until the new value is published and verified.
#Browse a binary cache
Cache slugs share the top-level URL namespace with registries:
| Page | Path |
|---|---|
| Cache home | /<cache>/-/ |
| Objects | /<cache>/-/objects |
| Object detail | /<cache>/-/objects/<store-hash> |
| Transitive closure | /<cache>/-/closure/<store-hash> |
A public cache also exposes its object list at /<cache>/-/api/objects.
#Use the simple JSON views
Public-only, read-only JSON views are available alongside the browse pages:
/<flat-slug>/-/api/registry
/<flat-slug>/-/api/packages
/<flat-slug>/-/api/packages/<name>
/<flat-slug>/-/api/channels
/<flat-slug>/-/api/releases
These routes never use a browser session or bearer token to reveal non-public
data. The convenience router currently accepts single-segment slugs; use the
unary API for canonical organization/registry paths such as acme/cdn. Use
these routes for small read integrations and the HTTP API for
authenticated visibility, writes, or stable service methods.
#Authentication behavior
- Password sign-in is enabled by default and can be disabled in instance settings.
- Passkeys provide usernameless WebAuthn sign-in. They require the small first-party browser script mentioned above.
- Magic links are single-use and expire after 15 minutes. Native deployments currently log them; Worker deployments need Email Service or an HTTP relay for delivery.
- OIDC is configured per organization and uses authorization code with PKCE. The current implementation accepts RS256 ID tokens.
- Browser sessions use a secure, HTTP-only cookie. The defaults are seven days idle and 30 days absolute, with a 15-minute reauthentication window for sensitive work; the absolute lifetime cannot exceed 30 days.
The aos hub login device-code flow uses the same identity and authorization
state as browser sign-in; see the CLI guide.
#Inspect native runtime ability documents
Open /-/runtime-abilities, choose a JSON file or paste its contents, and select
Inspect document. The file picker reads locally; submitting sends the document
to the Hub for rendering. The Hub does not retain it. Browser import accepts up
to 2,796,199 bytes so encoded form data fits the shared 8 MiB request limit.
Use options.json from a native documentationArtifact to browse option types,
descriptions, operation inputs/results, and links between package/environment
owners and the operations they declare, handle, or configure. Import an
aos.package.transaction to see effects in execution order, with dependency
links, implementation programs, owners, lifetimes, exact selected inputs, and
desired revisions. Composition links identify child effects and the producers
of exported results. These identities describe the checked selected graph;
they do not prove a handler ran.
These are evaluated declarations and desired execution paths, not live state. Imported documents do not authenticate a publisher. Published native references also appear in the release Docs and package pages, where Hub verifies their signed publication identity. See the full guide and inspection API.
Published release ability pages aggregate authenticated native declarations and link each reference with its exact release and document digest. They show operation contracts and definition owners. These pages describe release declarations; they do not show an executed deployment graph or verify live runtime state.