Configuration reference
Deployment environment variables and kubeconfig requirements for CosmicAC.
Configure a CosmicAC deployment with environment variables in .env and a kubeconfig file. For the deployment steps, see Deploy CosmicAC.
Environment variables
Set these variables in the .env file in the deployment directory.
| Variable | Description |
|---|---|
TAG | Release image tag to deploy (release-1.0.0). |
GITHUB_USER, GITHUB_PAT | GitHub Container Registry (GHCR) credentials. The PAT needs the read:packages scope. |
DOCKER_PLATFORM | Docker platform to build for (linux/amd64). |
CONTAINER_UID / CONTAINER_GID | Container user and group IDs. Use 0:0 for rootless Docker, or the host UID:GID for rootful. |
KUBECONFIG_SRC | Absolute host path to the kubeconfig file. Required. |
K8S_KUBECONFIG | Custom in-container path. Omit it to use /app/kube/config. |
K8S_NAMESPACE | Kubernetes namespace for job resources. Defaults to cosmic-ac. |
K8S_WORKER_TYPE / K8S_WORKER_ENV / K8S_WORKER_ARGS | Worker type, environment, and arguments (wrk-server-rack-kv, development, and "--rack rack-0"). |
K8S_MQ_TOPIC | Message queue topic, in the form job-workflow-<env> (job-workflow-dev). |
K8S_RACK_ID / K8S_RACK_LOCATION / K8S_GPU_PRICE | Rack ID, location, and GPU price (rack-0, IN, and the hourly price). |
BOOTSTRAP_ADMIN_EMAIL / BOOTSTRAP_ADMIN_PASSWORD | First-run UI login seeded by task bootstrap. Optional. |
BOOTSTRAP_ADMIN_ROLES | Roles for the bootstrap admin. Use * for full access. |
PROXY_AUTOBASE_KEY | Leave blank. wire or bootstrap sets it automatically. |
Kubeconfig requirements
The kubeconfig is a standard Kubernetes YAML file, passed to the deployment through KUBECONFIG_SRC. Your cluster administrator normally provides it, or you generate it with kubectl config view --raw --flatten. It must contain clusters, users, and contexts:
apiVersion: v1
kind: Config
current-context: <context-name>
clusters:
- name: <cluster-name>
cluster:
server: https://<kubernetes-api>
certificate-authority-data: <base64-ca>
users:
- name: <user-name>
user:
client-certificate-data: <base64-certificate>
client-key-data: <base64-private-key>
contexts:
- name: <context-name>
context:
cluster: <cluster-name>
user: <user-name>- Certificate-based and token-based user credentials both work.
- Credential paths such as
certificate-authority,client-certificate, andclient-keymust be inline*-datafields, not file references. - The file stays on your host and is never built into an image.