Platform overview

The platform is what a Voyant deployment is. It is the same whether you use Voyant or self-host Voyant OSS: a normalized travel operations data model on PostgreSQL, domain modules covering the whole commercial chain, an API over all of them, an admin, and a public booking surface. It is built for online travel agencies, tour operators, and destination management companies. Rather than a generic e-commerce engine bent into travel shape, it models the business directly: catalog, commerce, inventory, operations, relationships, bookings, trips, finance, distribution, legal, charters, cruises, flights, and accommodation resale.

​

How it runs

Voyant runs as a resident Node process against Postgres. TanStack Start and React 19 for the dashboard, Hono for the API, Better Auth for identity, Drizzle for data access. The modules are not separately deployed services. They are components of one deployable, assembled through the resolved deployment graph and booted together into a single application. A deployment cannot drop or replace a standard module; substitution happens at adapters and providers. The deployable is published as the ghcr.io/voyant-travel/operator container image.

​

What you get

• A normalized travel operations data model on PostgreSQL and Drizzle.
• Domain modules covering the full commercial chain, each owning its services, data model, routes, and local domain logic.
• A Hono-based API layer with admin, public, and app surfaces.
• Package-owned background work — subscribers and jobs contributed by the modules that need them, recovering from domain-owned durable state.
• React packages per domain (relationships-react, inventory-react, commerce-react, bookings-react, and so on) that wrap each module’s HTTP contract.
• A shared admin shell and a first-class Public API surface.

​

The package surface

Most packages are internal to the platform. Fourteen are published to npm: the *-contracts tier plus @voyant-travel/ui, @voyant-travel/payments, @voyant-travel/schema-kit, @voyant-travel/app-manifest, and @voyant-travel/admin-extension-sdk. Those are the integration points for code outside the platform repository. @voyant-travel/cli is published separately. Everything else is private. Treat the families below as a map of the platform, not of the npm registry.

​

Core

The runtime and tooling every deployment uses: @voyant-travel/core (module system, container, event bus, adapter registration), @voyant-travel/db, @voyant-travel/hono, @voyant-travel/react, @voyant-travel/auth, @voyant-travel/types, @voyant-travel/utils, @voyant-travel/storage, @voyant-travel/i18n.

​

Travel domain modules

The business logic. Each module owns one subdomain — @voyant-travel/catalog, @voyant-travel/bookings, @voyant-travel/finance, and the rest. See the full module catalog.

​

UI and React families

Every domain module has a matching -react package owning hooks, clients, providers, query keys, view-model helpers, and components. The shared admin shell is @voyant-travel/admin; cross-cutting primitives are in @voyant-travel/ui.

​

Extension seams

Customization happens in exactly two places: adapters and providers change an implementation inside the deployment, and apps run entirely outside it.

​

Architecture principles

• Packages hold reusable business logic, schemas, services, routes, adapters, and contracts. Applications own UI, auth wiring, deployment shape, and runtime configuration.
• Core packages stay framework-agnostic in the generic sense: they do not assume a particular UI or HTTP library, even though the shipped application uses React, TanStack Start, Hono, Better Auth, and Drizzle.
• Transport adapters stay thin and call shared domain services rather than owning business logic.
• Package-owned jobs call the same domain services as routes and subscribers. Domain records stay authoritative.
• Selected modules publish their ownership through the same voyant.package.v1 manifest contract, whether first-party, third-party, or project-local. There is no parallel central catalog for API, admin, access, tool, event, webhook, schema, migration, or runtime authority.

The tenancy model is one Postgres database and one runtime per organization, with isolation enforced at the deployment boundary. See Architecture for the reasoning.

​

Accommodation, deliberately scoped

Voyant supports accommodation as catalog inventory for resale, packaging, and trip composition. It is not a hotel property-management system and does not position itself as first-party hotel operations. Accommodation appears as sourced inventory, as a component of a product, or as a place reference — never as a PMS.

​

Next steps