An integrated AI platform for enterprise model routing, chat, files, tools, billing, identity, and operations.

English | 简体中文

DEEIX Chat is an open-source, deployable AI platform for individuals, teams, and enterprises that need long-term, stable, and unified access to multiple model providers. It provides one clear entry point for multiple upstream models and providers, integrating multimodal chat, model routing, files and RAG, MCP tools, usage billing, identity, audit logs, and operational controls into one product.

The system is designed around simple deployment, efficient static delivery, and a low runtime resource footprint: lightweight without feeling limited, restrained without losing capability, and open without becoming disorderly.

DEEIX Chat uses a split frontend/backend development model with a single-runtime deployment path. The frontend is built into static assets and served by the Go service, while APIs, authorization, model routing, files, billing, and audit capabilities run in the same backend runtime. Heavy document extraction and OCR capabilities are optional services, keeping the base deployment lightweight.

flowchart TB
  Browser["User / Admin Browser"]

  subgraph Frontend["Frontend Build"]
    Web["Next.js 16 / React 19<br/>Chat UI / Admin Console"]
  end

  subgraph Backend["Go Single Runtime"]
    Static["Static Asset Serving"]
    HTTP["Gin HTTP API"]
    App["Application<br/>Auth / Routing / Files / Billing / Audit"]
    Infra["Infra Adapters<br/>Protocols / Data / Cache / Storage"]
  end

  subgraph External["External Capabilities"]
    Providers["Model Providers<br/>OpenAI / Anthropic / Google / xAI / OpenRouter"]
    Tools["Tool Services<br/>MCP / Provider Native Tools"]
    Extractors["Optional File Processing<br/>Tika / Docling / OCR"]
  end

  subgraph Data["Data and Storage"]
    DB["PostgreSQL + pgvector<br/>or SQLite + sqlite-vec"]
    Cache["Redis<br/>or In-Memory Cache"]
    Storage["Local Filesystem<br/>or S3-Compatible Storage"]
  end

  Web --> Static
  Browser --> Static
  Browser --> HTTP
  HTTP --> App
  App --> Infra
  Infra --> Providers
  Infra --> Tools
  Infra --> Extractors
  Infra --> DB
  Infra --> Cache
  Infra --> Storage

The backend keeps clear internal boundaries: cmd/internal/cli handles entrypoints, internal/app assembles the application, transport/http owns the HTTP boundary, application coordinates use cases and transactions, domain expresses business semantics, and infra contains database, cache, storage, and external protocol implementations. The data layer uses domain-prefixed tables, while financial records, audit trails, system events, and high-growth vector data remain separate sources of truth.

Quick installation guide: Quick Start.

Local development is intended for editing source code and running the frontend and backend separately. The default config connects to local PostgreSQL and Redis. If you only want a low-dependency trial, use the lightweight Docker installation below.

1. Prepare backend configuration:

cp config.example.yaml config.yaml

Adjust database.postgres.dsn, database.redis.*, and public URLs in config.yaml for your local environment.

2. Start the backend:

cd backend
make run

3. Start the frontend:

cd frontend
pnpm install
cp .env.example .env.local
pnpm dev

The frontend uses NEXT_PUBLIC_API_BASE_URL for API requests. For local development, confirm that frontend/.env.local contains:

NEXT_PUBLIC_API_BASE_URL=http://127.0.0.1:8080

URLs:

If NEXT_PUBLIC_API_BASE_URL is omitted, local development defaults to localhost:8080; same-origin deployments use the current origin.

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.

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.

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.

cp config.example.yaml config.yaml
# Edit database.postgres.dsn, database.redis.*, and public URLs.
docker compose up -d

The default docker-compose.yml starts only the application container. Keep compose environment empty unless you intentionally want environment variables to override config.yaml.

Use this when you want compose to start the app, PostgreSQL, and Redis together.

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

docker-compose.full.yml sets POSTGRES_DSN, REDIS_ADDR, REDIS_USERNAME, and REDIS_PASSWORD in compose environment, so those values override the database and Redis values in config.yaml.

Configuration priority is environment variables > config.yaml > built-in defaults. config.yaml is for static infrastructure and security configuration such as server URLs, database, cache, storage, GeoIP, tracing, JWT, and encryption keys. Runtime business settings are stored in the database and managed in the admin console.

The default compose files persist application data:

The default application image is ghcr.io/deeix-ai/deeix-chat:latest. Override it with DEEIX_CHAT_IMAGE when testing a custom build:

DEEIX_CHAT_IMAGE=deeix-chat:local docker compose up -d --build

APP_ENV accepts dev/development and prod/production, normalizes them to dev or prod, and defaults to prod when omitted. Use dev only for local development. Public production deployments should keep APP_ENV=prod or APP_ENV=production and use production secrets.

These services are optional. Start only the ones you enable in the admin console or config.yaml. They attach to deeix-chat-network; start one root compose profile first, or create the network manually with docker network create deeix-chat-network.

docker compose -f docker/tika/docker-compose.yml up -d
docker compose -f docker/tesseract/docker-compose.yml up -d --build
docker compose -f docker/docling/docker-compose.yml up -d --build

Default local endpoints:

docker/rapidocr currently provides a Dockerfile and app entrypoint, but no compose file. Add a compose file or run it manually if you choose RapidOCR.

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 .

2. 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.

3. 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.

After the application starts, verify the health endpoint, config file, and startup logs. For Docker deployments:

curl http://localhost:8080/healthz
docker compose exec app ls -l /app/config.yaml
docker compose logs app

If the database does not contain a superadmin account, the backend creates the initial administrator on first startup and prints the initial password only once.

If a superadmin already exists, the service does not regenerate or print the initial password again.

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.

• User Guide
• Admin Guide
• Advanced Guide

• User passwords are hashed with bcrypt.
• Production mode rejects unsafe default secrets, weak encryption keys, wildcard CORS, and non-HTTPS public URLs.
• Refresh tokens and recovery-style secrets are stored as hashes.
• Upstream API keys, SSO client secrets, MCP auth tokens, sensitive settings, and TOTP secrets are encrypted with AES-GCM using DATA_ENCRYPTION_KEY.
• Access tokens are short-lived and held client-side in memory; refresh tokens are issued through HttpOnly cookies.
• User-supplied model options are filtered before provider requests. System-generated fields such as model, messages, tools, system prompts, headers, and previous-response identifiers are not user-overridable.

• Quick Start
• Configuration
• User Guide
• Admin Guide
• Advanced Guide
• Backend guide: backend/README.md
• Backend standards: backend/docs/README.md
• Frontend guide: frontend/README.md
• Contributing: CONTRIBUTING.md
• Security policy: SECURITY.md
• Swagger UI: http://localhost:8080/swagger/index.html

DEEIX Chat is built on the open-source ecosystem. Thanks to all maintainers and communities in the AI tooling ecosystem.

• Next.js
• Go
• LINUX DO

• Website: deeix.com
• Blog: blog.cheny.me
• Email: support@deeix.com
• Telegram: t.me/deeix_chat
• X: @DEEIX_AI

DEEIX Chat is licensed under the Apache License 2.0.