Sdcb Chats: a self-hosted front end and gateway for 20-plus model providers

One container, one command, one local port

The quick start in the documentation is a single Docker command, and it is worth reading in full because every part of it is a decision. The container is named sdcb-chats, it restarts unless stopped, the database type is set to sqlite and the connection string points at a file inside a mounted AppData directory. The image is published as sdcb/chats:latest, and the service is published on port 8080. Once it is running, the documentation says to open http://localhost:8080 and sign in with the default account chats and the password RESET!!!, and the quick start guide under doc/zh-CN/quick-start.md covers Docker deployment, executable deployment and database configuration. The project also ships self-contained executables, and the downloads document lists the Docker image and the binaries, so the container is a convenience rather than the only route.

The Docker command mounts your Docker socket into the app

That command includes a line that deserves a second look before you run it anywhere that matters. It binds the host's Docker socket into the container, and it sets the container to run as root.

mkdir -p ./AppData && chmod 755 ./AppData && docker run --restart unless-stopped --name sdcb-chats -e DBType=sqlite -e ConnectionStrings__ChatsDB="Data Source=./AppData/chats.db" -v ./AppData:/app/AppData -v /var/run/docker.sock:/var/run/docker.sock --user 0:0 -p 8080:8080 sdcb/chats:latest

The socket mount exists so the built-in code interpreter can start sibling containers for the code and browser tools, which is a real feature rather than an accident, and the root user flag is there so the process can talk to that socket. The combination is the trade. A process with the Docker socket mounted and running as root can effectively control the host, so this deployment is only as safe as the machine under it. If you do not need the sandbox, that mount is the first thing to remove. The AppData volume is the one you must keep, since the SQLite database file lives there and losing it loses the conversations and the account list.

Several request protocols, and a gateway rather than a single provider

The positioning is a front end and an API gateway in one product, and the protocol list is what makes the gateway claim credible. The feature list names Chat Completions and Messages compatibility, support for Claude Code, and the standard protocols covering Chat Completions, Messages, Responses and Gemini, with interleaved thinking supported. The model provider document lists 22 or more mainstream providers and their support status. Alongside the text protocols there is multimodal work, with vision input and image generation, and the 1.17.0 notes add background modes for image generation with default, auto, opaque and transparent values. For a team that already has accounts with several vendors, that combination is the point, because the gateway becomes the place where provider choice, quotas and audit live rather than being scattered across separate dashboards.

Storage choices cover the database and the files separately

The storage story is split into two layers, and separating them is the right design for a chat product. Conversation and account data goes into a relational database, with SQLite, SQL Server and PostgreSQL listed as the options. Files and images go into object storage, with local storage, AWS S3, Aliyun OSS and Azure Blob named. The single command in the quick start uses SQLite with the database file on the AppData volume, which is the right starting point for a trial and the wrong one for a busy multi-user instance, and the configuration document is where the connection string and the storage keys are set. The 1.17.0 release notes also flag an upgrade requirement that is easy to miss, that SQL Server and SQLite deployments need the matching 1.17.0 database migration script to be run, which tells you the schema is versioned and the migration step is not optional.

Users, balances, rate limits and Keycloak login

The security and governance features are the part aimed at an organisation rather than a hobbyist. The feature list describes a complete user permission system, account balance control, rate limiting and audit logs, and login by Keycloak single sign-on or by SMS verification code. An account balance control is an unusual thing to find in an open source chat front end and it changes what the tool is for, because it lets you meter usage per user rather than only track it. The user management work in 1.17.0 also shows some care about real deployments, with the edit user form and the change password form split apart to improve compatibility with password managers. The other operational feature worth naming is Request Trace, a full link trace for inbound and outbound requests that the feature list says is there to locate problems quickly when a request goes wrong in either direction.

A Docker sandbox for code execution, a browser and spreadsheets

The code interpreter is listed as a Docker sandbox with a built-in browser, code execution and spreadsheet tools, and it is the reason the socket mount in the quick start command exists. For a product that talks to models which can emit code, running that code somewhere isolated is the difference between a useful feature and a remote shell. The tool listing also covers a browser inside the sandbox, which is what makes an agent that has to visit a page to answer a question possible. The cost of the design is that the sandbox is part of the same container stack, so a deployment that keeps it enabled inherits the socket exposure discussed earlier. The 1.17.0 notes also record a fix to the image endpoint appending a duplicate /v1 path, with a model validation check added and a regression test, which is the kind of detail that only shows up once people use the image generation path heavily.

A C# and TypeScript codebase with a Chinese-first documentation set

The project is written in C# and TypeScript, and the repository layout shows a conventional split with a src directory, an eng directory, a doc directory and a Chats.slnx solution file. The documentation index is worth knowing about because it is organised around what a deployer needs. The quick start covers deployment and database settings, the downloads page covers the Docker image and the executables, the model providers page lists the 22 or more services with their support status, the build guide explains how to compile and develop, the configuration page covers the parameters, and there is a release notes directory with a page per version plus a FAQ. The README itself points at a DeepWiki knowledge base for the project, and a Chinese and an English readme are both at the top level. The licence is Apache 2.0, the last push to the repository was on 2026-10-12, and the recent tags are 1.17.0 from 2026-08-27, 1.16.0 from 2026-08-22 and 1.15.0 from 2026-08-19.

Editorial conclusion

Sdcb Chats fits an organisation that has several model provider accounts and wants a single front end with one login, one balance and one set of permissions in front of them, especially when the team also needs an API gateway that speaks the common request protocols. It does not fit a deployment where you cannot change the default account password, because the documented first login is chats with the password RESET!!!, and it does not fit a host where mounting the Docker socket into the application container is not acceptable. Before you put it anywhere shared, change that password, decide whether you need the code interpreter sandbox and its socket mount at all, and read the configuration documentation for the storage and single sign-on settings before the first real conversation goes through it.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sdcb/chats on GitHub