Migrating to enterprise on-prem¶

Enterprise on-prem v1

Cluster registration, customer object storage, and on-cluster inference ship in enterprise on-prem v1. If your org still uses per-class install (WireGuard on the Ray head, one setup bundle per class), that path remains supported. This page describes how to adopt the new model when you are ready.

Do I need to migrate?¶

No. Existing on-prem resource classes keep working. Migration is opt-in when you want:

Checkpoints and deployment artifacts in your S3-compatible store (not Arena cloud storage)
On-prem inference on Kubernetes you operate (after v1.0b)
One WireGuard tunnel per cluster instead of one per resource class

Stay on the current model if:

You use Docker Swarm (enterprise v1 targets Kubernetes only)
Cloud-stored checkpoints are fine for your workflows
You do not need on-cluster inference yet

What changes¶

	Current (per-class)	Enterprise (cluster)
Setup	One install bundle per resource class	Register one cluster, then add classes linked to it
WireGuard	On each Ray head	On the cluster agent pod
Storage	Arena cloud S3	Your bucket
Experiment URL	`arena-on-prem-{env}-{classId}.{on_prem_proxy_domain}`	Phase 1a: `arena-ent-train-{classId}.{on_prem_proxy_domain}`; Phase 1b: `arena-ent-train-{jobId}.{on_prem_proxy_domain}`

You can run both in the same organization: new experiments on enterprise classes, old experiments on legacy classes until you retire them.

Recommended approach: new classes¶

Safest path — run old and new workloads in parallel.

Register your cluster (org Admin: on-prem cluster page, or arena on-prem cluster register).
Install the cluster agent Helm chart from the registration bundle.
Configure your object store (endpoint, bucket, credentials in a Kubernetes Secret).
Add new resource classes linked to the cluster (use new names, e.g. gpu-l4-v2).
Install Ray on your cluster for each class — without WireGuard on the Ray head.
Start new experiments on the new classes only.
When legacy classes have no running jobs: disable them and run teardown on the old Ray stacks.

Do not convert an existing class row in place while Ray is still running the old install. Create new classes instead.

Same Kubernetes cluster, new model¶

If you want one cluster instead of parallel class sets:

Stop scheduling new jobs on legacy classes; wait for current jobs to finish.
Remove legacy Ray WireGuard installs (arena on-prem teardown per class).
Register the cluster and install the agent.
Create enterprise classes and reinstall Ray (no WireGuard in the Ray chart).
Archive legacy class rows in the UI.

Checkpoints and deployments¶

Scenario	What to expect
New training on enterprise class	Checkpoints written to your bucket; UI inventory via the cluster agent
Old experiments on legacy class	Checkpoints stay in Arena cloud storage; unchanged
Deploy inference from enterprise training	Supported when checkpoint is already in your bucket
Deploy on-prem using an old cloud-trained checkpoint	Requires an explicit export/import step (planned; not automatic today)

Arena blocks enabling on-prem deployment when the checkpoint is not already in your bucket.

Preprocessing¶

On the enterprise path, the preprocessing resource class is chosen at cluster registration, not from the global org default. Set it when you register, or update the cluster later after CPU classes exist.

Retiring legacy classes¶

Confirm no running or queued jobs on the class.
Disable the class in On-prem training cluster.
Teardown the Ray stack on your hardware (On-prem CLI).
Keep the class row for history unless your process allows deletion.

Swarm customers¶

Enterprise on-prem v1 does not add new Swarm features. Continue per-class Swarm install for training until you move workloads to Kubernetes.

More detail¶

Platform engineers and customer success: see the full playbook in the platform repo at docs/on-prem/legacy-to-enterprise-migration.md.