Skip to main content

Domain Requirements

Tip: You can use third-level domains or higher. Domain configurations must match the deployment method to ensure normal service access.

1. Domain Requirements​

Considering the convenience and scalability of CSGHub, corresponding domains must be configured during deployment. Domain requirements vary across different deployment methods as follows:

1.1 Docker Deployment​

Only one primary domain is required; all requests are routed through different ports of this domain. Example:

  • csghub.example.com: Mainly used for accessing core services such as the CSGHub main service, Registry, Label Studio, and Temporal.
  • *.csghub.example.com: Used to expose various service instances such as Spaces, model inference, and MCP.

1.2 Kubernetes Deployment​

In a Kubernetes environment, request routing is typically implemented via Ingress or Gateway using common ports (80/443). Since routing via different ports on a single domain is not feasible here, multiple domains must be configured. Example: If global.gateway.external.domain=csghub.example.com is specified during installation, the following domains will actually be needed:

  • csghub.example.com: Used for accessing the CSGHub main service, Registry, Label Studio, and Temporal.
  • casdoor.example.com: Used for accessing the IAM identity authentication service.
  • minio.example.com: Used for accessing the object storage service.
  • *.csghub.example.com: Used to expose service instances such as Spaces, model inference, and MCP.
  • csgship.example.com: If CSGShip is enabled, used to access the CSGShip console.
  • csgship-api.example.com: If CSGShip is enabled, used to access the CSGShip API service.

1.3 Independently Deployed Runner Service​

If there is an independently deployed Runner service, the following additional domains need to be configured:

  • runner.example.com: Used to expose the Runner service for the CSGHub Server to dispatch tasks.
  • loki.example.com: Used to expose the Loki service on the CSGHub side to receive logs uploaded by all Runners.
  • prometheus.example.com: Used to expose the Prometheus service on the CSGHub side to centrally manage all monitoring metrics.

1.4 Independently Deployed Dataflow Service​

If there is an independently deployed Dataflow service, the following additional domains need to be configured:

  • dataflow.example.com: Used to expose the Dataflow service.
  • label-studio.example.com: Used to expose the Label Studio service.

2. Certificate Requirements​

Domain certificates must cover all domains used under the corresponding deployment method to ensure service security. Requirements are as follows:

2.1 Docker Deployment​

The certificate must include the following two domains: csghub.example.com, *.csghub.example.com.

2.2 Kubernetes Deployment​

The certificate must include the following domains: csghub.example.com, casdoor.example.com, minio.example.com, *.csghub.example.com, csgship.example.com, csgship-api.example.com (if CSGShip is enabled).

2.3 Independently Deployed Runner Service​

The certificate must include: runner.example.com, loki.example.com, prometheus.example.com.

2.4 Independently Deployed Dataflow Service​

The certificate must include: dataflow.example.com, label-studio.example.com.

3. Supplementary Notes​

  • DNS Resolution: Domain resolution should be configured in advance. Ensure resolution is effective before deploying CSGHub to avoid service access issues.
  • Certificate Selection: It is recommended to use SSL certificates issued by formal authorities to ensure security and compatibility, avoiding the access risks associated with self-signed certificates.
  • Configuration Updates: If the domain changes in the deployment environment, the corresponding certificates and CSGHub configurations must be updated synchronously to ensure normal operation.