Skip to main content
Mcpjungle requires a database to persist registered servers, tool groups, users, and related configuration. Use the database choice as a deployment signal:
  • SQLite for local evaluation and single-user experimentation.
  • PostgreSQL for anything shared, durable, or production-facing.

Default: SQLite

When no database configuration is provided, Mcpjungle automatically creates a SQLite file named mcpjungle.db in the directory where the process is started:
SQLite requires no setup and works well for individuals running Mcpjungle locally. It is not recommended for production or multi-user deployments. If you do not provide PostgreSQL settings or a custom SQLite path, Mcpjungle uses ./mcpjungle.db. You can optionally set a custom path for the SQLite file using either a command-line flag or an environment variable:

PostgreSQL

Mcpjungle supports PostgreSQL for serious deployments. You can configure it with either a full DSN or individual environment variables.

Option 1: Connection DSN

Set the DATABASE_URL environment variable to a full Postgres connection string:

Option 2: Individual environment variables

If you prefer not to construct a full DSN, set the individual Postgres variables instead. POSTGRES_HOST is required; all other variables are optional and have sensible defaults.
Each credential variable also accepts a _FILE variant, which reads the value from a file. This is useful for Docker secrets and similar secret-injection mechanisms: Example using file-based secrets:
If both a variable and its _FILE counterpart are set, the plain variable takes precedence.

Variable precedence

When Mcpjungle starts, it resolves the database connection in this order:
  1. DATABASE_URL — used as-is if set
  2. POSTGRES_HOST (+ optional variables) — constructs a DSN if POSTGRES_HOST is set
  3. --sqlite-db-path — uses the configured SQLite file path from the CLI flag
  4. SQLITE_DB_PATH — uses the configured SQLite file path from the environment variable
  5. SQLite default — creates file mcpjungle.db in the current directory

Production recommendations

Deploy a separate Postgres cluster and supply its endpoint via DATABASE_URL. Running the database in a sidecar container is acceptable for development but not recommended for production.
The production Docker Compose file (docker-compose.prod.yaml) bundles a Postgres 17 container for convenience. For a real deployment, replace it with a managed database service and update the DATABASE_URL accordingly.