---
name: generate-config
description: Generate a pREST config for a PostgreSQL database. Use when the user needs prest.toml, .env, or Docker Compose to stand up pREST.
---

# Generate pREST config

## When to use

- Starting a new pREST project from an existing PostgreSQL database
- Migrating ad-hoc connection settings into `prest.toml` / env vars
- Producing a local Docker Compose stack

## Ask first

Collect only what is missing:

1. pREST version (prefer v2; ask if unclear)
2. Postgres host, port, database name, schema, SSL mode
3. DB user / password strategy (env vars vs local demo values)
4. Auth needs (none for local demo, JWT, table-based `/auth`)
5. Prefer Docker Compose or bare `prestd` binary
6. Single database or multi-database (`pg.single = false`)

## Instructions

1. Emit a minimal, documented config — do not invent undocumented TOML keys.
2. Prefer environment variables for secrets (`PREST_PG_PASS`, `DATABASE_URL`, `PREST_JWT_KEY`).
3. Generate:
   - `.env.example` (never real secrets)
   - `prest.toml` using v2-friendly sections (`[http]`, `[pg]`, `[pg.ssl]`, optional `[jwt]`, `[auth]`, `[expose]`, `[access]`, `[queries]`)
   - Optional `docker-compose.yml` with Postgres + pREST (`prest/prest` image) when the user wants Compose
4. For local demos only, use obvious placeholder credentials and label them as non-production.
5. Warn that production must use strong secrets, TLS, restricted `access`, and non-superuser DB roles.
6. Point to https://docs.prestd.com/get-started/configuring-prest for authoritative field lists.

## Output shape

Provide files ready to paste, plus a short “how to run” section (`docker compose up` or `prestd`).

## Safety

- No real credentials in committed examples.
- Prefer `access.restrict = true` in anything beyond throwaway demos.
- Mention that `debug = true` disables JWT enforcement.