Database Templates

The database category includes 6 production-ready database templates with persistent storage, health checks, and secure defaults.

Template List

Common Configuration

All database templates include:

• Persistent volumes for data storage (survives container restarts)
• Health checks using database-native commands (pg_isready, mysqladmin ping, etc.)
• Auto-generated passwords — secure random passwords created at deploy time
• No exposed ports — databases are accessible only within the Docker network

Variables

PostgreSQL

Image: postgres:16

The default database for AI Admin Panel itself. Configured with:

• WAL archiving support
• pg_stat_statements extension enabled
• Tuned shared_buffers and work_mem for the allocated memory
• Automatic vacuum configuration

MySQL

Image: mysql:8.4

Configured with:

• InnoDB as the default storage engine
• utf8mb4 character set and utf8mb4_unicode_ci collation
• Binary logging enabled for point-in-time recovery
• Secure default authentication (caching_sha2_password)

MariaDB

Image: mariadb:11

MySQL-compatible with additional features:

• Aria storage engine for crash-safe temporary tables
• Thread pool for better concurrent connection handling
• utf8mb4 character set by default

MongoDB

Image: mongo:7

Document database configured with:

• Authentication enabled by default
• WiredTiger storage engine
• Journal enabled for crash recovery
• Initial database and user created from variables

Redis

Image: redis:7

In-memory store configured with:

• appendonly yes for persistence
• maxmemory-policy allkeys-lru to handle memory limits
• Password authentication required
• RDB snapshots every 60 seconds

Qdrant

Image: qdrant/qdrant:v1.15.1

Qdrant is a high-performance vector database — the storage layer behind most RAG (retrieval-augmented generation) and semantic-search applications. It stores high-dimensional embeddings with payload filtering and HNSW indexing, and ships a built-in web dashboard for browsing collections. Configured with:

• Auto-generated API key — created at deploy time and injected as QDRANT__SERVICE__API_KEY. Every REST and gRPC request requires it; the only unauthenticated path is the health endpoint. Reveal the key in the service's Credentials card (admin-only, audit-logged).
• Persistent named volume at /qdrant/storage — your collections survive restarts and redeploys.
• Real health check — the container probes GET /healthz and auto-recovers if Qdrant crashes or hangs.
• HTTPS dashboard — unlike the relational databases above, Qdrant is reached over its own subdomain. Click Open Qdrant Dashboard on the service page; it lands on /dashboard. Paste the API Key into the dashboard's API Key field (top-right) to browse collections.

Ports

Connecting an app

Use the auto-generated API key as the api-key header (REST) or in your gRPC client config. From another service on the same panel network, reach Qdrant by its service name:

# REST, from another service on the same panel
curl -H "api-key: <YOUR_API_KEY>" http://my-qdrant:6333/collections

# gRPC client config
host=my-qdrant port=6334 api_key=<YOUR_API_KEY>

For external/SDK access, use the service's public HTTPS subdomain with the same API key.

Connecting to Databases

Databases deployed through the panel are accessible to other services on the same Docker network. Use the service name as the hostname:

# From another service on the same panel
postgresql://db_user:db_pass@my-postgres:5432/mydb
mysql://db_user:db_pass@my-mysql:3306/mydb
mongodb://db_user:db_pass@my-mongo:27017/mydb
redis://:password@my-redis:6379

For external access, databases intentionally do not expose ports. If you need external access, deploy a connection proxy or use the panel's API to stream queries.

Backup Integration

Database templates work with the panel's backup system. Backups use database-native dump tools:

• PostgreSQL: pg_dump
• MySQL/MariaDB: mysqldump
• MongoDB: mongodump
• Redis: RDB snapshot copy