bbs-go: a Go and React community platform you self-host with Docker Compose

What bbs-go actually replaces

The README describes bbs-go as a lightweight community and Q&A platform for forums, knowledge bases and discussion communities. The concrete claim is scope: posts, short updates and long-form articles in one content model, with comments, replies, likes and favourites wired through all three. Tags and nodes handle organisation, and there is an in-site search layer rather than a dependency on an external search service.

Who this is for is fairly narrow and the README says so in its list of suitable scenarios: technical exchange communities, Q&A sites, internal knowledge communities, interest groups and product user communities. The common thread is a community that needs both discussion threads and a durable article surface. If you only need a mailing-list-style forum, the article and points machinery is overhead you will carry anyway.

The growth-side features are the part that distinguishes it from a plain forum. Daily check-ins, a task system split into newcomer, daily and achievement categories, points and experience rewards, level configuration, and badges are all listed as shipped capabilities. That is an engagement design, not a discussion design, and it implies you are running a community you intend to keep alive rather than a support board attached to a product.

The Go backend, the React front end, and where the data lives

The repository is a Go module named bbs-go on Go 1.26.0, with a web/ directory holding the front end. The Dockerfile makes the split explicit: a node:24-alpine stage builds the web assets with pnpm, a golang:1.26-alpine stage compiles the server, and the runtime image is node:24-alpine because the server is started through a Node entrypoint script. The web build produces two outputs, an SSR build and an SPA build, and the SPA output is copied into the Go build so the binary can serve it.

Persistence is GORM. The go.mod lists gorm.io/gorm alongside gorm.io/driver/mysql, and the top-level entries include a SQLite driver as well, plus a golang-migrate dependency and a migrations/ directory. So schema changes are versioned migrations rather than an implicit auto-migrate step, which matters when you upgrade.

Search is bleve, the Go-native full-text index, listed in go.mod. That is a deliberate choice against an external service: it keeps deployment to one process and one database, at the cost of an index that lives alongside your application data rather than in a cluster you can scale independently. The rest of the dependency list is a tour of what the platform does. Captcha libraries for two different captcha systems, OAuth2, JWT, WeChat and Alibaba Cloud and Tencent Cloud SDKs, AWS S3, IP geolocation via ip2region, and bluemonday for HTML sanitisation. That last one is the interesting entry. User-generated content is sanitised before storage or render, which is table stakes for a public community and is present here rather than left to a plugin.

Installing bbs-go with Docker Compose

The README gives two Compose files, one that brings up MySQL and one for PostgreSQL. The MySQL path downloads the compose file and starts it:

curl -fsSL https://raw.githubusercontent.com/mlogclub/bbs-go/master/docker-compose.yml -o docker-compose.yml
docker compose up -d

The compose file defines a mysql:8.4 service with a healthcheck on mysqladmin ping, and the bbs-go service declares depends_on with condition: service_healthy, so the application container waits for the database to answer before starting. The bbs-go service runs the published image mlogclub/bbs-go with a tag controlled by BBSGO_IMAGE_TAG, defaulting to latest.

Three host directories are mounted so that container recreation does not wipe state: ./docker-data/data for the config, ./docker-data/logs, and ./docker-data/uploads for the res/uploads path. The compose comments state the reason directly: bbs-go.yaml lives in /app/data, and keeping runtime files on the host means deleting or recreating the container does not reset the install configuration. If you skip the volume mounts you will redo the install wizard every time you pull a new image.

The container listens on port 3000, and the environment block sets BBSGO_ENV to prod, NODE_ENV to production, PORT to 3000 and BBSGO_SERVER_URL to http://127.0.0.1:8082. Database credentials come from variables with defaults, including BBSGO_DOCKER_MYSQL_DATABASE defaulting to bbsgo and BBSGO_DOCKER_MYSQL_USER defaulting to bbsgo. Change those before the first start, not after.

Once it is up, the README points at three URLs: the front end at http://localhost:3000, the dashboard at http://localhost:3000/dashboard, and the install wizard at http://localhost:3000/install. The wizard is the first real use. You complete it, and the platform writes its configuration into the mounted data directory.

Deployment, health checks and the rollback path

The README is unusually explicit that you should not build on a small server. It states that the project uses GitHub Actions with GHCR and Docker Hub to build images in the cloud, specifically to avoid local compilation, noting that docker build on a 2-core 4 GB machine tends to run out of resources. Builds trigger on pushes to master and on v* version tags, and a tag like v4.4.5 produces v4.4.5, 4.4.5 and latest.

Server-side deployment is a script rather than a bare compose command:

bash /opt/bbs-go/repo/deploy/remote-deploy.sh

The README says the script pulls the image, validates the compose file, recreates containers, and runs a health check for up to 90 seconds, printing container logs on failure. The corresponding compose file on the server is expected at /opt/bbs-go/docker-compose.yml with the image pointing at ghcr.io/<owner>/bbs-go:latest.

