What you get
- Deployable application shells, not just isolated packages. The starters are real apps you can ship.
- A normalized travel operations data model on PostgreSQL and Drizzle.
- Headless domain modules you compose into your own platform.
- A Hono-based API transport layer with optional route helpers.
- Durable, step-based workflow orchestration that runs on your own infrastructure or on Voyant Cloud’s hosted runtime.
- Versioned React packages per domain (
relationships-react,inventory-react,commerce-react,bookings-react, and so on) that wrap each module’s HTTP contract. - Optional integrations for payments, e-invoicing, storage, CMS sync, and notifications, shipped as plugins.
Starters
Voyant ships a first-party starter you scaffold from with the CLI:| Starter | Purpose | Stack |
|---|---|---|
operator | Tour-operator workflows | Cloudflare Workers, TanStack Start, Hono, Better Auth, Drizzle |
The framework surface
The packages fall into a few families.Core platform
The runtime and tooling every app uses:@voyant-travel/core, @voyant-travel/db, @voyant-travel/hono, @voyant-travel/react, @voyant-travel/auth, @voyant-travel/types, @voyant-travel/utils, @voyant-travel/storage, @voyant-travel/i18n, and the @voyant-travel/cli.
Travel domain modules
The headless business logic. Each module owns one subdomain such as@voyant-travel/catalog, @voyant-travel/bookings, or @voyant-travel/finance. See the full module catalog.
Workflows
Durable orchestration:@voyant-travel/workflows (the authoring SDK) and @voyant-travel/workflows-orchestrator (the engine and self-host runtime). See Workflows.
UI and React families
Every domain module has a matching-react package that owns hooks, clients, providers, query keys, view-model helpers, and reusable components. The shared admin shell lives in @voyant-travel/admin, and cross-cutting UI primitives in @voyant-travel/ui.
Plugins
First-party integration bundles:@voyant-travel/plugin-netopia (payments), @voyant-travel/plugin-smartbill (e-invoicing), @voyant-travel/plugin-payload-cms and @voyant-travel/plugin-sanity-cms (CMS sync).
Architecture principles
Voyant keeps a strict separation of concerns:- Packages hold reusable business logic, schemas, services, routes, adapters, and contracts.
- Starters and app shells own UI, auth wiring, deployment shape, and runtime configuration.
- Core packages stay framework-agnostic even though the first-party starters use React, TanStack Start, Hono, Better Auth, and Cloudflare Workers.
- Transport adapters stay thin and call shared domain services rather than owning business logic.
- Workflow business logic ships as plain SDK packages; orchestrator and runner apps wrap them for a given runtime.
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 shows up as sourced inventory, as a component of a product, or as a place reference, never as a PMS.Next steps
Project structure
What a scaffolded project contains and how it is organized.
Module catalog
Every domain module and what it owns.
Data model
How schemas, links, and migrations work.
Workflows
Author durable, step-based orchestration.