Custom environments

Custom environments are Python Gymnasium (or compatible) code you upload to Arena, validate in a sandbox, and version like source control. Open them from Environments in the sidebar.

Create a new environment

Use New environment on the overview page. The modal has five steps:

  1. Setup — name, description, single- vs multi-agent, language-based toggle

  2. Environment — upload with File or Folder. A single script is fine for small envs. For packages, upload a folder with requirements.txt at the top level, and put optional constructor arguments in env_config.yaml (uploaded in the Configuration step).

  3. Requirements — requirements.txt (Arena can suggest defaults from your upload), or type dependencies in the text box

  4. Configuration — optional env config file or YAML arguments for your environment class

  5. Entrypoint — module path to the env class (for example my_pkg.env:MyEnv). Arena scans the upload and lists likely entrypoints; pick the one you want. You can rename the first version (default v1) before you finish.

When you finish, Arena creates the environment and first version. Duplicate names within the organization are rejected in the modal.

If validation succeeded during create, profiling may start in the background.

Versions overview

Click an environment on the list to open its detail page. The versions table columns are Name, Status, and Validated at. Expand a row for validation panels and Resource Usage (CPU and RAM per worker when profiling finished).

Row actions include Launch experiment, Edit version code, Duplicate version, Rename version, and Delete version. Use New version to add another version.

Status shows Validated (with a checkmark) when validation has passed. Launch experiment stays disabled until the version is Validated, CPU and RAM are populated on the version, and profiling is not still in progress (profiling counts as active for up to about fifteen minutes without completion).

Code editor

Open a version from the versions table to edit code. You get a file tree on the left. Typical actions:

  • Edit and save files

  • Pick or change entrypoint before commit

  • Validate — run checks on the working copy. Clear Run random episodes in validation if you only want structural checks without rollout episodes.

  • Save or Commit — save creates a named version when you branch from an existing one; commit attaches validation results and may trigger reprofiling

  • Arena prompts you to save when you have unsaved edits

The right-hand panel switches between validation views when data exists (see Validation and profiling).

Entrypoint choices appear in a picker when Arena has scanned the working copy. Committed versions also list stored entrypoints on the version row.

New version from an existing one

On the environment page, use New version or Duplicate version on an existing version to branch from known-good code.

Experiments

Classic and Advanced Training RL experiments let you pick a custom gym in the wizard Environment step; use Select version when the grid asks for it. The same validation and profiling rules apply as Launch experiment.

Launch experiment from the versions table opens the experiment dialog with this gym and version prefilled.

For command-line workflows, use the Arena CLI environment commands instead of the UI steps above.