Compute private beta - Trigger

<Warning> MicroVM compute is in private beta. Use it in staging only - do not run production traffic on it yet, and expect bugs. </Warning>

What it is

MicroVM compute is a new runtime for your tasks, designed for fast cold starts via boot snapshots. For most tasks the migration is transparent - the same task code runs unchanged.

Getting access

You can't opt in yourself. Once we've enabled the private beta for your org, the us-east-1-next region becomes available on the Regions page in the dashboard. If you'd like access, ping us on Slack.

Routing runs to microVM compute

MicroVM compute is exposed as a region: us-east-1-next. The region is tagged with a microVM badge on the Regions page.

Per-trigger override (recommended)

The region option is part of TriggerOptions, accepted by most triggering functions.

typescript

import { yourTask } from "./trigger/your-task";

await yourTask.trigger(payload, { region: "us-east-1-next" });

This is the safest way to opt in during the beta - you control exactly which runs land on microVM compute.

To gate it on an environment variable so prod isn't affected, define one constant and reuse it at every call site:

typescript

const defaultRegion = process.env.USE_COMPUTE_BETA === "1" ? "us-east-1-next" : undefined;

await yourTask.trigger(payload, { region: defaultRegion });

Set USE_COMPUTE_BETA=1 in the staging environment of the app that calls trigger() (typically Vercel, or wherever you deploy your app).

Set it as your project default

Open the Regions page in the dashboard and set us-east-1-next as the project-wide default. This applies to all environments in the project, so only do this on a project that is running staging traffic only.

<Note> Switching the default region doesn't move runs that are already in the queue - they stay in the previous region until they execute. To make a switch take effect for in-flight work, [cancel those runs](/bulk-actions) and re-trigger them after changing the default. This applies whenever you change regions, not just when moving on or off `us-east-1-next`. </Note>

Machine sizes

A few things to be aware of during the beta:

small-1x is the default and what we've optimized for. Boot snapshots are precreated for small-1x only - other sizes generate the snapshot lazily on first run after a deploy.
small-2x, medium-1x, and medium-2x work, but the first run after each deploy is slower while the boot snapshot is generated. Subsequent runs use it.
large-1x and large-2x aren't supported yet. Stick to small-* or medium-* for now.
Avoid micro during the beta. Cold starts on micro are noticeably slower than other sizes.
All sizes are capped at 1GB of disk during the beta. The machine size table lists 10GB as the target, but every preset is currently provisioned with 1GB regardless.

We'll be shipping CLI and SDK changes during the beta to make cold start times more consistent across machine sizes, lift the disk cap, and unlock the larger presets. Compute-specific prereleases will be announced on this page as we go, and we'll also reach out on Slack.

Reporting issues

Send anything weird (errors, slow runs, restore failures, anything that surprises you) over Slack with the run ID. The more reproductions we get during the beta, the faster we harden it for public beta.