Skip to main content
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.

​
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.
  • Environment — user secrets plus explicitly bound provider credentials, injected at deploy time. The 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:
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:
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 covers. On paid plans, insta compute scale <n> 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.