> ## 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.

# Project structure

> What a scaffolded Voyant project contains, how to configure it, and the everyday commands you run.

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:

```bash theme={null}
voyant config show       # print the resolved manifest
voyant config validate   # check it is well formed
voyant config path       # show which file was resolved
```

## 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:

  ```bash theme={null}
  cp .env.example .env
  ```

* **`.env`** provides `DATABASE_URL` for Drizzle tooling and local worker processes.

  ```bash title=".env" theme={null}
  DATABASE_URL="postgres://user:password@localhost:5432/my_travel_app"
  ```

When you deploy to Voyant, secrets move into the managed [Vault](/docs/services/vault) instead of local files.

## Database workflow

The platform uses Drizzle ORM over PostgreSQL. The CLI proxies Drizzle Kit and adds Voyant-aware helpers:

```bash theme={null}
voyant db generate       # generate a migration (timestamp-prefixed by default)
voyant db migrate        # apply migrations
voyant db studio         # open Drizzle Studio
voyant db push           # push schema directly (dev only)
voyant db sync-links     # emit link-table DDL for cross-module links
voyant db schemas        # print the manifest-derived schema list
voyant db doctor         # report migration and schema drift
```

See [Data model](/docs/concepts/how-it-is-built) 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:

```bash theme={null}
voyant doctor            # run all preflight gates
voyant doctor --strict   # fail on warnings too
```

## Running locally

The operator application serves on port `3300`:

```bash theme={null}
pnpm dev
```

For workflow development, the CLI can watch and hot-reload your workflow definitions on their own:

```bash theme={null}
voyant dev --file ./src/workflows.ts
```

## Common scripts

Generated projects expose a consistent set of package scripts:

| Command           | What it does              |
| ----------------- | ------------------------- |
| `pnpm install`    | Install dependencies      |
| `pnpm dev`        | Start the dev server      |
| `pnpm db:migrate` | Apply database migrations |
| `pnpm build`      | Build the app             |
| `pnpm typecheck`  | Run TypeScript checks     |
| `pnpm test`       | Run tests                 |

## 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

<CardGroup cols={2}>
  <Card title="Add a module" icon="plus" href="/docs/platform/modules">
    Generate a new domain module with the CLI.
  </Card>

  <Card title="Data model" icon="table" href="/docs/concepts/how-it-is-built">
    Schemas, links, and migrations in depth.
  </Card>
</CardGroup>