Advanced Configuration

1. Overview

A default installation may not meet production-grade requirements. Additional operations such as TLS encryption, Instance resource definition, and external infrastructure integration are often necessary.

2. TLS Encryption

To enhance security, it is highly recommended to configure TLS. The steps in CSGHub Helm Chart are straightforward:

2.1 Prepare Certificates

Prepare your domain certificates based on your deployment method. Note that wildcard certificates (e.g., *.csghub.example.com) are required if you use multiple subdomains.

2.2 Create TLS Secret

kubectl -n csghub create secret tls csghub-tls-certs \
  --cert=fullchain.pem \
  --key=privkey.pem

2.3 Upgrade to Apply Certificates

helm upgrade --install csghub csghub/csghub \
  --namespace csghub \
  --set global.gateway.external.domain="csghub.example.com" \
  --set global.gateway.tls.enabled=true \
  --set global.gateway.tls.secretName="csghub-tls-certs"

If you use multiple independent certificates for different services, specify them as follows:

--set portal.gateway.tls.secretName="portal-tls-certs" \
--set minio.gateway.tls.secretName="minio-tls-certs" \
--set casdoor.gateway.tls.secretName="casdoor-tls-certs"

3. Instance Resource Definition

After instance readiness, defining resource specifications (flavors) is required before using GPU resources for inference or fine-tuning.

• Enterprise Edition: Add resources directly via the Admin Console under Resource Management or Computing Power Management.
• Community Edition: Initialize resource specifications directly in the backend database.

4. Using External Infrastructure

By default, CSGHub deploys built-in services (PostgreSQL, Redis, MinIO, etc.). For production, using external managed resources is recommended for better availability and performance.

4.1 Disabling Built-in Resources

Use the following logic to disable internal components:

global:<component>.enabled: false

For example, setting global.postgresql.enabled=false will stop Helm from deploying the built-in PostgreSQL.

4.2 Naming Conventions

Default database and bucket names follow the format csghub-{service}.

To override these, specify them in the local service configuration:

server:
  objectStore:
    bucket: "my-custom-bucket"

4.3 Configuration Priority

Priority	Level	Example
🥇 1	Service-level (Local)	server.objectStore.bucket
🥈 2	Global-level (Global)	global.objectStore.external.endpoint

Tips: Service-level configurations always take precedence over global configurations.

5. Configuration Examples

The following examples demonstrate how to use external resources such as PostgreSQL, Redis, MinIO, and Registry.

5.1 External PostgreSQL

global:
  postgresql:
    enabled: false
    external:
      host: "postgres.example.com"
      port: 5432
      user: "csghub"
      password: "StrongPassword"
      timezone: "Asia/Shanghai"
      sslmode: "prefer"

The following configurations are examples of the default database configurations for each resource. You can specify a new database name by modifying `database`.
casdoor:
  postgresql:
    database: "new_casdoor_database"
    
temporal:
  postgresql:
    database: "new_temporal_database"
    
server:
  postgresql:
    database: "new_server_database"
portal:
  postgresql:
    database: "new_portal_database"
dataflow:
  dataflow:
    postgresql:
      database: "new_dataflow_database"
  labelStudio:
    postgresql:
      database: "new_label_studio_database"
csgship:
  web:
    postgresql:
      database: "new_csgship_database"

5.2 External Redis

global:
  redis:
    enabled: false
    external:
      host: "redis.example.com"
      port: 6379
      password: "RedisStrongPassword"

5.3 External MinIO / S3

global:
  objectStore:
    enabled: false
    external:
      endpoint: "https://s3.amazonaws.com"
      accessKey: "AKIAxxxx"
      secretKey: "xxxx"
      region: "us-east-1"
      secure: true
      pathStyle: false
      
## The following configurations are examples of default bucket configurations for each resource. You can specify a new bucket name by modifying `bucket`.
registry:
  objectStore:
    bucket: "new-registry-bucket"
   
server:
  objectStore:
    bucket: "new-server-bucket"
    
