Self-Hosting

Self-hosting is for teams that need a shared web entry point, private network access, dedicated database credentials, AI key management, and persistent application data.

Best-Fit Scenarios

  • Run Dory in a private network, private cloud, or self-managed server.
  • Manage database access, AI keys, secrets, and team permissions directly.
  • Provide one shared browser entry point for a team.
  • Connect private, cloud, staging, or production databases.
LayerDecision
RuntimeRun Dory as a Docker container.
Application dataChoose persistent PGlite storage or Postgres.
Public accessPut Dory behind HTTPS through a reverse proxy or gateway.
SecretsStore .env values through a secret-management process.
Database networkConfirm the Dory runtime can reach target databases.
IdentityChoose email login, verification, or OAuth policy.

Two Database Concepts

Database roleWhat it storesWhere to configure
Application databaseDory users, organizations, connections, saved queries, settings, and MCP tokens.Environment Variables
Connected databasesBusiness or analytical databases queried through Dory.Connect Your Database

Do not leave application data inside a disposable container filesystem for production. PGlite needs a persistent volume; Postgres needs a dedicated backed-up database.

Preflight Checklist

ItemConfirm
DomainThe URL users will open, such as https://dory.example.com.
HTTPSRequired for team deployments.
Auth URLBETTER_AUTH_URL matches the browser-facing URL.
SecretsDS_SECRET_KEY and BETTER_AUTH_SECRET are generated and stored safely.
Application databasePGlite persistent storage or Postgres is selected.
AIProvider, model, API key, data boundary, and key rotation are decided.
Database accountsProduction connections use readonly credentials first.
MembersInvitation, connection ownership, and offboarding rules are defined.
BackupsApplication data, .env, and database credentials have a backup plan.
  1. Choose the domain, HTTPS path, and network boundary.
  2. Choose application storage: PGlite or Postgres.
  3. Prepare .env and secrets.
  4. Start a test deployment with Docker.
  5. Sign in with the initial admin user.
  6. Configure authentication policy.
  7. Connect a test database and validate SQL Console, Explorer, AI, and Saved Queries.
  8. Back up data before adding production database connections.

Operational Boundaries

  • Use dedicated database users for production connections.
  • Prefer readonly credentials for production analysis.
  • Allowlist the Dory server egress IP for cloud databases.
  • Use SSH tunnels or private routing for internal databases.
  • Mount SQLite and DuckDB files into the container when needed.
  • Dory AI sends necessary context to the configured provider, so decide the allowed data boundary before rollout.

How is this guide?