Deploying with Docker

Nanobox CRM ships as Docker containers, which makes deployment a repeatable process rather than a one-off build. This page walks the shape of a production deployment with Docker Compose. The exact file and commands come with your licensed source; the structure below is what to expect and confirm against it.

The pieces

A typical Nanobox deployment runs two main services plus a way to terminate TLS:

• The app container: the Next.js application that serves the CRM.
• PostgreSQL: the database. You can run it as a container in the same Compose file, or point the app at a managed Postgres instance and leave it out of Compose entirely.
• A reverse proxy: something like Caddy or Nginx in front of the app to handle HTTPS and route traffic to the container.

Bringing it up

With Docker and Docker Compose installed (see Installation) and your environment configured (see Configuration), a deploy is roughly:

1. Place your environment file next to the Compose file so both services read the same values: database URL, auth secret, app URL, email, and any Stripe keys.
2. Start the stack with Docker Compose. The database comes up, the app connects, and the services stay running in the background. [TODO: confirm the exact compose file name and up command shipped with the source.]
3. Apply migrations so the Postgres schema matches the app. Drizzle handles this in a single step. [TODO: confirm whether migrations run automatically on boot or as a separate command.]

Reverse proxy and TLS

Don't expose the app container directly to the internet. Put a reverse proxy in front of it to terminate HTTPS and forward requests to the app's internal port. Caddy is a common choice because it provisions and renews Let's Encrypt certificates automatically; Nginx with Certbot is the more manual alternative. Point your domain's DNS at the server, let the proxy obtain a certificate, and make sure your App URL environment variable matches the https:// address exactly. A mismatch here breaks login.

Where your data lives

This is the heart of owning the software. Your CRM data sits in PostgreSQL, and Postgres stores it on a Docker volume (or on the managed instance you chose). That volume is on infrastructure you control. Two implications worth internalizing:

• Back it up. Because it's standard Postgres, a routine pg_dump on a schedule is a complete, portable backup you can restore anywhere. Keep copies off the server.
• It's portable. There's no proprietary format to escape: you can move the database to another host or export it whenever you want.

After it's live

Verify the public URL loads over HTTPS, registration and login work, and a created record survives a restart of the app container (proving data is persisting to the volume, not just memory). From there, set up automated backups and a plan for applying updates to the source. If running all of this yourself isn't where you want to spend your time, Hosted does every step on this page for a flat monthly rate.