Rollback is documented, which is not always true of projects at this stage:

docker pull ghcr.io/<owner>/bbs-go:sha-<previous commit>
docker compose -f /opt/bbs-go/docker-compose.yml up -d --no-deps

Note the shape of that advice. Rollback pulls a sha-<commit> tag, not the version tag. The version tags are what the release notes announce, but the rollback path depends on commit-addressed images existing in the registry. If your workflow prunes old images, that rollback instruction stops working, and the README does not say anything about retention.

Where bbs-go is the wrong choice

The comparison table in the README is candid about one thing: real-time interaction is not the selling point. Against NodeBB, the README lists real-time interaction experience and mobile experience as the competing advantages, and positions bbs-go for teams that prefer a Go backend and a lightweight self-hosted deployment. If your community lives or dies on live chat, presence indicators and instant thread updates, you are buying against the grain.

The second limitation is structural. bbs-go is a monolith: one Go process, one database, a bleve index on local storage. That is exactly why it deploys in two commands, and it is also why you cannot scale the search tier separately from the API tier. At the scale the README targets, that is a fair trade. At the scale where you need a dedicated search cluster, it is not.

The third is operational knowledge. The deployment documentation assumes you run a server at /opt/bbs-go with a repo checkout, a compose file and a deploy script. There is no documented Kubernetes path, no Helm chart in the top-level entries, and no documented managed-hosting option. The README lists a paid commercial authorisation and paid custom development, but not hosting. If your team has no one who wants to own a Compose file and a database backup, this is the wrong shape of project regardless of features.

How bbs-go differs from Discourse, Flarum and Question2Answer

The README's own comparison is worth taking at face value because it names the trade in each direction. Discourse is described as suited to mature large communities with complex moderation workflows, with a mature ecosystem and strong review and governance tooling, and bbs-go positioned for teams that want a lighter self-hosted platform, a Go stack, and forum plus Q&A plus article publishing in one system. The real difference is not features but operational weight: Discourse is a larger system with a larger surface to run.

Flarum is the closest in spirit. The README describes it as a clean modern forum, lightweight at the core, with a flexible extension ecosystem, especially for PHP teams. The stated difference is that bbs-go ships more of the operational and growth machinery in the box: a fuller admin dashboard, a Q&A flow, article publishing for knowledge accumulation, and user growth incentives, without assembling them from extensions. That cuts both ways. Extensions let you leave out what you do not want; a built-in points and badge system is something you configure or ignore, not something you decline to install.

NodeBB is the real-time option, and Question2Answer is the pure Q&A option with a focused question model, points and rankings, and simple PHP and MySQL deployment. The distinction against Question2Answer is the clearest of the four: bbs-go is not a Q&A site, it is a community platform that includes Q&A. If questions are your entire product, Question2Answer's narrower model is not a limitation, it is less to run.

Licence, maintenance and upgrade cost

bbs-go is GPL-3.0. That is a copyleft licence, and it is the single fact most likely to end the evaluation for a commercial team. The README separately offers a paid commercial authorisation at a listed price of ￥1628, described as providing commercial use authorisation for bbs-go. Whether you need that depends on how you deploy and distribute the software, which is a question for your own counsel rather than for this article. What is worth noting is that the project is upfront that the option exists, rather than leaving commercial users to discover the licence on their own.

On activity: the repository is not archived, and the last push was on 2026-08-25. Recent releases are v4.4.6 on 2026-08-17, v4.4.5 on 2026-08-17 and v4.4.4 on 2026-08-04. That is a release cadence measured in weeks, not years, and patch versions arriving on the same day suggests quick follow-up fixes.

Upgrade cost is where you should look hardest. The version tag scheme means a v4.4.5 release produces v4.4.5, 4.4.5 and latest, and the default compose tag is latest. Following latest means every docker compose pull can move you across a schema migration, and the migrations/ directory plus golang-migrate means those migrations run against your data. The rollback instruction pulls a commit-addressed image instead. Pin BBSGO_IMAGE_TAG to a specific version rather than accepting the latest default, and confirm before each upgrade that a sha-<commit> image for your previous working version is still in the registry.

Editorial conclusion

Adopt bbs-go if you want a self-hosted forum plus Q&A plus article publishing under one admin dashboard, you are comfortable running Docker Compose and MySQL or PostgreSQL, and you accept GPL-3.0. Do not adopt it if you need real-time interaction as the core experience, or if a copyleft licence is a blocker for your distribution model. Before you commit, verify three things: whether the paid commercial authorisation at the listed price is something your organisation needs, whether the built-in en-US and zh-CN locales cover your audience, and whether the image tag you pin is one you can roll back to, since the deploy documentation rolls back by pulling a sha-<commit> tag rather than the version tag.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. mlogclub/bbs-go on GitHub
3. Project website
4. README
5. Releases