DEEIX聊天

Docker Deployment

Choose one installation profile first, then copy the matching config file. All root compose profiles expose the app at http://localhost:8080 by default and mount the repository-level config.yaml to /app/config.yaml inside the container.

1. Lightweight Installation: SQLite

This is the lowest-dependency deployment. It starts only the app container, stores data and local vector indexes in SQLite, and uses the in-process memory cache. Use it for local evaluation, personal deployments, and small single-node setups.

cp config.sqlite.example.yaml config.yaml
docker compose -f docker-compose.sqlite.yml up -d

SQLite + memory cache is single-process only. It is good for local use, evaluation, and small single-node deployments. Use PostgreSQL + Redis for multi-node or high-concurrency production deployments.

2. Default Installation: External PostgreSQL + Redis

Use this when PostgreSQL and Redis are already managed outside this compose stack. Before starting, set database and Redis addresses to values reachable from inside the container; if the services run on the Docker host, host.docker.internal is usually the right hostname.

```bash cp config.example.yaml config.yaml

Separated Deployment

Use this mode when the frontend and backend are served from different public origins, for example https://chat.example.com and https://api.example.com.

1. Configure public URLs.

• Frontend build variable: NEXT_PUBLIC_API_BASE_URL=https://api.example.com
• Backend config: server.public_api_base_url=https://api.example.com
• Backend config: server.public_web_base_url=https://chat.example.com
• Backend config: server.cors_allow_origin=https://chat.example.com

For Docker image builds, pass the frontend API URL at build time:

   docker build --build-arg NEXT_PUBLIC_API_BASE_URL=https://api.example.com -t deeix-chat .
   

1. Build and publish the frontend.

   cd frontend
   pnpm install
   NEXT_PUBLIC_API_BASE_URL=https://api.example.com pnpm build
   

The static output is frontend/out. Serve it with Nginx, CDN, object storage, or any static web server. To let the Go backend serve the frontend, place frontend/out under server.frontend_dist_dir; the Docker image defaults to /app/frontend/out.

1. Apply CDN rules.

| Path | Rule | | --- | --- | | /_next/static/* | Cache for 1 year with immutable assets enabled. | | /logo*.svg, /*.ico, /*.png, /*.jpg, /*.webp, /*.woff2 | Cache for 1 day to 30 days. | | /, /*.html, /chat*, /recent*, /files*, /setting*, /admin*, /share* | Do not long-cache. Use no-cache or a short TTL. | | /api/*, /healthz, /readyz, /swagger/* | Bypass CDN cache and forward all request headers, methods, query strings, and request bodies. |

If the CDN serves frontend/out from object storage, enable route fallback so clean URLs resolve to their exported index.html files, for example /chat -> /chat/index.html.

Quick Start

Quick installation guide: Quick Start.

Feature Guides

• User Guide
• Admin Guide
• Advanced Guide

Configuration

Full configuration guide: Configuration.

Backend configuration is split into static runtime configuration and runtime business settings. Static runtime configuration describes the infrastructure, security, and storage parameters required to start the service, and is provided through config.yaml and environment variables. Runtime business settings cover product capabilities such as authentication, conversations, models, files, and billing; they are stored in system_settings and maintained from the admin console. Environment variables override matching config-file values, which is useful for containerized deployments, separated deployments, and secret injection.

At startup, the backend resolves the default config file from the working directory: starting from the repository root reads config.yaml, while starting from backend/ reads ../config.yaml. Docker deployments usually mount host ./config.yaml as read-only /app/config.yaml inside the container. If the config file is stored elsewhere, set CONFIG_FILE to a path accessible from the running process or container.

Static configuration environment variables:

Authentication, registration, conversation settings, model option policies, file processing, RAG, embedding, MCP, billing, payments, and announcements are runtime business settings, not static YAML configuration. Their defaults are seeded by the backend and maintained in the admin console.