## In addition, another bucket `{service}-public` is needed here. It should be automatically named according to the service name; custom naming is not currently supported.

## Because this bucket needs to be publicly accessible, the `-public` identifier is defined.
portal:
  objectStore:
    bucket: "new-portal-bucket"
    
runner:
  objectStore:
    bucket: "new-runner-bucket"

## csgship currently does not expose a MinIO bucket field in the chart; the object storage is shared via the global configuration.

5.4 External Registry

global:
  registry:
    enabled: false
    external:
      registry: "registry.example.com"
      repository: "csghub"
      username: "user"
      password: "pass"

5.5 External Gitaly

global:
  gitaly:
    enabled: false
    external:
      scheme: "tcp"
      host: "gitaly.example.com"
      port: 8075
      token: "gitaly_token"
      storage: "default"
      jwtSecret: "signing-key"   # shared secret for gitlab-shell <-> server JWT auth

jwtSecret defaults to signing-key and is used for JWT authentication between gitlab-shell and the server. Change it only when using an external Gitaly with a custom key.

5.6 External Dataflow

global:
  dataflow:
    enabled: false
    external:
      host: "dataflow.example.com"
      port: 80

5.7 Reference existingSecret for external Secrets

Starting with the common library chart 0.2.8, PostgreSQL / Redis / Gitaly / ObjectStore support an additional existingSecret path: when enabled=false, you can point at a pre-provisioned Kubernetes Secret and the chart will read connection info from its data keys instead of requiring plaintext credentials in values.yaml.

global:
  postgresql:
    enabled: false
    existingSecret: "my-pg-secret"
  redis:
    enabled: false
    existingSecret: "my-redis-secret"
  gitaly:
    enabled: false
    existingSecret: "my-gitaly-secret"
  objectStore:
    enabled: false
    existingSecret: "my-s3-secret"

The Secret must be pre-created in the release namespace and contain the following keys (optional ones are bracketed):

Component	Secret data keys
PostgreSQL	POSTGRES_HOST / POSTGRES_PORT / POSTGRES_USER / POSTGRES_PASSWORD / [POSTGRES_SSLMODE]
Redis	REDIS_HOST / REDIS_PORT / REDIS_PASSWORD / [REDIS_USER] / [REDIS_DATABASE]
ObjectStore	OBJECT_STORE_ENDPOINT / OBJECT_STORE_ACCESS_KEY / OBJECT_STORE_SECRET_KEY / [OBJECT_STORE_REGION] / [OBJECT_STORE_BUCKET]
Gitaly	GITALY_HOST / GITALY_PORT / GITALY_TOKEN / [GITALY_STORAGE] / [GITALY_SCHEME]
Registry	REGISTRY_HOST / [REGISTRY_REPOSITORY] / [REGISTRY_USERNAME] / [REGISTRY_PASSWORD]

A service-level existingSecret overrides the global one:

global:
  postgresql:
    enabled: false
    existingSecret: "shared-pg-secret"

portal:
  postgresql:
    existingSecret: "portal-pg-secret"  # overrides the global value

Notes:

• existingSecret and external are mutually exclusive at runtime; when existingSecret is non-empty, the chart uses the Secret values and external.* is ignored (kept only for backward compatibility).
• The database name is still defined per service by the chart, so one shared Secret can back multiple services.
• When enabled=true (built-in mode), existingSecret is ignored — the chart deploys its own instance and uses an auto-generated password.

6. Summary Table

Component	Disable Command	External Config Path	Default Naming
PostgreSQL	global.postgresql.enabled=false	global.postgresql.external	csghub_<service>
Redis	global.redis.enabled=false	global.redis.external	—
MinIO / S3	global.objectStore.enabled=false	global.objectStore.external	csghub-<service>
Registry	global.registry.enabled=false	global.registry.external	—
Gitaly	global.gitaly.enabled=false	global.gitaly.external	—
Dataflow	global.dataflow.enabled=false	global.dataflow.external	—