Skip to main content

Cloud contexts

A cloud context is a cloud VM running k3s that ERun provisions for you, starts on demand, and stops when it goes idle. Same workflow as local, just hosted somewhere else — your environments live there, your IDE and Agent connect to them exactly as if the cluster were on your laptop.

When to reach for one:

  • Your machine doesn't have the capacity for the env you want to run.
  • You need to share an env with another Operator or Agent across the network.
  • You want overflow capacity for parallel work without buying a beefier laptop.

ERun watches each cloud context in the background, starts it on erun open, and stops it when idle — so the cluster doesn't bill twenty-four hours a day.

Lifecycle​

Cloud context lifecycle as a state machine. Four cyan-stroked state boxes left to right: stopped (cluster is off) → starting (waking up) → running (ready to use) → stopping (winding down). Forward arrows are labelled 'erun open', 'cluster ready', and 'idle policy fires'. A return curve below loops from stopping back to stopped, labelled 'shutdown complete'. A note at the bottom reads: 'Idle timeout and traffic thresholds are configurable per environment.'
ERun watches each cloud context in the background and reports the current state in erun list and in the desktop sidebar.
StatusMeaning
stoppedThe underlying machine is off. Nothing is reachable.
startingERun is waking it up.
runningReady to use; you can open environments.
stoppingIdle timer fired (or someone hit stop) — winding down.

Idle stop​

For environments backed by a cloud context, ERun watches two activity sources — terminal input and network traffic. When both have been quiet for the configured idle.timeout window (default 5m, working hours default 08:00-20:00), ERun stops the instance. The next erun open brings it back — though outside working hours ERun refuses to start a stopped context unless you pass --force (erun context start --force), so it doesn't wake overnight.

Both the Agent and the Operator can read the live state via the MCP idle tool. The Agent watches this automatically before long-running operations — see Agent patterns · Idle before sleeping.

For the exact eligibility predicate, default thresholds, and working-hours semantics, see Agent reference · Idle-stop policy.

Configuring​

You create a cloud context with erun context init, which provisions the VM and installs k3s; ERun manages its lifecycle from there. The one-time AWS prerequisites (registering a provider alias, permissions) are covered in Cloud setup. Once it exists, environments reference it by its kubeconfig context, and erun cloud set ties an environment to the provider alias.

Cloud contexts are AWS-only; Cloudflare is context-less​

A cloud context is always an AWS EC2 instance running k3s — that's the only kind of VM ERun provisions and manages today. Cloudflare aliases are a different thing entirely: they have no VM, no start / stop, and no idle-stop, because there is nothing to bill around the clock. A Cloudflare alias just hands a scoped API token to an environment's runtime pod for DNS and zone work, so it is context-less — you attach it to an environment with erun cloud set, but it never appears in erun context list. An environment can carry both at once: an AWS alias backing its managed cloud context, and a Cloudflare alias for DNS.