[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-78089":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":23,"hasPages":23,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":26,"readmeContent":27,"aiSummary":28,"trendingCount":16,"starSnapshotCount":16,"syncStatus":29,"lastSyncTime":30,"discoverSource":31},78089,"DEEIX-Chat","DEEIX-AI\u002FDEEIX-Chat","DEEIX-AI","An enterprise AI workspace for model routing, multimodal chat, files, tools, billing, identity, and operations.","https:\u002F\u002Fdeeix.com",null,"Go",469,59,1,4,0,5,250,422,113,5.33,"Apache License 2.0",false,"main",[],"2026-06-12 02:03:46","\u003Cp align=\"center\">\n  \u003Cpicture>\n    \u003Csource media=\"(prefers-color-scheme: dark)\" srcset=\".\u002Ffrontend\u002Fpublic\u002Flogo-white.svg\" \u002F>\n    \u003Cimg src=\".\u002Ffrontend\u002Fpublic\u002Flogo-black.svg\" alt=\"DEEIX Chat\" width=\"160\" \u002F>\n  \u003C\u002Fpicture>\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  An enterprise AI workspace for model routing, multimodal chat, files, tools, billing, identity, and operations.\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  English | \u003Ca href=\".\u002FREADME.zh-CN.md\">简体中文\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  \u003Ca href=\"https:\u002F\u002Fdeeix.com\">\u003Cimg alt=\"Website\" src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FWebsite-deeix.com-black\" \u002F>\u003C\u002Fa>\n  \u003Ca href=\"https:\u002F\u002Fwww.apache.org\u002Flicenses\u002FLICENSE-2.0\">\u003Cimg alt=\"License\" src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FLicense-Apache%202.0-blue\" \u002F>\u003C\u002Fa>\n  \u003Cimg alt=\"Next.js\" src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FNext.js-16-black\" \u002F>\n  \u003Cimg alt=\"React\" src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FReact-19-149eca\" \u002F>\n  \u003Cimg alt=\"Go\" src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FGo-1.25-00add8\" \u002F>\n\u003C\u002Fp>\n\n## Overview\n\nDEEIX Chat gives teams a unified workspace for working with multiple AI models and providers. It combines multimodal chat, model routing, file and RAG workflows, MCP tools, usage billing, identity, audit logs, and operational controls in one product.\n\nThe architecture is designed for simple deployment, efficient static delivery, and a predictable Go runtime footprint. The admin console centralizes upstream channels, platform model names, routing priority, pricing, subscriptions, users, and security policies, while the conversation workspace keeps the user experience stable and focused.\n\n![DEEIX Chat workspace](.\u002Ffrontend\u002Fpublic\u002FDEEIX-Chat.jpg)\n\n## Features\n\n| Area | Capabilities |\n| --- | --- |\n| Conversations | Multi-branch chat, streaming, retries, edits, feedback, sharing, cloned shared conversations, rich markdown rendering, file cards, model metadata, usage details, and execution traces. |\n| Media generation | Dedicated image generation and image edit flow with task-aware routing, OpenAI Images-compatible protocols, generated file storage, preview, download, and run history separated from text chat. |\n| Model control plane | Platform model catalog, upstream channels, real upstream models, route bindings, priority and weight routing, model capability JSON, display ordering, vendor mapping, automatic icons, and circuit breaker state. |\n| Provider protocols | OpenAI Responses and Chat Completions, OpenAI Images, Anthropic Messages, Google\u002FGemini Generate Content, xAI Responses, OpenRouter defaults, and custom OpenAI-compatible routes. |\n| Request governance | Protocol-aware request assembly, user option allowlists and denylists, system-protected fields, previous-response continuation where supported, and context snapshots for review. |\n| Files and RAG | File upload, preview, download, deletion, quota control, MIME detection, text extraction, OCR, full-context injection, image context, chunking, embeddings, and semantic retrieval. |\n| Memory and context | Message-window truncation, token-budget truncation, context compression, conversation memory, long-term user memory, RAG evidence records, and prompt trace inspection. |\n| Tools | Admin-managed MCP servers, tool discovery, per-tool enablement, user-side tool selection, execution limits, retries, trace rendering, and tool result handling. |\n| Billing and payments | Subscription plans, top-ups, balances, token\u002Fcall\u002Fduration\u002Ftiered model pricing, free models, prepaid thresholds, usage ledgers, billing snapshots, Stripe Checkout, EPay, and webhook validation. |\n| Identity and security | Local login, registration, session management, HttpOnly refresh cookies, 2FA\u002FTOTP, recovery codes, trusted devices, SSO\u002FOIDC\u002FOAuth providers, contact verification, timezone, and locale. |\n| Administration | Users, roles, auth providers, upstreams, platform models, route bindings, model pricing, subscriptions, balances, usage logs, audit logs, auth events, system events, and runtime settings. |\n| Operations | Efficient static delivery, predictable Go runtime footprint, Docker builds, single-runtime frontend\u002FAPI serving, Swagger docs, structured logs, request IDs, Redis caching, PostgreSQL pgvector, optional GeoIP, optional OpenTelemetry, and S3-compatible storage. |\n\n\u003Cp>\n  \u003Cimg src=\".\u002Ffrontend\u002Fpublic\u002FDEEIX-Chat-Image.png\" alt=\"DEEIX Chat image generation\" width=\"32%\" \u002F>\n  \u003Cimg src=\".\u002Ffrontend\u002Fpublic\u002FDEEIX-Chat-Dark.png\" alt=\"DEEIX Chat dark mode\" width=\"32%\" \u002F>\n  \u003Cimg src=\".\u002Ffrontend\u002Fpublic\u002FDEEIX-Chat-Usage.png\" alt=\"DEEIX Chat usage and billing\" width=\"32%\" \u002F>\n\u003C\u002Fp>\n\n## Architecture\n\n```text\nfrontend\u002F  Next.js App Router web application\nbackend\u002F   Go API service, domain\u002Fapplication layers, infra adapters, Swagger docs\ndocker\u002F    Optional document extraction and OCR services\n```\n\nBackend code follows a layered structure:\n\n```text\ncmd -> internal\u002Fcli -> internal\u002Fapp\ntransport\u002Fhttp -> application -> repository interfaces -> infra implementations\ndomain -> shared domain types and constants\npkg -> dependency-free technical helpers\n```\n\nThe database uses domain-prefixed tables for identity, LLM routing, billing, conversations, files, RAG, settings, tools, audit logs, and system events. Financial records, audit trails, system events, and high-growth vector data are kept as separate sources of truth.\n\n## Tech Stack\n\n- Frontend: Next.js 16, React 19, TypeScript, Tailwind CSS, shadcn\u002Fui-style components, Radix\u002FBase UI, Streamdown, KaTeX, Mermaid, Recharts, Motion\n- Backend: Go 1.25, Gin, Gorm, PostgreSQL, pgvector, Redis, Swagger, OpenTelemetry, Zap\n- Storage: local filesystem or S3-compatible object storage\n- File processing: built-in extractors, Apache Tika, Docling, RapidOCR, Tesseract OCR, Paddle OCR, cloud OCR adapters, MinerU, and LLM OCR fallback\n- Tooling: MCP Streamable HTTP JSON-RPC\n- Runtime: Docker, Docker Compose, PostgreSQL, Redis\n\n## Quick Start\n\n### Local Development\n\n```bash\ncp config.example.yaml config.yaml\ncd backend\nmake run\n```\n\n```bash\ncd frontend\npnpm install\ncp .env.example .env.local\npnpm dev\n```\n\nURLs: frontend `http:\u002F\u002Flocalhost:3000`, API `http:\u002F\u002Flocalhost:8080`, Swagger `http:\u002F\u002Flocalhost:8080\u002Fswagger\u002Findex.html`.\n\nThe frontend uses `NEXT_PUBLIC_API_BASE_URL` for API requests. For local development, set it in `frontend\u002F.env.local`:\n\n```env\nNEXT_PUBLIC_API_BASE_URL=http:\u002F\u002F127.0.0.1:8080\n```\n\nIf omitted, local development defaults to `localhost:8080`; same-origin deployments use the current origin.\n\n### Docker Deployment\n\nPriority: `environment variables > config.yaml > built-in defaults`.\n\n`APP_ENV` accepts `dev`\u002F`development` and `prod`\u002F`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.\n\n#### Lightweight Start\n\nStarts only the `app` container. PostgreSQL and Redis must be provided externally. Use this when database and cache services already exist.\n\n```bash\ncp config.docker.example.yaml config.yaml\n# Edit database.postgres.dsn and database.redis.*.\ndocker compose up -d\n```\n\n#### Full Stack Start\n\nStarts `app`, `postgres`, and `redis`. Use this for local evaluation, development smoke tests, or single-machine deployments without external services.\n\n```bash\ncp config.docker.example.yaml config.yaml\ndocker compose -f docker-compose.full.yml up -d\n```\n\nThe default application image is `ghcr.io\u002Fdeeix-ai\u002Fdeeix-chat:latest`. Override it with `DEEIX_CHAT_IMAGE` when testing a custom build:\n\n```bash\nDEEIX_CHAT_IMAGE=deeix-chat:local docker compose up -d --build\n```\n\nDocker URL: `http:\u002F\u002Flocalhost:8080`. Keep the Docker `server` section unchanged unless changing ports or public domains; then update compose ports, public URLs, and CORS together.\n\n#### Separated Deployment\n\nUse this mode when the frontend and backend are served from different public origins, for example `https:\u002F\u002Fchat.example.com` and `https:\u002F\u002Fapi.example.com`.\n\n1. Configure public URLs.\n\n   - Frontend build variable: `NEXT_PUBLIC_API_BASE_URL=https:\u002F\u002Fapi.example.com`\n   - Backend config: `server.public_api_base_url=https:\u002F\u002Fapi.example.com`\n   - Backend config: `server.public_web_base_url=https:\u002F\u002Fchat.example.com`\n   - Backend config: `server.cors_allow_origin=https:\u002F\u002Fchat.example.com`\n\n   For Docker image builds, pass the frontend API URL at build time:\n\n   ```bash\n   docker build --build-arg NEXT_PUBLIC_API_BASE_URL=https:\u002F\u002Fapi.example.com -t deeix-chat .\n   ```\n\n2. Build and publish the frontend.\n\n   ```bash\n   cd frontend\n   pnpm install\n   NEXT_PUBLIC_API_BASE_URL=https:\u002F\u002Fapi.example.com pnpm build\n   ```\n\n   The static output is `frontend\u002Fout`. Serve it with Nginx, CDN, object storage, or any static web server. To let the Go backend serve the frontend, place `frontend\u002Fout` under `server.frontend_dist_dir`; the Docker image defaults to `\u002Fapp\u002Ffrontend\u002Fout`.\n\n3. Apply CDN rules.\n\n   | Path | Rule |\n   | --- | --- |\n   | `\u002F_next\u002Fstatic\u002F*` | Cache for 1 year with immutable assets enabled. |\n   | `\u002Flogo*.svg`, `\u002F*.ico`, `\u002F*.png`, `\u002F*.jpg`, `\u002F*.webp`, `\u002F*.woff2` | Cache for 1 day to 30 days. |\n   | `\u002F`, `\u002F*.html`, `\u002Fchat*`, `\u002Frecent*`, `\u002Ffiles*`, `\u002Fsetting*`, `\u002Fadmin*`, `\u002Fshare*` | Do not long-cache. Use `no-cache` or a short TTL. |\n   | `\u002Fapi\u002F*`, `\u002Fhealthz`, `\u002Freadyz`, `\u002Fswagger\u002F*` | Bypass CDN cache and forward all request headers, methods, query strings, and request bodies. |\n\n   If the CDN serves `frontend\u002Fout` from object storage, enable route fallback so clean URLs resolve to their exported `index.html` files, for example `\u002Fchat` -> `\u002Fchat\u002Findex.html`.\n\n4. Configure Stripe Webhook if Stripe is enabled.\n\n   Add this endpoint in Stripe Dashboard:\n\n   ```text\n   https:\u002F\u002Fapi.example.com\u002Fapi\u002Fv1\u002Fbilling\u002Fpayments\u002Fstripe\u002Fwebhook\n   ```\n\n   Enable the `checkout.session.completed` event and paste the generated `whsec_...` signing secret into Admin -> Billing -> Payment settings -> Stripe Webhook Secret. This endpoint must bypass CDN cache and preserve the raw request body plus the `Stripe-Signature` header.\n\n## Main Routes\n\n- `\u002Fchat` - conversation workspace\n- `\u002Fshare` - public conversation snapshot page\n- `\u002Frecent` - recent conversations, share status, starred and archived states\n- `\u002Ffiles` - file manager\n- `\u002Fsetting` - user account, subscription, preferences, security settings, and product information\n- `\u002Fadmin` - administration console\n\n## Common Commands\n\nBackend:\n\n```bash\ncd backend\ngo build .\u002Fcmd\u002Fserver\ngo test .\u002F...\ngo vet .\u002F...\nmake swagger\n```\n\nFrontend:\n\n```bash\ncd frontend\npnpm lint\npnpm build\n```\n\n## Configuration\n\nStatic infrastructure configuration is loaded from the repository-level `config.yaml` and can be overridden by environment variables. Runtime business settings are stored in `system_settings` and managed from the admin console.\n\nFrontend build-time variables:\n\n| Variable | Purpose |\n| --- | --- |\n| `NEXT_PUBLIC_API_BASE_URL` | Browser API base URL; set in `frontend\u002F.env.local` for local dev or at build time for separated deployment. |\n\nCommon backend environment variables:\n\n| Variable | Purpose |\n| --- | --- |\n| `APP_ENV` | Runtime environment. Accepts `dev`\u002F`development` and `prod`\u002F`production`; omitted values default to `prod`. |\n| `HTTP_PORT` | API\u002Fruntime port. |\n| `JWT_SECRET` | JWT signing secret. Must be strong in production. |\n| `DATA_ENCRYPTION_KEY` | Key material for encrypted secrets such as upstream API keys, SSO client secrets, MCP tokens, and TOTP secrets. |\n| `POSTGRES_DSN` | PostgreSQL DSN. |\n| `REDIS_ADDR`, `REDIS_PASSWORD`, `REDIS_DB` | Redis connection settings. |\n| `STORAGE_BACKEND` | `local` or `s3`. |\n| `STORAGE_ROOT_DIR` | Local storage root. |\n| `STORAGE_S3_ENDPOINT`, `STORAGE_S3_REGION`, `STORAGE_S3_BUCKET`, `STORAGE_S3_PREFIX`, `STORAGE_S3_ACCESS_KEY_ID`, `STORAGE_S3_SECRET_ACCESS_KEY` | S3-compatible storage settings. |\n| `PUBLIC_API_BASE_URL`, `PUBLIC_WEB_BASE_URL` | Public URLs used for links and callbacks. |\n| `GEOIP_PROVIDER` | GeoIP provider. The default `ipwhois` uses the built-in public endpoint. |\n| `OTEL_ENABLED`, `OTEL_EXPORTER_OTLP_ENDPOINT`, `OTEL_EXPORTER_OTLP_HEADERS`, `OTEL_EXPORTER_OTLP_INSECURE`, `OTEL_TRACES_SAMPLER_ARG`, `OTEL_SAMPLING_RATE` | OpenTelemetry tracing settings. |\n\nProduction mode rejects unsafe default secrets, weak encryption keys, wildcard CORS, and non-HTTPS public URLs.\n\nThe initial superadmin username is `admin`. When the database has no superadmin account, the backend generates a random password and prints it once in the startup logs while creating the account. The first login forces changing the username and password; later changes are managed from the account flow, not from `config.yaml`.\n\nTo retrieve the initial admin password, inspect the backend logs from the first startup and search for `bootstrap superadmin created`; the `username` and `password` fields are the initial login credentials. If a superadmin already exists in the database, the service does not regenerate or print this password again.\n\n## Security Notes\n\n- User passwords are hashed with bcrypt.\n- Refresh tokens and recovery-style secrets are stored as hashes.\n- Upstream API keys, SSO client secrets, MCP auth tokens, sensitive settings, and TOTP secrets are encrypted with AES-GCM using `DATA_ENCRYPTION_KEY`.\n- Access tokens are short-lived and held client-side in memory; refresh tokens are issued through HttpOnly cookies.\n- 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.\n\n## Optional Services\n\nThe compose files below attach to `deeix-chat-network`. Create it with `docker network create deeix-chat-network`, or start the root compose stack once before launching these services.\n\nApache Tika:\n\n```bash\ndocker compose -f docker\u002Ftika\u002Fdocker-compose.yml up -d\n```\n\nTesseract OCR:\n\n```bash\ndocker compose -f docker\u002Ftesseract\u002Fdocker-compose.yml up -d --build\n```\n\nDocling:\n\n```bash\ndocker compose -f docker\u002Fdocling\u002Fdocker-compose.yml up -d --build\n```\n\nRapidOCR:\n\n```bash\ndocker build -t deeix-chat-rapidocr .\u002Fdocker\u002Frapidocr\n```\n\nThese services are optional. The admin file settings decide which extraction or OCR engine is active.\n\n## Documentation\n\n- Backend guide: [backend\u002FREADME.md](.\u002Fbackend\u002FREADME.md)\n- Backend standards: [backend\u002Fdocs\u002FREADME.md](.\u002Fbackend\u002Fdocs\u002FREADME.md)\n- Frontend guide: [frontend\u002FREADME.md](.\u002Ffrontend\u002FREADME.md)\n- Contributing: [CONTRIBUTING.md](.\u002FCONTRIBUTING.md)\n- Security policy: [SECURITY.md](.\u002FSECURITY.md)\n- Swagger UI: `http:\u002F\u002Flocalhost:8080\u002Fswagger\u002Findex.html`\n\n## Acknowledgements\n\nDEEIX Chat is built on the open-source ecosystem. Thanks to all maintainers and communities in the AI tooling ecosystem.\n\n- [Next.js](https:\u002F\u002Fnextjs.org)\n- [Go](https:\u002F\u002Fgo.dev)\n- [LINUX DO](https:\u002F\u002Flinux.do)\n\n## Contact & Community\n\n- Email: [support@deeix.com](mailto:support@deeix.com)\n- Telegram: [t.me\u002Fdeeix_chat](https:\u002F\u002Ft.me\u002Fdeeix_chat)\n\n## License\n\nDEEIX Chat is licensed under the [Apache License 2.0](.\u002FLICENSE).\n","DEEIX Chat 是一个面向企业的AI工作空间，支持模型路由、多模态聊天、文件管理、工具集成、计费系统、身份验证和运营管理。其核心功能包括多分支聊天、媒体生成、模型控制平面、提供者协议兼容性、请求治理以及文件与检索增强生成（RAG）处理。技术上，它采用了Go语言开发，并结合了Next.js和React框架来构建前端界面，确保高效部署与静态交付。该平台适合需要整合多种AI服务的企业使用，特别是在希望简化AI应用流程、提高团队协作效率及维护统一操作环境的场景下尤为适用。",2,"2026-06-11 03:56:25","CREATED_QUERY"]