Create your first app

simulo create scaffolds a runnable app folder from a starter template. It never touches the network and needs no login — it only writes files to your local disk.

simulo create mybot

Created training app in mybot/ (app.py + .simuloignore).
Next steps:
  cd mybot
  simulo run app.py

That’s it — mybot/app.py is real, runnable code for the pinned global-catalog asset simulo/robot/cartpole:v1. Run it as-is, choose another validated asset from the Simulo global catalog, or edit it for your own robot and task.

The starter’s global-catalog asset

The generated file declares this module-level handle:

cartpole = simulo.Asset.from_registry("simulo/robot/cartpole:v1")

simulo/ means the read-only Simulo global catalog, robot is the asset kind, cartpole is the name, and :v1 pins the immutable version. Declaring the handle at module level lets simulo run discover, resolve, and record the asset before it creates the job.

Browse or inspect the source catalog entry from the CLI:

simulo asset list --global --kind robot
simulo asset inspect simulo/robot/cartpole:v1

See Choose & validate assets for the global-catalog workflow and how to publish your own USD/URDF package.

Choosing a starter

--type picks the starter shape (default training):

training

simulo create mybot --type training

One @app.job that trains a PPO policy to convergence and saves a checkpoint. The default and the simplest starting point. Full walkthrough: Training template.

inference

simulo create mybot --type inference

Three jobs sharing two volumes: train → evaluate → rollout, a complete policy lifecycle in one self-contained app. Full walkthrough: Inference template.

scenario

simulo create mybot --type scenario

A headless, scripted scene with no learning — no task, no reward, no trainer. Useful for scene construction, controller testing, or anything that isn’t training a policy. Full walkthrough: Scenario template.

Other flags

simulo create mybot --dir ~/projects   # scaffold ~/projects/mybot instead of ./mybot
simulo create mybot --force            # overwrite an existing, non-empty target folder

Without --force, simulo create refuses to write into a non-empty target — it never silently clobbers files.

Note

simulo create scaffolds an app folder, not a “project” — every Simulo org has exactly one project server-side, so the command only ever talks about the folder it just wrote.

<name> is used as the folder name, the simulo.App(...) name, and a Python class-name fragment in every template — <name>Task for the training and inference starters, <name>Scenario for the scenario starter — letters, digits, and underscores only, and it must start with a letter or underscore.

What’s inside

Every scaffolded app.py follows the same shape: one simulo.App (running on the default Simulo runtime) and one or more @app.job-decorated functions containing the actual simulation/training logic — no @app.entrypoint needed. simulo run app.py maps its flags straight onto the training/scenario starter’s sole job, or (for the inference starter’s three jobs) the --job-selected one; see App & Jobs for the full behavior. The heavy imports (torch, and anything worker-only) live inside a with app.runtime.imports(): block, so importing or running the file itself never needs a GPU or even torch installed locally.

The templates also declare the cartpole catalog handle at module level. That lets simulo run capture and pin the exact asset before the cloud job is created.

See Templates for a full annotated walkthrough of each starter’s generated code — what to edit, and where.

Next

Run & submit the app you just scaffolded.