CSGHub's Docker build needs a registry in Alibaba Cloud Beijing

The builder stage pulls a Go image from a private registry

The Dockerfile opens with FROM --platform=$BUILDPLATFORM pointing at opencsg-registry.cn-beijing.cr.aliyuncs.com/opencsg_public/go-node as the builder, not the public golang image. Everything else in the file is portable: it copies the source into /myapp, sets CGO_ENABLED=0, runs go mod tidy, builds the frontend with cd frontend followed by yarn install and yarn build, then cross-compiles with GOOS and GOARCH taken from a TARGETPLATFORM argument into a single binary, csghub-portal, from ./cmd/csghub-portal. The runtime stage is bitnami/minideb with ca-certificates installed. So the build is a standard static Go binary with a Vue frontend baked in, and the one thing standing between an outside contributor and a build is where the base image lives. Cross-compiling with CGO disabled is also why the final image can be a minimal Debian rather than a Go distribution.

The module is opencsg.com/portal and the binary is csghub-portal

The go.mod file names the project differently three ways, which is the first naming puzzle. The module is opencsg.com/portal, the product is CSGHub, and the compiled artefact is csghub-portal. The command directory is cmd/csghub-portal and the binary is declared in the Dockerfile, while the environment variables all start CSGHUB_PORTAL_. So the word portal is the internal name for the web-facing service, and CSGHub is the platform around it. Anyone writing automation against this needs the artefact name rather than the module name, and anyone reading logs needs to know that a csghub-portal log line refers to the web tier rather than to asset storage. The go directive is 1.23.3, which is the minimum toolchain the module declares.

The portal is a front end to a separate csghub-server

The environment example names a service the repository does not contain. There is a block headed csghub-server API Configuration, with a comment pointing at github.com/OpenCSGs/csghub-server as the source, a base URL variable CSGHUB_PORTAL_STARHUB_BASE_URL defaulting to http://localhost:8080, and an API key CSGHUB_PORTAL_STARHUB_API_KEY whose example value is a long hex-looking string. So the portal you build from this repository does not store assets itself; it talks to a server over HTTP with a key. That split is consistent with the readme's claim of microservice submodules and standardised OpenAPIs, and it changes what a self-hosted install means, since there is at least the portal, the server, a database and an S3 endpoint. The naming is worth noting too, since the variables are called STARHUB while the product is CSGHub.

One DSN variable, two dialects, PostgreSQL or SQLite

The database configuration is two variables rather than a dialect per deployment. CSGHUB_PORTAL_DATABASE_DSN holds the data source name, and the example is a PostgreSQL URL with a postgres user, a csghub_development database and sslmode=disable. CSGHUB_PORTAL_DATABASE_DIALECT then says which driver to use, with the possible values given as pg for PostgreSQL or sqlite. That pair lines up with the Go dependencies, where Bun appears with a pgdialect, a pgdriver, a sqlitedialect and a sqliteshim, all at version 1.2.1. So SQLite is a first-class option rather than a fallback, and the presence of a shim driver is what makes the pure-Go build with CGO disabled possible on both. Object storage is separate again: five variables cover the S3 endpoint, whether to use SSL, the region, the access key id and secret, and the bucket name for public files.

Five toggles at the top of the environment file

The first block of the example environment file is a set of booleans and one port, and each one changes how the portal behaves. CSGHUB_PORTAL_ON_PREMISE is the switch between deployment models, true for on-premise and false for SaaS. CSGHUB_PORTAL_SENSITIVE_CHECK toggles sensitive content checking, which the example leaves off. CSGHUB_PORTAL_ENABLE_HTTPS forces HTTPS in site URLs. CSGHUB_PORTAL_SERVER_PORT sets the listening port, and the example value is 8090. CSGHUB_PORTAL_SUPER_USERS takes a comma-separated list of usernames with an empty default. The port matters when you line the services up: the portal example listens on 8090 while the server it calls is pointed at localhost:8080, so nothing collides by accident. Two empty variables, CSGHUB_PORTAL_SIGNUP_URL and CSGHUB_PORTAL_LOGIN_URL, are there to point at an external authentication provider's pages.

Two CI systems and a generated mocks directory

The root of the repository carries the markers of a project set up by more than one team. There is a .github/ directory and a .gitlab-ci.yml, so builds run on both platforms, and the readme's badge points at a unit_tests.yml workflow in GitHub Actions. There is .air.toml for live reloading of a Go server and makefile, lowercase, for the task runner. .mockery.yaml together with a _mocks/ directory means the test doubles are generated rather than written by hand, which is the difference between updating a mock when an interface changes and finding out later. Editor and assistant configuration is committed too, with .idea/, .vscode/, .claude/ and .codesouler/, along with .env.example and .envrc.example for the two environment workflows, direnv and a plain file. The Go source sits in cmd/, internal/ and pkg/, config/ holds configuration, and frontend/ is the Vue side that yarn builds.

Three -ce releases in three months, and no local install steps

The recent releases are v2.3.0-ce in July 2026, v2.4.0-ce in August and v2.5.0-ce in September, a monthly cadence with a suffix the readme never explains. Meanwhile the installation story is entirely off-repository. The quick start offers the free SaaS version on the OpenCSG website with its own brief guide, then sends anyone wanting practice to a hosted documentation site where the installation methods are Docker Compose and a Helm Chart, and points further reading at the OpenCSG Documentation Center. The repository's own documents are the detailed introduction, a roadmap, release notes and a development setup guide, all under docs/, plus an Aliyun marketplace listing for a hosted trial. There is no install command in the readme, and the tree's _mocks/, cmd/ and pkg/ layout means you are expected to have the toolchain before you start.

Five translated readmes, and a chat entry in four places

Localisation and community are handled with the same energy as the code. The readme exists in five languages, README_zh.md for Simplified Chinese, README_jp.md, README_kr.md and README_es.md alongside the English original, all linked from one line at the top. Community entry points are four: a Slack workspace invite, a Discord invite, the OpenCSG Community repository on GitHub, and a GuruBase page. The community repository is where the mechanics live, with a meeting process, a contribution guide in English under guidelines/, and a questions-and-issues page, so the readme is a signpost rather than a place where contribution rules are written. A demo video is embedded as a GitHub user attachment and also hosted on YouTube and Bilibili, and the roadmap and release notes are markdown files in the repository rather than release descriptions on the releases page.

Editorial conclusion

CSGHub is for organisations that need a model registry they host themselves, which the readme frames as a private on-premise version of Hugging Face with the ability to run offline. The asset story is broad, LLMs plus datasets, spaces and code, handled over a web interface, the git command line, a natural language chatbot or an SDK, and the licences are friendly at Apache 2.0. Three things to check before you commit. The build has a hard external dependency: the Dockerfile's first stage pulls a Go toolchain image from a registry hosted in Alibaba Cloud Beijing, so a first build outside that network is not a plain docker build. Second, the portal is a front end, not the whole system, and it calls a separate csghub-server through a base URL and an API key, so you are deploying at least two services plus PostgreSQL or SQLite and an S3 endpoint. Third, releases carry a -ce suffix and there are three of them in 2026 alone, v2.3.0-ce, v2.4.0-ce and v2.5.0-ce, while the readme itself documents no local install steps and points at a hosted documentation site instead.

Frequently asked questions

Official sources

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