csghub-server: two Postgres services both bind host port 5433

The quick start ships default passwords and creates world writable directories

The whole deployment is four commands, and three of them set values you will want to change.

export STARHUB_SERVER_API_TOKEN=<API token>
mkdir -m 777 gitea minio_data
curl -L https://raw.githubusercontent.com/OpenCSGs/csghub-server/main/docker-compose.yml -o docker-compose.yml
docker-compose -f docker-compose.yml up -d

`mkdir -m 777` is the line to notice. The Gitea data directory and the MinIO data directory are created with mode 777, so any local user on that host can read and write the object store and the git data. That is fine on a laptop and wrong on a shared or multi-tenant host.

The compose file repeats the pattern for credentials. The main database runs as `postgres` with the password `postgres`:

    environment:
      POSTGRES_USER: "postgres"
      POSTGRES_PASSWORD: "postgres"
      POSTGRES_MULTIPLE_DATABASES: "starhub_server,gitea,mirror"

and the auxiliary pair uses `memmachine` with `memmachine_password`, plus a Neo4j instance whose auth string is `neo4j/neo4j_password`. Four services, four default passwords, all written into the file the quick start tells you to download.

Only one password is yours to set, and it has a hard requirement: the API token must be at least 128 characters long, and every HTTP request to the server has to carry it as a Bearer token. Nothing in the quick start rotates or stores it for you, so treat the shell variable as the whole of your authentication story.

Resource guidance is a single line: 4 CPU and 8 GB of memory, tested in an Ubuntu 22 environment.

Two Postgres services publish host port 5433, so the stack cannot start as shipped

The compose file defines a `postgres` service and a `memmachine_postgres` service. Both publish the same host port for the same container port:

    ports:
      - "5433:5432"

That mapping appears under the main database and again under the memory one. Docker cannot bind one host port twice, so starting the file unchanged fails on the second service with a port conflict, and the failure arrives after the first database is already running.

This is worth stating plainly because it is not a configuration nuance. The file the quick start downloads cannot come up as written.

The same service publishes its Neo4j ports to the host rather than keeping them internal:

    environment:
      NEO4J_AUTH: "neo4j/neo4j_password"
    ports:
      - "7474:7474"
      - "7687:7687"

So the graph database's browser interface and its Bolt port are both reachable from outside the host, behind the password written in the file. Combined with the `mkdir -m 777` step, the default posture is a development configuration on every axis: world writable data directories, published database ports and four known passwords.

The main database is also configured for TimescaleDB, with `shared_preload_libraries=timescaledb` and 32 background workers, from an image that already carries that extension. That part is self-contained; the port collision is the part that stops you.

The API token variable is still called STARHUB_SERVER_API_TOKEN

The product is CSGHub Server. The environment variable that authenticates every request to it is `STARHUB_SERVER_API_TOKEN`, and the first database in the same file is created with a database named `starhub_server`.

So the internal name is still the old one, in three separate places: the shell variable you export, the database name in `POSTGRES_MULTIPLE_DATABASES`, which also lists `gitea` and `mirror`, and the compose file's own directory layout with data under `./data/memmachine/`.

This is a rename that stopped partway. It matters for anyone automating a deployment, because a secret named for the previous product will be missed by a naming convention, and because a fresh deployment that follows the README will create a database called `starhub_server` and then have to migrate it if the name ever changes.

The rest of the internal naming is consistent and worth knowing when you read the tree. There are packages for the AI gateway, the dataset viewer, accounting, moderation, notifications, mirroring, a message queue backed by a checked-in `nats-server.conf`, a log collector with a `loki-config.yaml`, a runner for deployment targets, and plugins. The dataset viewer is what backs the online preview of dataset files such as `.parquet`.

Two deployment-related files sit at the top level as well: `docker-compose.yml` for the default stack and `docker-compose-gitaly.yml` as the alternative, the second naming GitLab's Gitaly component for Git serving.

One section claims GitLab support and the roadmap says only Gitea works

The extensibility section states that different git servers are supported, naming Gitea and GitLab with an and others. The roadmap, one screen later, is more honest about the state of it: support for more git servers is checked off, but the description under that check reads that it currently supports Gitea and plans to support mainstream Git repositories in the future.

Both statements are on the same page and they do not agree. Read the second one as the accurate summary and the first as the aspiration, because the second carries the same checked-box formatting as items that are demonstrably done, such as Git LFS and S3 protocol support.

The extensibility claims that are backed by code are more concrete. LFS storage is configured flexibly, and you can choose local storage or any third-party cloud service compatible with the S3 protocol, which is what MinIO is for in the shipped file. Content moderation can be enabled on demand and pointed at any third-party moderation service, matching the feature list entry for moderation of both text and images.

The roadmap has exactly one unfinished item. Model format conversion, described as conversion of mainstream model formats, is the sole entry without a check. Everything else is marked done: more git servers, Git LFS with both command operations and web download, a dataset online viewer with Top20 or TopN loading of LFS format datasets, automatic model and dataset tagging with custom metadata, S3 and MinIO storage protocol, and one-click model deployment through integration with OpenCSG llm-inference.

