Skip to main content
Azure Container Apps sandboxes are hardware-isolated microVMs that run Roomote tasks on your own Azure subscription. The provider supports memory+disk snapshots and sub-second suspend/resume standby, so both environment setup caching and task sleep/resume flows keep the full workspace state. Azure Container Apps sandboxes are in public preview; expect API drift.

​
When to use Azure Container Apps

Use Azure Container Apps when:
  • task work should run inside your own Azure subscription
  • you want hosted sandboxes without managing an API key (auth uses the ambient Azure login or a managed identity)
  • memory+disk snapshots or standby with sub-second resume is useful

​
Prerequisites

  1. An Azure subscription and resource group.
  2. A sandbox group (one-time bootstrap):
    The calling principal is granted the Container Apps SandboxGroup Data Owner role automatically; grant it explicitly to any additional principal, such as a deployed controller’s managed identity.
  3. Authentication: az login for local runs; a managed identity when the Roomote controller itself runs in Azure (set AZURE_CLIENT_ID for a user-assigned identity); or a service principal (recommended for containerized installs, where az login is impractical) — az ad sp create-for-rbac --name <name> --skip-assignment, then grant the app the Data Owner role from step 2 and set all three of AZURE_TENANT_ID/AZURE_CLIENT_ID/AZURE_CLIENT_SECRET.

​
Configuration

Add Azure Container Apps from Settings > Sandboxes, or provide the values as deployment env vars:
Optional values:
AZURE_SANDBOX_DISK_IMAGE selects the worker disk image. Leave it unset to let Roomote provision it automatically: the setup wizard and the Settings > Sandboxes page bake a disk image from the published worker OCI image after the Azure settings are saved. Private registries (e.g. a private GHCR worker image) need AZURE_SANDBOX_REGISTRY_USERNAME + AZURE_SANDBOX_REGISTRY_TOKEN.

​
Snapshots and standby

Azure snapshots capture memory and disk, so a restored sandbox resumes in sub-second time with processes still alive. Task standby uses the same memory-preserving suspend/resume, and sandboxes bill storage-only while suspended. Preview port URLs do not survive a snapshot restore; Roomote re-adds ports after resume.

​
Idle suspension and cost control

Roomote enables Azure’s memory-preserving auto-suspend policy for new sandboxes and refreshes it when restoring snapshots or resuming standby. The idle interval follows the task’s sandbox timeout, normally five hours. This gives Azure a fallback when Roomote’s cleanup service is offline or a development database has been reset. CPU and memory charges stop while the sandbox is suspended. Azure measures idle time from incoming traffic, API code execution, shell sessions, and file operations. This is an idle fallback, not a hard runtime or spending cap: continued activity can keep a sandbox running. Roomote’s normal task sleep and timeout handling still applies. The separate auto-delete policy retains stopped task sandboxes for at least 30 days. Its timer starts after suspension; it cannot stop a running sandbox. Upgrading refreshes lifecycle settings as sandboxes are reused. Existing orphaned sandboxes that Roomote no longer tracks need to be inspected and suspended separately in Azure.

​
Egress TLS inspection

The ACA egress proxy can TLS-inspect (MITM) outbound traffic. Roomote defaults to trafficInspection: Partial, so with no egress rules configured nothing is inspected: package managers (npm, Maven/Gradle, pip) see normal public certificate chains, and non-HTTP traffic such as SSH git works. Override this with AZURE_SANDBOX_EGRESS_INSPECTION, which accepts Legacy, Full, Partial, or None and passes the selected mode to ACA. The service default (Full) resigns all TLS traffic with the proxy CA (/etc/ssl/certs/adc-egress-proxy-ca.crt, preinstalled in the system store and referenced by NODE_EXTRA_CA_CERTS/SSL_CERT_FILE) and blocks non-HTTP traffic; choose Full only when wiring deny-default egress rules or header transforms, and note Java’s per-JDK cacerts still needs a manual import in that mode.

​
Verify setup

  1. save the Azure subscription, resource group, sandbox group, and region
  2. select Azure Container Apps as the default sandbox provider
  3. start a small task from an environment
  4. confirm the task starts, streams logs, and can run project commands
  5. verify preview links if the task starts a web app

​
Common issues

  • Authentication fails. Run az login locally, or confirm the deployed controller’s managed identity holds the Container Apps SandboxGroup Data Owner role on the sandbox group.
  • Sandbox creation is slow on first use. Cold disk image pulls take longer; the worker disk image bake is a one-time provisioning step.