# Compute > Run any container in a microVM, always on or scaling to zero. A compute service runs your container — web app, API, worker — in an isolated microVM with its own URL. Services stay warm by default, you can opt any of them into sleeping when idle, and billing is actual usage either way. ```bash insta services add compute app insta deploy . ``` ## What a compute service is An image, its environment, and a listen port: - **Image** — built remotely from your Dockerfile on `insta deploy .`, or supplied prebuilt with `--image`. See [build & deploy](https://www.instacloud.com/docs/deploy/overview). - **Environment** — user secrets plus explicitly bound provider credentials, injected at deploy time. The [quickstart](https://www.instacloud.com/docs/quickstart) shows the binding step. - **Port** — an explicit `--port` wins; otherwise the Dockerfile's last `EXPOSE` line; otherwise 8080. - **User** — the app and everything it starts run as the image's `USER`, resolved against the image's own `/etc/passwd` and `/etc/group` as Docker does; with no `USER` they run as root. On InstaCloud only the user's primary group applies (supplementary groups listed in `/etc/group` are not added), and `insta compute exec` sessions always run as root. This depends on a fleet-wide runtime rollout still in progress — until it completes, warm launches may still start as root regardless of the image's `USER`, and already-running containers keep their current user until their next launch. A branch can run several compute services, each its own group with its own URL and deploys. WebSocket apps deploy with `--websocket` for a larger guest and connection-based concurrency. ## MicroVMs Each service runs in its own microVM — hardware-level isolation rather than a shared-kernel container, which is what makes it safe to run agent-built code next to everything else. Need disk that survives restarts? Attach a persistent `/data` volume: ```bash insta services add compute app --volume 1 insta compute volume app --size 10 ``` Any plan can attach the default 1 Gi; larger sizes are paid and plan-capped. Volume-backed services stop (cold wake) instead of suspending, so the disk stays consistent. ## Lifecycle New compute services scale to zero, on every branch: an idle machine suspends until the next request wakes it in seconds. Outbound traffic counts as activity as well as inbound requests, so an app calling out to a model or polling an API stays up while it works. A worker (`--port 0`) has nothing routed to it, so it is always-on regardless. Control the lifecycle directly: ```bash insta compute status # desired vs actual state insta compute start insta compute stop insta compute suspend ``` `insta compute always-on on|off` overrides that on any branch, and `--always-on` at creation starts a service always-on. Billing is actual usage either way, so an always-on machine bills continuously while a sleeping one costs almost nothing. Scale-to-zero also stops any background work running in the container, which [limitations](https://www.instacloud.com/docs/limitations/overview) covers. On paid plans, `insta compute scale ` sets a replica cap: a scale-to-zero service wakes at one replica and adds more under load up to n, while an always-on service runs exactly n. Specs move with `insta compute limits`. Custom domains attach per branch with `insta domain attach`. On self-hosted InstaCloud OSS, `compute scale` is cloud-only, while `compute limits`, `--always-on`, and custom domains work as they do here. `insta secrets bind` answers `501`: every compute container already receives each service's credentials under their own names, so read those (`insta secrets list` names them) or set your own with `insta secrets set`. The command-by-command list is in [COMPATIBILITY.md](https://github.com/InsForge/instacloud-oss/blob/main/COMPATIBILITY.md).