Skip to main content
When you scaffold a project with voyant new, you get a working application shell wired to the platform. This page walks through what is inside and the commands you run day to day.

​
Configuration

A Voyant project is described by a voyant.config.ts manifest at its root. It declares which modules the app uses, and the platform reads it to assemble schemas, routes, and admin extensions. Inspect it at any time:

​
Environment and secrets

Local development uses two files:
  • .env holds local secrets and the database URL. Copy it from the example the generated project ships:
  • .env provides DATABASE_URL for Drizzle tooling and local worker processes.
    .env
When you deploy to Voyant, secrets move into the managed Vault instead of local files.

​
Database workflow

The platform uses Drizzle ORM over PostgreSQL. The CLI proxies Drizzle Kit and adds Voyant-aware helpers:
See Data model for how schemas and links fit together.

​
Preflight checks

Before deploying, run the doctor to catch configuration drift between your env types, wrangler.jsonc, database, and admin manifest:

​
Running locally

The operator application serves on port 3300:
For workflow development, the CLI can watch and hot-reload your workflow definitions on their own:

​
Common scripts

Generated projects expose a consistent set of package scripts:

​
How code is organized

The platform draws a hard line between reusable logic and app-specific wiring:
  • Packages (the @voyant-travel/* dependencies) hold business logic, schemas, services, routes, adapters, and contracts. You consume them as ordinary versioned dependencies.
  • Your app shell owns UI, auth wiring, deployment configuration, and the voyant.config.ts manifest that ties chosen modules together.
This keeps upgrades clean: you bump module versions like any other dependency, and your app-specific code stays put.

​
Next steps

Add a module

Generate a new domain module with the CLI.

Data model

Schemas, links, and migrations in depth.