CSGHub: a self-hosted LLM asset platform built around a Go portal and csghub-server
CSGHub is a brand-new open-source platform for managing LLMs, developed by the OpenCSG team. It offers both open-source and on-premise/SaaS solutions, with features comparable to Hugging Face. Gain full control over the lifecycle of LLMs, datasets, and agents, with Python SDK compatibility with Hugging Face. Join us! ⭐️
At a glance
- What is it?
- CSGHub is an Apache-2.0 platform for managing models, datasets and spaces, positioned as an on-premise alternative to Hugging Face. The repository you clone is the portal layer; the API and storage live in a separate service.
- Who is it for?
- Adopt CSGHub if you need model, dataset and space assets to stay inside your own network and you are willing to run a multi-service stack: a Go portal, csghub-server, PostgreSQL and S3-compatible storage. Do not adopt it if you want a single binary with no external dependencies, or if you only need to pull weights from a public registry.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly Vue, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 26, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What CSGHub manages that a git server does not
A plain Git server stores files. It has no notion that a directory of .safetensors files is a model with a licence, a task tag and a download count, and no notion that a dataset version should be linked to the space that consumes it. CSGHub adds that layer. According to the README, the platform handles "the entire LLM and their assets such as datasets, spaces and codes", with upload, download, storage, verification and distribution available through a web interface, the git command line, a natural language chatbot, or the separate CSGHub SDK.
The intended audience is an organisation that has decided model weights and training data should not leave its network. The README describes on-premise deployment for "secure, offline operation" and calls the product essentially "a private, on-premise version of Huggingface". That framing sets the expectation: you are not buying a better model hub, you are buying the ability to run one yourself, with your own access control and your own storage endpoints.
Portal, csghub-server and the storage behind them
The repository named csghub is not the whole platform. The .env.example file points at CSGHUB_PORTAL_STARHUB_BASE_URL=http://localhost:8080 and describes it as "The URL of the csghub-server service", with a separate repository link. So the deployment splits in two: a Go portal that serves the web UI and the Git-facing endpoints, and a csghub-server process that owns the API surface. The portal talks to it with an API key, CSGHUB_PORTAL_STARHUB_API_KEY.
The Go module is named opencsg.com/portal and its direct dependencies tell you what the portal itself does. Gin handles HTTP, bun with the pgdialect and pgdriver talks to PostgreSQL, minio-go talks to S3-compatible object storage, and cobra provides the command line. The frontend is a Vue application built by yarn during the Docker build. Persistent state therefore lives in two places: relational rows in PostgreSQL, and file content in whatever S3 endpoint you configure. The portal is stateless enough to be replaced during an upgrade, but only if those two stores are healthy.
That split is the main architectural decision to understand before you start. It also means the portal version and the csghub-server version are separate things you have to keep in step, and the README does not document a compatibility matrix between them.
Deploying CSGHub with Docker Compose or Helm
The README does not put installation commands inline. It directs readers to the official documentation, which it says currently provides installation methods using Docker Compose and Helm Chart. If you want to see the product before deploying anything, the README points to the free SaaS version on the OpenCSG website and a short quick start guide for handling models and datasets there.
For a self-hosted run, the repository does give you the configuration contract. Copy .env.example and fill it in. The minimum set that determines whether the portal comes up is the database and the upstream API.
Your first run: environment, database and port
The .env.example file is the closest thing to an install checklist in the repository. It sets CSGHUB_PORTAL_ON_PREMISE to true for a self-hosted deployment and false for SaaS, and CSGHUB_PORTAL_SERVER_PORT to 8090, which is the port the portal listens on. The database block accepts either pg or sqlite as CSGHUB_PORTAL_DATABASE_DIALECT. A PostgreSQL DSN looks like this:
CSGHUB_PORTAL_DATABASE_DIALECT=pg
CSGHUB_PORTAL_DATABASE_DSN=postgresql://postgres:postgres@localhost:5432/csghub_development?sslmode=disableThe portal also needs to know where csghub-server lives and how to authenticate to it, and it needs S3 credentials before uploads will work:
CSGHUB_PORTAL_STARHUB_BASE_URL=http://localhost:8080
CSGHUB_PORTAL_STARHUB_API_KEY=f3a7b9c1d6e5f8e2a1b5d4f9e6a2b8d7c3a4e2b1d9f6e7a8d2c5a7b4c1e3f5b8a1d4f9b7d6e2f8a5d3b1e7f9c6a8b2d1e4f7d5b6e9f2a4b3c8e1d7f995hd82hf
CSGHUB_PORTAL_S3_ENDPOINT=
CSGHUB_PORTAL_S3_BUCKET=The value shown for CSGHUB_PORTAL_STARHUB_API_KEY is the placeholder from .env.example, not a working credential. Replace it before starting anything. The S3 keys are empty in the example, so a deployment that skips them boots and then fails on the first upload. Once the portal is running on port 8090, the README says assets can be pushed and pulled through the git command line, the web interface, the chatbot, or the CSGHub SDK.
Where CSGHub stops being the right tool
The stack is heavy for what many teams actually need. If your goal is to serve inference to an application, CSGHub is not an inference server; it is an asset registry with deployment features attached. If your goal is to mirror a handful of public checkpoints onto a machine, a Git remote and a cron job will do it with far fewer moving parts.
The portal also assumes network topology that not every environment has. It needs to reach csghub-server over HTTP, and it needs S3 credentials with write access to a bucket. The .env.example S3 block (CSGHUB_PORTAL_S3_ENDPOINT, CSGHUB_PORTAL_S3_ACCESS_KEY_ID, CSGHUB_PORTAL_S3_ACCESS_KEY_SECRET, CSGHUB_PORTAL_S3_BUCKET) has empty defaults, so a half-configured deployment fails at upload time rather than at boot. The README does not document rollback for a failed upgrade, and it does not describe how the portal behaves when csghub-server is unreachable. Treat both as things you will discover in your own environment.
CSGHub against a plain Hugging Face mirror
The obvious alternative is running your own Hugging Face mirror: hf-mirror style caching, or a Git LFS server with a proxy in front of huggingface.co. The difference in approach is where the metadata lives. A mirror is a cache. It has no user accounts tied to assets, no space definitions, no annotation workflow, and no notion of a private dataset that only one team can see. CSGHub is a registry with identity and access control built in, which is why the README lists enterprise-level security and access control and multi-source data synchronisation as separate features.
The cost of that difference is operational. A mirror is one process and a disk. CSGHub is a portal, an API service, a PostgreSQL instance and an object store, each with its own upgrade path and its own failure modes. If your requirement is genuinely "keep the weights inside the firewall", the mirror gets you most of the way for a fraction of the effort. CSGHub earns its keep when the assets need owners, permissions and a lifecycle.
Release cadence, licence and what an upgrade touches
The repository is not archived, and the last push was on 2026-09-08, so it is being worked on. Recent releases are v2.4.0-ce on 2026-08-09, v2.3.0-ce on 2026-07-16 and v2.2.0-ce on 2026-06-16, roughly monthly, with the -ce suffix indicating the community edition. The README points to a separate release notes file for feature improvements and to a roadmap for future direction; neither is reproduced in the repository root.
Upgrade cost is driven by the split architecture rather than by the portal binary. The Dockerfile builds csghub-portal from ./cmd/csghub-portal and ships it in a minideb image, so replacing the portal container is cheap. What is not cheap is the database. The portal uses bun migrations against PostgreSQL, and the README does not document a downgrade path, so a release that changes schema is effectively one-way without a database backup. The same applies to the csghub-server side, which this repository does not contain.
On licensing: the repository is Apache-2.0, which permits commercial use and modification. The README also advertises an on-premise/SaaS offering from OpenCSG, so the community edition and the commercial product are distinct things. Apache-2.0 covers the code in this repository; it says nothing about the csghub-server repository, the SaaS service, or any support agreement. Check those separately before you plan a production rollout.
Editorial conclusion
Adopt CSGHub if you need model, dataset and space assets to stay inside your own network and you are willing to run a multi-service stack: a Go portal, csghub-server, PostgreSQL and S3-compatible storage. Do not adopt it if you want a single binary with no external dependencies, or if you only need to pull weights from a public registry. Before committing, verify the csghub-server version your portal release expects, confirm whether you need PostgreSQL or can run the sqlite dialect, and decide up front whether S3 credentials and the CSGHUB_PORTAL_STARHUB_API_KEY will be managed by your secret store or pasted into .env files.
Frequently asked questions
What is GitHub hub?
The question is ambiguous, but within this project's scope the relevant answer is that CSGHub is not a GitHub feature. It is an open-source platform for managing LLM assets such as models, datasets and spaces, and it can be deployed on-premise.
Does CSGHub need csghub-server running?
Yes. The .env.example sets CSGHUB_PORTAL_STARHUB_BASE_URL to a csghub-server address and CSGHUB_PORTAL_STARHUB_API_KEY to the key used to call it, and the README links to the csghub-server repository as a separate project.
Which database can CSGHub use?
The .env.example documents CSGHUB_PORTAL_DATABASE_DIALECT with possible values pg for PostgreSQL or sqlite, and CSGHUB_PORTAL_DATABASE_DSN for the connection string.
What port does the CSGHub portal listen on?
The .env.example sets CSGHUB_PORTAL_SERVER_PORT to 8090 and describes it as the listening port for the Portal service.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/opencsgs-csghub)