Deployment options

Four backends: local, node, kuberay, slurm

The console is one control-plane process. Where training containers run is a property of the Fleet a job is placed on, so one console can carry several backends at once (see Fleets); FORGE_DEFAULT_FLEET_KIND only says which one to seed at first start. User commands stay the same. There is no runtime fallback if the chosen backend is misconfigured.

Comparison

	local	node	kuberay	slurm
Training vehicle	Docker on the console host	Docker on a remote node (forgelet)	K8s RayJob (head + workers)	slurmrestd allocation (Enroot/Pyxis or Apptainer)
Scale	One node, 1–8 GPUs	Many single-node jobs	Multi-node	Multi-node HPC
Multi-node gang	No	No (Phase 1; gang is later)	Yes	Yes (srun + Ray)
Heterogeneous multi-pool	No	No	Yes (worker groups)	Yes (hetjob + constraint)
Job code	Host directory mount	Shared storage (FORGE_STORAGE_ROOT)	Object storage + in-container bootstrap	Shared storage (FORGE_STORAGE_ROOT)
Playground	Yes	No	Yes (vLLM Pod)	No
Extra deps	Docker + NVIDIA Container Toolkit	Per-node daemon + shared disk	K8s + KubeRay + object storage	slurmrestd (JWT) + container runtime
Where the console runs	Same machine as the GPUs	Anywhere that can reach agents and the shared disk	In-cluster or with a kube token	Anywhere that can reach slurmrestd and the shared disk

How to choose

• One box: local. Fewest moving parts.
• Two to eight machines, no K8s and no Slurm: agent. Console no longer needs the Docker socket.
• Existing Kubernetes: kuberay. One RayCluster per job, K8s reclaims it.
• Existing Slurm: slurm. The platform is the submit and observe layer; the site scheduler still owns the queue.

Pages

Shared install

Console process, database, object storage, reverse proxy

Fleets

Registering machines, join tokens, drain, liveness

local

Single-node Docker

node

Bare-metal machines running forgelet

kuberay

Operator, RBAC, job packages

slurm

slurmrestd, runtime profiles, hetjob