ImportantAlways be vigilent for false links, our wealth app can only be found here.
HQ DocsLedgercurrentSign in

Ledger › Getting Started › Configuration

Getting Started

Configuration

How to configure Ledger's database connection, OAuth providers, and runtime options through a single environment file.

Version
current
Updated
Reading time
2 min
Author
HQ FS

Configuration

Ledger reads its entire configuration from a single environment file at the project root. The repository ships an .env.example with every supported variable documented; copying it to .env.local and filling in the handful of required values is enough to get a development instance running. Nothing about Ledger requires editing source code to configure — every behaviour-changing setting is an environment variable.

This page walks through the variables in three groups: the small required set that every instance needs, the OAuth provider credentials (at least one is required for sign-in), and a longer list of optional variables you can leave at their defaults until you have a reason to change them.

Required variables#

These three values are non-negotiable. Without all three, the server refuses to start. The auth secret should be generated locally and never reused across environments — openssl rand -base64 32 produces a suitable value.

Variable

Description

DATABASE_URL

PostgreSQL connection string

AUTH_SECRET

32-byte secret for signing JWT sessions

AUTH_URL

Public URL of this app (e.g. https://app.atlas-labs.com)

OAuth providers#

Ledger doesn't manage passwords directly — all sign-ins go through a third-party OAuth provider. At least one provider must be configured for sign-in to work; all three listed below are supported and you can configure as many as you want.

bash
GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=

DISCORD_CLIENT_ID=
DISCORD_CLIENT_SECRET=

TWITTER_CLIENT_ID=
TWITTER_CLIENT_SECRET=

Database setup#

Once DATABASE_URL points at a reachable PostgreSQL instance, apply the schema migrations before starting the server for the first time. The standard production-style flow is migrate deploy, which applies the committed migration history exactly as it was created.

bash
npx prisma migrate deploy

For local development where you'd rather skip the migration ceremony, db push synchronises the schema without recording a migration. Use this only for personal databases that no one else depends on.

bash
npx prisma db push

Optional variables#

The rest of the configuration surface has sensible defaults. Override these only when you have a specific reason to — most local-development setups never touch them.

Variable

Default

Description

NEXT_PUBLIC_APP_URL

AUTH_URL

Used in emails and public links

LOG_LEVEL

info

One of debug, info, warn, error

RATE_LIMIT_WINDOW_MS

60000

API rate-limit window in milliseconds

Was this page helpful?