Configuration

Nanobox CRM is configured through environment variables, the standard approach for a Dockerized app. You set them once (typically in a .env file or your container environment), and the app reads them at startup. This page explains the categories of settings and what each is for. Exact variable names ship with the source you receive; where a name isn't certain here, treat it as a label to confirm rather than a literal.

Database

The most important setting is the connection to your PostgreSQL database. Nanobox talks to Postgres through Drizzle ORM, and it expects a standard connection string pointing at a database it can read and write.

• Connection URL: host, port, database name, user, and password, usually as a single postgres:// URL. [TODO: confirm the exact variable name, e.g. DATABASE_URL.]

If the app starts but can't save records, this is the first thing to check.

Authentication

Accounts, sessions, and login are handled by better-auth. It needs a secret to sign sessions and a canonical URL for the app so callbacks and cookies resolve correctly.

• Auth secret: a long random string. Generate a fresh one per deployment and never reuse it across environments. [TODO: confirm the exact variable name.]
• App URL: the public base URL of your instance, e.g. https://crm.example.com. Getting this wrong is the usual cause of login redirect loops.

Email

Transactional email covers things like sign-up confirmation and password resets. Nanobox sends through an email provider you supply, so you'll configure credentials for that provider.

• Email provider credentials: typically an API key plus a verified "from" address. [TODO: confirm whether SMTP, a provider API, or both are supported, and the exact variable names.]

If you don't configure email, expect account-recovery flows that depend on it to be unavailable until you do.

Payments

If your deployment takes payments (for example, the Hosted billing flow or any in-app purchase), Stripe handles it. That requires API keys and a webhook secret so Stripe can notify your instance of completed events.

• Stripe keys: a secret key for server-side calls and a webhook signing secret to verify incoming events. [TODO: confirm exact variable names and which Stripe features are wired up in your licensed build.]

Good practice

Keep secrets out of version control, use different values per environment, and restart the app after changing any variable so it's picked up. When something misbehaves after deploy, re-read this list top to bottom. Most issues are a single missing or mistyped value. Next, see Deploying with Docker.