AprilNEA/AChat: A Self-Hosted AI Chat Platform for Teams, Built on Postgres and ElectricSQL

The problem AChat targets: team AI conversations that live on someone else's servers

Most people who use an AI assistant do it through a personal account. The conversation history sits with the model provider, the billing is per seat, and there is no shared record of what the team asked or what the model answered. AChat is aimed at the version of that problem where a group, not an individual, needs the record. The README lists centralized AI conversation management, organized conversation history, team collaboration with roles and permissions, and content moderation as main features. It also lists built-in commercial support, which the README describes as integrated tools for AI usage billing, payment, and cost management. That combination tells you the intended buyer: an organization that wants to hand out AI access to staff and then meter, review and archive it. The topics list on the repository (agent, chatbot, llm-client, self-hosted, enterprise-solutions) points the same direction. If you are one person who wants a nicer chat window, the feature list is mostly overhead.

What the docker-compose.yaml reveals about AChat's architecture

The repository root contains docker-compose.yaml, and it is the most concrete architectural document in what the project publishes. It defines five services. Postgres runs on the timescale/timescaledb-ha image, pinned to pg17 by default through the POSTGRES_VERSION variable, with user, password and database all defaulting to postgres. Electric, the sync engine from ElectricSQL, connects to that Postgres instance with ELECTRIC_INSECURE set to true, and the file carries a comment stating that insecure mode is not suitable for production and should only be used in development or if the Electric API has otherwise been secured. Redis runs with append-only persistence enabled. Inngest runs as a background job service, started with a command that points its SDK URL at host.docker.internal:3001/api/inngest, which implies the application itself is expected to listen on port 3001 on the host. MinIO provides object storage, with root credentials defaulting to minioadmin. The dependency set in package.json matches this shape: hono for the HTTP layer, drizzle-orm and pg for the database, react 19 for the frontend, zod for validation. The monorepo is managed with pnpm workspaces and turbo, and the package name is achat at version 4.0.0. That version number is worth pausing on, because the most recent tagged release in the repository is v3.2.4 from 2023-12-27, while package.json on the default branch already declares 4.0.0. The releases and the code are on different tracks.

Installing AChat: what the README gives you and what it does not

The README's Start section is one line: it directs you to the documentation at manual.sku.moe for configuration and installation. There is no install command in the README itself. What the repository does give you is docker-compose.yaml, so the practical starting point is that file. Copy it, then create a .env alongside it, because the compose file reads POSTGRES_VERSION, POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB, REDIS_IMAGE, INNGEST_IMAGE and MINIO_IMAGE with defaults. If you want the defaults, you can start without an .env at all:

docker compose up -d

The compose file exposes ports rather than publishing them, so the services are reachable from other containers on the same network but not from your host. For the application to be useful you will need to publish the port that the Inngest command already assumes, 3001, and the MinIO console on 9001 if you want the web UI. Working from the repository layout, the application is built with pnpm and turbo. The root package.json defines the scripts:

pnpm install
pnpm build
pnpm dev

pnpm dev runs turbo run dev --parallel, which starts every workspace package in watch mode. pnpm build runs turbo run build. The repository pins Node through .node-version, so check that file before installing if your environment manager does not read it automatically. What you should see after a successful compose start is five containers: achat-postgres, achat-redis, achat-inngest, achat-minio, and the Electric service. What the README does not tell you is what to open in a browser, which environment variables the application itself needs beyond the compose defaults, or how to create the first account. For those, the manual site is the only documented source.

The licence file and the releases page disagree with the README's badge

Three sources in this repository give three different answers about licensing. The README renders a GitHub license badge. The root package.json declares "license": "MIT". The repository metadata reports NOASSERTION, which is GitHub's way of saying it could not classify the LICENSE.md file automatically. NOASSERTION is not a finding that the project is unlicensed; it means the file's text does not match a standard template closely enough for the classifier. The practical consequence is that package.json is a declaration by the author, not a legal instrument, and the operative text is LICENSE.md. If you plan to redistribute AChat, host it for other organizations, or embed it in a product, read LICENSE.md rather than trusting the badge or the package field. This article is not legal advice, and the discrepancy is exactly the kind of thing that needs a human reading the file.

