Isaac Automator

Isaac Automator (v4) is a tool for the quick deployment of Isaac Sim, Isaac Lab, and Isaac Lab Arena to public clouds, including AWS, GCP, Azure, and Alibaba Cloud.

It automates the creation of an Isaac Workstation—a remote desktop cloud VM configured for robotic application development. Key features include:

• Support for various GPU instances.
• Stop/start functionality to manage cloud costs.
• Tools for data uploading/downloading, autorun scripts, and deployment management.

Isaac Automator is a skill designed to deploy and operate cloud-based Isaac Workstations. It allows developers to provision GPU Virtual Machines (VMs) running Isaac Sim, Isaac Lab, and/or Isaac Lab Arena across major cloud providers including AWS, GCP, Azure, and Alibaba Cloud.

Key capabilities include:

• Provisioning: Setting up remote workstations in the cloud.
• Connectivity: Connecting to the provisioned instances.
• Data Management: Moving data in and out of the cloud environment.
• Cost Control: Managing expenses by starting, stopping, repairing, or destroying deployments.
• Integration: Importing existing deployments into the Automator workflow.

Isaac Automator allows you to provision and operate a cloud-based Isaac Workstation (a GPU VM running Isaac Sim, Isaac Lab, and/or Isaac Lab Arena) on AWS, GCP, Azure, or Alibaba Cloud.

Core Lifecycle Commands

• Deploy: Create a new workstation using cloud-specific scripts (e.g., ./deploy-aws).
• Connect: Access the workstation via noVNC (browser-based 2D desktop), NoMachine (for live 3D viewport), or SSH (shell).
• Manage Cost: Use ./stop <name> to pause compute billing (preserves public IP) and ./start <name> to resume.
• Tear Down: Use ./destroy <name> --yes to delete the deployment and stop all billing. Always destroy when finished.
• Maintenance: Use ./repair <name> to re-apply configuration if the workstation is unhealthy.

Selecting the right connection method depends on whether you need to see the 3D rendered viewport or just interact with the OS.

Tip: To capture rendered output programmatically without a display, use the application's built-in recorder (e.g., Isaac Lab's --video flag) instead of attempting to screenshot via noVNC.

Depending on your goal, choose one of three connection methods to interact with a deployed Isaac Workstation:

• noVNC: Best for general desktop interaction, launching applications, and opening terminals via a web browser.
• NoMachine: Required for viewing the live Isaac Sim or Isaac Lab 3D viewport. Because Omniverse Kit renders via a Vulkan surface, noVNC cannot capture the 3D output; NoMachine is GPU/Vulkan-aware and handles this correctly.
• SSH: Best for running commands, reading logs, launching demos headlessly, or recording viewport video.

Managing deployment lifecycles is critical for controlling costs. The billing behavior depends on the instance state:

• Running: You are billed for compute (high cost) plus storage.
• Stopped: You are billed only for storage (low cost). The public IP is preserved, so connection URLs remain valid.
• Destroyed: All resources are removed and all billing stops.

Best Practice: Use ./stop when idle, ./start to resume, and ./destroy when you are completely finished with the deployment.

Credentials are stored in the state/ directory to persist across container restarts.

Note for AWS: If AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are set on the host before invoking a command, they are forwarded into the container and take precedence over the SSO flow.

Because Isaac Automator provisions real, billable cloud infrastructure, users should follow these best practices to mitigate financial risk:

1. Instance Selection: Use the cheapest viable instance type for your workload.
2. Non-interactive Execution: Pass options non-interactively to ensure predictable deployment.
3. Lifecycle Management: Always explicitly stop or destroy deployments when they are no longer needed to prevent ongoing charges.

Isaac Automator is designed to be operated by AI agents. If you are building or using an agent to manage deployments, connections, or workstation lifecycle (stop/start/destroy), follow these resources:

• Operator Guide: Refer to ai/automator.agent.md for step-by-step procedures.
• Skill Sets: Specific tasks are defined in ai/skills/.
• Discovery: Agent-aware tools can auto-discover AGENTS.md (and CLAUDE.md for Claude Code) to understand cost, safety, and non-interactive rules.

Use these primary commands to manage the lifecycle of Isaac Automator and your deployments. Note that deployment commands vary by cloud provider (e.g., use deploy-gcp instead of deploy-aws).

./build                       # build the Isaac Automator container (one-time)
./run                         # enter the container
./deploy-aws                  # deploy an Isaac Workstation (follow the prompts)
./novnc <deployment-name>     # open the remote desktop in your browser
./destroy <deployment-name>   # tear down the deployment when done
./import --cloud aws ...      # import existing cloud resources into state