> ## Documentation Index
> Fetch the complete documentation index at: https://voyant.travel/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Admin

> The staff-facing operations console: a shared, extensible admin runtime your starter composes into a back office.

The admin is Voyant's staff-facing surface. It is the operations console where your team manages quotes, bookings, inventory, finance, legal documents, and the rest of the back office. Like the Public API, it is a first-class platform surface rather than UI thrown together per project.

## Shared runtime, application-owned shell

The admin is split into two layers on purpose:

* The **admin runtime** is framework-owned. It provides shared providers, an auth-aware admin context, locale and timezone runtime, and base layout primitives. This lives in the common admin packages so it is not reimplemented in every app.
* The **admin shell** is application-owned. Your app composes the final layout, navigation defaults, and route composition on top of the shared runtime.

This keeps every Voyant admin consistent at the runtime level while leaving you free to shape the product.

## Extension points

The admin is extensible through explicit extension points rather than ad hoc patching. Each domain module contributes its admin surface, and the platform assembles them. The CLI generates the wiring from your `voyant.config.ts` manifest:

```bash theme={null}
voyant admin generate              # emit admin.extensions.generated.ts from the manifest
voyant admin generate --routes     # emit the code-assembled admin route module
voyant admin generate --destinations # emit the generated destination resolver map
voyant admin doctor                # check manifest, extension, and route parity
```

Run `voyant admin generate --check` to verify the generated files are in sync without rewriting them, which is useful in CI.

## Localization

The admin supports its own localization for the operator interface. This is kept separate from business-content translation: translating the admin UI for your staff is a different concern from translating customer-facing catalog content, and the two do not share a pipeline.

## Packages

The shared admin shell lives in `@voyant-travel/admin`, with `@voyant-travel/admin-react` and the per-domain `-react` packages contributing the views. Cross-cutting UI primitives live in `@voyant-travel/ui`.

## Next steps

<CardGroup cols={2}>
  <Card title="Modules" icon="cubes" href="/docs/platform/modules">
    The domain modules that contribute admin surfaces.
  </Card>

  <Card title="Public API" icon="globe" href="/docs/platform/public-api">
    The customer-facing counterpart.
  </Card>
</CardGroup>