Hosted runs
A hosted run executes your workflow on shared infrastructure instead of your laptop — the same script, producing the same checkpoints, without tying up your machine.
In development
Hosted runs are not available yet and there is no announced date. This page describes the intended behaviour so you can see where it fits. VeraTracer Desktop runs entirely on your own machine today and needs no account.
Why move a run off your machine
Local runs are the right default — they are fast, private and need nothing but the app. Three situations are where they stop being comfortable:
- The source is bigger than your laptop. Pulling tens of millions of rows across a home connection to filter them down to thousands is mostly waiting on the network.
- The run outlives your session. Anything long enough that closing the lid cancels it is work you cannot schedule around.
- Someone else needs the result. A checkpoint that only exists in your copy of the project cannot be handed to a colleague.
What changes and what does not
The point of hosted runs is that almost nothing about how you work changes:
Your script
The same .verascript file, unchanged. There is no cloud dialect and no separate deployment format.
Checkpoints and ranges
Steps become checkpoints the same way, and a checkpoint range still scopes what re-runs.
The interface
Editor, gutter, inspector and results panels behave identically. Only the run target changes.
Where your data sits
A hosted run reads from sources the server can reach, not from your local disk. Local file paths do not resolve.
How long you can walk away
A run keeps going when you close the lid. Results are waiting when you reconnect.
Who else can see it
A hosted checkpoint can be shared with your team rather than living only in your copy of the project.
Choosing where a run executes
The run target lives in the status bar at the bottom of the window. It reads Running locally by default; switching it to a server sends the next run there instead. Nothing else about the Run button or ⌘R changes.
Because the target is per-run rather than per-project, the normal pattern is to develop against a small local sample, then switch targets for the full pass — the same script either way.
Checkpoints across machines
A hosted run produces the same checkpoint graph you would get locally. That is what makes the two interchangeable: you can rewind to a hosted checkpoint, branch from it, and compare it against a local one, because they are the same kind of object.
See Checkpoints for how ranges and branching work — none of it is specific to where the run happened.
Questions we have not answered yet
Being straight about the open ones, since they will decide whether this fits your setup:
- Which regions runs execute in, and what that means for data residency.
- How connectors authenticate to your warehouse without credentials sitting somewhere they should not.
- Concurrency limits, and how a queued run behaves.
- Pricing.
If one of these is the deciding factor for you, tell us — it is genuinely useful input while this is still being designed.
In the meantime, VeraTracer Desktop runs locally with the full checkpoint model and no account.