Where AChat is the wrong tool

The version table in the README is the clearest warning in the whole document. V4, on the canary branch, is marked Under Development. V3 is No longer updated. V2 is Deprecated, with the note Flawed design. V1 is No longer updated, with the note Redis database, less scalable. The default branch is canary, which is the v4 branch, and package.json there says 4.0.0. So the code you get by cloning the default branch is the branch the README itself labels as under development, while the newest tagged release, v3.2.4, is from 2023-12-27 and belongs to a line the README says is no longer updated. That is a real tension for anyone planning a deployment. If you need a stable, released artifact with a version number you can pin, this repository does not currently offer one that matches the default branch. The last push to the repository was on 2026-04-17, so there is recent activity, but activity on a branch the project calls under development is not the same as a supported release. A second limitation is operational weight. Five services, including a Postgres variant built for time-series workloads, a sync engine, a job runner and an object store, is a lot of surface for a chat tool. If your team is small, or if nobody owns the Postgres instance, a hosted assistant will cost less in attention. Third, the README does not document rollback or upgrade steps between versions, and the version table shows that the project has already refactored its stack more than once. Treat cross-version migration as uncharted.

AChat compared with a plain reverse proxy in front of a model API

The obvious alternative for a team that wants shared AI access is not another chat product. It is a thin internal service: a reverse proxy or small gateway in front of a model provider's API, with a shared key and a log table. That approach gives you one thing AChat does not: it is small enough to read in an afternoon. You control exactly which requests go out and what gets logged, and there is no sync engine, no job runner and no object store to operate. What you lose is everything AChat's feature list names. There is no conversation history UI, no roles or permissions model, no content moderation layer, and no billing or cost management. If your requirement is genuinely just shared credentials and a request log, the proxy is the better fit and AChat is over-engineered. If your requirement is that staff can revisit their own past conversations, that managers can see usage, and that someone can review what was said, then you are rebuilding AChat's feature list from scratch, and the comparison changes. The decision hinges on whether conversation history is a product feature for you or an incidental byproduct.

Maintenance and upgrade cost

Running AChat means running five stateful or semi-stateful services. The compose file gives each of Postgres, Redis, Inngest and MinIO a named volume, so backups are your responsibility and they are spread across four stores rather than one. Electric connects directly to Postgres with a connection string that includes sslmode=disable in the compose defaults, which is fine inside a private Docker network and not fine if you expose that port. The Inngest service is configured with a host.docker.internal URL, which is a development convenience and behaves differently depending on your Docker platform. On upgrade cost, the published documentation is thin: the README does not document rollback, and the update log lives on the external manual site. The release history shows v3.2.2, v3.2.3 and v3.2.4 landing roughly a week apart in December 2023, then nothing tagged since. That cadence, followed by a long gap and a jump to a 4.0.0 package version on an unreleased branch, suggests the project's own upgrade path has been discontinuous. Budget for reading the diff between branches rather than following a changelog.

Editorial conclusion

Adopt AChat if you want team AI conversations inside your own network and you are comfortable reading docker-compose.yaml and a separate manual site, because the README will not walk you through it. Skip it if you need a single-binary install or a documented upgrade path, since the README does not document either. Before committing, verify three things: which branch you are deploying (canary is v4 and the default branch), whether the LICENSE.md terms match how you plan to redistribute, and whether the docker-compose.yaml service set (Postgres, Electric, Redis, Inngest, MinIO) fits your operational budget.

Frequently asked questions

Official sources

1. AprilNEA/AChat on GitHub
2. Issues
3. Project website
4. README
5. Releases