DEEIX Chat: a Go single-runtime AI workspace for routing models, files and billing

The problem DEEIX Chat targets: many providers, one entry point

Teams that use more than one model provider end up maintaining a thin internal layer: keys in several places, different request shapes per vendor, no shared usage record, and no single place to revoke access. DEEIX Chat is built for that situation. The README describes it as an "integrated AI platform for enterprise model routing, chat, files, tools, billing, identity, and operations", aimed at individuals, teams and enterprises that need "long-term, stable, and unified access to multiple model providers".

The audience matters. This is not a thin chat wrapper you drop into a static site. The feature table lists subscriptions, top-ups, balances, usage ledgers, billing snapshots, Stripe Checkout and EPay alongside 2FA, SSO/OIDC/OAuth and audit logs. Those are operator features. A single developer who only wants to talk to one model will carry a lot of surface area for no benefit.

How the Go runtime, routing layer and adapters fit together

The architecture diagram in the README shows a split build with a single deployment path. The frontend is Next.js 16 and React 19, built into static assets; the Go service serves those assets and hosts the HTTP API. The backend is Go 1.26 with Gin, Gorm, Swagger, OpenTelemetry and Zap. Data and cache are PostgreSQL with pgvector, or SQLite with sqlite-vec, plus Redis or an in-memory cache. Files go to the local filesystem or S3-compatible object storage.

Internal boundaries are stated explicitly: `cmd/internal/cli` for entrypoints, `internal/app` to assemble the application, `transport/http` for the HTTP boundary, `application` for use cases and transactions, `domain` for business semantics, and `infra` for database, cache, storage and external protocol implementations. The README also says the data layer uses domain-prefixed tables, and that financial records, audit trails, system events and vector data are kept as separate sources of truth. That last choice is the interesting one: it means a billing query and a chat query do not contend for the same table, at the cost of joins across domains when you need a combined view.

Routing sits in a platform-model layer over upstream channels, real models, route bindings, priority, weights, circuit breaking, vendor mapping and capability configuration. Protocol adaptation covers OpenAI, Anthropic, Google/Gemini, xAI, OpenRouter and OpenAI-compatible endpoints. Heavy document extraction and OCR are optional services (Apache Tika, Docling, RapidOCR, Tesseract, Paddle OCR, MinerU, cloud OCR adapters), which is what keeps the base deployment small.

Installing DEEIX Chat with Docker Compose or pnpm

The README points to a Quick Start page at deeix.com/docs/deeix-chat/quickstart for the short path, and describes two local options. For a low-dependency trial it recommends the lightweight Docker installation; for editing source it describes running frontend and backend separately.

The Compose file in the repository pulls a published image and mounts a config file read-only. Note the port binding: it is localhost-only by default, and the comment tells you to put a reverse proxy in front for public access.

services:
  app:
    image: ${DEEIX_CHAT_IMAGE:-ghcr.io/deeix-ai/deeix-chat:latest}
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - ./config.yaml:/app/config.yaml:ro

Before starting the container you need that config file. The repository ships several examples, and the README's local development section uses the general one:

cp config.example.yaml config.yaml

For the source path, the workspace is a pnpm monorepo with Turbo. The README gives these three steps, and the default config connects to local PostgreSQL and Redis:

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

After `pnpm dev`, the README says the frontend and backend start together; `pnpm dev:web` and `pnpm dev:api` start one workspace only. The frontend reads `NEXT_PUBLIC_API_BASE_URL` for API requests, so a local run fails to reach the API if that variable does not match where the Go service is listening. The README's text is cut off mid-sentence at exactly that point, so treat the value as something to confirm in `frontend/.env.example` rather than something the README states.

Where DEEIX Chat gets thin: operations, rollback and OCR dependencies

The README documents capabilities well and procedures poorly. There is no migration guide, no rollback procedure, and no statement about what happens to in-flight requests when you swap the image tag. The Compose file mounts `./config.yaml` read-only, which means a config change requires a container restart; nothing in the repository explains whether the process validates that file at startup or fails later on first use of the affected subsystem.

Database choice is the other sharp edge. SQLite with sqlite-vec and an in-memory cache is offered as the lightweight path, and PostgreSQL with pgvector plus Redis as the production path. The README does not describe how to move data between them, and it does not say whether the two backends expose identical behaviour for vector search or for the separate financial and audit stores. If you start on SQLite and grow, the migration is your problem.

OCR is a dependency trap in the other direction. Apache Tika, Docling, RapidOCR, Tesseract, Paddle OCR and MinerU are listed as file processing options, but the README does not say which are bundled, which are separate containers, or what the LLM OCR fallback costs per page. Teams adopting this for scanned documents should price that before committing. And if all you want is a chat UI against one provider, the billing, subscription and audit machinery is dead weight you will still have to configure and secure.

How DEEIX Chat differs from LibreChat and Open WebUI

LibreChat and Open WebUI are the obvious comparisons, and the difference is the deployment shape rather than the feature list. Both of those are Node or Python applications where the chat server and the UI are separate moving parts, typically fronted by a proxy. DEEIX Chat compiles the frontend to static assets and serves them from the same Go process that handles routing, billing and audit, so a single container on `127.0.0.1:8080` is the whole product.

That has a real consequence. With LibreChat or Open WebUI you can replace the UI layer without touching the backend, and their plugin ecosystems are where most extension happens. DEEIX Chat instead puts extension behind MCP Streamable HTTP JSON-RPC and provider-native tools, and puts multi-tenant concerns (roles, subscriptions, balances, SSO) inside the core. If your requirement is a multi-provider gateway with metering and audit for an organisation, that is a better fit than bolting billing onto a chat app. If your requirement is a chat front end you can restyle freely, the compiled static bundle is the wrong trade.

Editorial conclusion

Adopt DEEIX Chat if you want one Go binary serving both the chat UI and the API, with routing, billing and audit in the same process, and you are willing to read config.full.example.yaml before touching production. Do not adopt it if you need a published migration or rollback procedure, or if your team has no Go and PostgreSQL experience. Verify first that the upstream providers you use are covered by the protocol adapters, and that the SQLite path in docker-compose.sqlite.yml is acceptable for your data volume.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes