Migrating to enterprise BYOC¶
For orgs with leftover per-class classes
Bring your own compute now works one way: register a cluster, install the Arena agent, then add resource classes to it. If your org still has classes from the older per-class install (WireGuard on the Ray head, one setup bundle per class), this page explains where they stand and how to move across.
Where leftover classes stand¶
Leftover per-class classes are not offered for new experiments: the Resources picker and the class table both list only classes that belong to a registered cluster. Treat them as history — they cover the jobs that already ran on them, and the API can still address them.
To run anything new, register a cluster and add classes to it (Install a cluster).
Moving across also gets you:
Checkpoints and deployment artifacts in your S3-compatible store (not Arena cloud storage)
BYOC inference on Kubernetes you operate (self-managed, or cloud Kubernetes such as EKS, GKE, or Nebius)
One tunnel per cluster instead of one per resource class
What changes¶
Leftover (per-class) |
Current (cluster) |
|
|---|---|---|
Setup |
One install bundle per resource class |
Register one cluster, then add classes linked to it |
Tunnel |
On each Ray head |
On the cluster agent pod |
Storage |
Arena cloud S3 |
Your bucket |
New experiments |
Not available |
Available once the cluster is Connected |
Both sets of rows can sit in the same organization while old jobs finish; only cluster-linked classes accept new runs.
Training hostnames follow the same shape on both paths (arena-on-prem-… on the leftover path, arena-ent-train-… on the current one). Those are DNS names in your environment, not labels you will see in Arena.
Recommended approach: new classes¶
Safest path — let old jobs finish while new ones run on the cluster.
Register your cluster (org Admin: Bring your own compute, or
arena cluster register).Install the cluster agent with the CLI command, Helm values, or install package from Install.
Configure your object store (endpoint, bucket, credentials in a Kubernetes Secret in the
arenanamespace).Add resource classes linked to the cluster (use new names, e.g.
gpu-l4-v2). The agent provisions Ray for each one.Start new experiments on those classes.
When the leftover classes have no running jobs, run teardown on their old Ray stacks.
Do not try to convert an existing class row in place while Ray is still running the old install. Create classes on the cluster instead.
Same Kubernetes cluster¶
If you want to reuse the hardware the leftover classes run on:
Stop starting jobs on the leftover classes; wait for current jobs to finish.
Remove the old per-class Ray installs on your hardware, one per class.
Register the cluster and install the agent.
Add classes to the cluster; the agent provisions Ray for them.
Checkpoints and deployments¶
Scenario |
What to expect |
|---|---|
New training on a cluster class |
Checkpoints written to your bucket; inventory shown in Arena via the cluster agent |
Old experiments on a leftover class |
Checkpoints stay in Arena cloud storage; unchanged |
Deploy inference from cluster training |
Supported when checkpoint is already in your bucket |
Deploy BYOC using an old cloud-trained checkpoint |
Requires an explicit export/import step (planned; not automatic today) |
Arena blocks enabling BYOC deployment when the checkpoint is not already in your bucket.
Preprocessing¶
The preprocessing resource class is chosen at cluster registration, not from the global org default. Set Preprocessing resource class under Advanced when you register, or edit the cluster later once CPU classes exist.
Retiring leftover classes¶
Confirm no running or queued jobs on the class.
Remove the Ray stack on your hardware.
Keep the row for history unless your process allows deletion.
More detail¶
Cutting over leftover classes on shared hardware can need a per-org plan. Contact AgileRL and we will work through it with you.