Documentation menu

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.

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.
  • 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:

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:

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 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.

View as Markdown