So if you are planning around format conversion, plan around doing it yourself.

The English README keeps Chinese punctuation and ships four typos

The page is maintained in three languages, with English, Simplified Chinese and Japanese files beside the default one. The English text has not been fully separated from its source.

Punctuation is the clearest tell. The opening sentence about managing assets ends with an ideographic comma and a full-width period, and the Key Features heading carries a full-width colon. Those characters are correct in the Chinese and Japanese files and wrong here.

Then there are the words. The feature list reads Creation and Management of users and orgnizations, with the o missing. The demo paragraph says the video is as blew rather than as below. The contact list offers an offical discord channel and asks you to join by scaning a wechat qrcode.

None of this changes behaviour, and none of it is unusual for a translated page that is edited in place. It does matter for one specific reader: anyone using this repository as a source of terminology for their own documentation will inherit both the typos and the mixed punctuation, and the doubled forms are exactly the kind of thing that propagates once it is copied.

The architecture section on the same page is an empty container, a centred div with nothing inside it, so the diagram it refers to is not readable as text. The parts of the page that do carry information are the feature list, the roadmap checkboxes and the two quick starts.

The Makefile declares seven phony targets, defines thirteen, and make cover opens a Mac app

The declaration and the contents do not line up.

.PHONY: test lint cover mock_wire mock_gen swag migrate_local

That covers seven names. The file goes on to define `build`, `db_migrate`, `db_rollback`, `error_doc`, `error_scan` and `notify_gen` as well, none of which appear in the declaration. In practice that only matters if a file of the same name appears in the directory, which is exactly why phony targets are declared, so the omission is a small latent problem rather than a daily one.

Two targets are the same command written twice:

migrate_local:
	go run cmd/csghub-server/main.go migration migrate --config local.toml

db_migrate:
	@go run cmd/csghub-server/main.go migration migrate --config local.toml

One echoes the command, one suppresses it. Both hard-code `local.toml` rather than taking an argument, so a developer with a differently named config file edits the Makefile or bypasses it.

Coverage is the target that will fail on Linux:

cover:
	go test -coverprofile=cover.out ./...
	go tool cover -html=cover.out -o cover.html
	open cover.html

The first two steps are portable. `open` is the macOS launcher, so the last one errors on a Linux machine. The image the project targets is Ubuntu 22, which makes that a routine surprise.

Mock generation is the most interesting target. `mock_wire` runs the Google Wire injector across the component packages and then renames the generated file to a `_test.go` name, with an explicit fallback message when Wire fails. Mockery handles the rest, driven by a checked-in `.mockery.yaml` with generated files in `_mocks/`.

go.mod pins a websocket pseudo-version and a mock release candidate next to four cloud SDKs

The module declares itself at `opencsg.com/csghub-server` and requires Go 1.26.0. The dependency list is where the shape of this service becomes visible.

There are four cloud vendor SDKs: three Alibaba Cloud modules for the OpenAPI runtime, Direct Mail and SMS messaging, plus the Alibaba Cloud SDK itself, and the Huawei Cloud SDK. There is also a Lark Suite SDK, a payment library, and a HashiCorp Vault API client. Those are the pieces of a commercial registry, not of a model hub.

Two version entries are worth a second look:

	github.com/golang/mock v1.7.0-rc.1
	github.com/gorilla/websocket v1.5.4-0.20250319132907-e064f32e3674

`golang/mock` is a release candidate, pinned in the main require block rather than in a tooling file. `gorilla/websocket` is a pseudo-version, which means the build is pinned to one specific commit rather than to a tagged release, and it will not move to a newer tag without a deliberate edit.

Both are the kind of pin that is easy to leave behind and hard to notice, and both are in the same block as everything else.

The data side is also visible here. DuckDB is present through the Go bindings, a scripting library is present, and pgx covers Postgres, with minio-go for object storage and a miniredis for Redis in tests. That combination lines up with the dataset online viewer that previews LFS format data.

The project acknowledges Gin, DuckDB, MinIO and Gitea as the open source work it builds on, and the released artifacts are all suffixed `-ce`, which is the community edition line.

Editorial conclusion

csghub-server is for an operator who already runs Gitea and object storage and wants a Hugging Face style registry they control, and its extension points are real: any git server, any S3-compatible store, any content moderation service. Before deploying the shipped compose file, change three things. Two services both bind host port 5433, so one of them will fail to start, and the passwords are postgres/postgres, memmachine_password and neo4j_password in plain text. The API token variable is still named STARHUB_SERVER_API_TOKEN, which is a leftover from the earlier name of the service and will confuse any automation you write around it. Resource guidance is 4 CPU and 8 GB, tested on Ubuntu 22, and the only unfinished roadmap item is model format conversion, so treat conversion as absent.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes