Local and Cloud Execution
The SDK validates and transforms task arguments in both environments. Surrounding services—signing, scheduling, persistent storage, and cloud metering—differ.
| Behavior | Local thyme run | Cloud executable |
|---|---|---|
| Runtime | Deno subprocess. | Available daytona or gvisor runtime. |
| Account | Required SIMULATE_ACCOUNT. | Selected profile's execution address. |
| RPC | RPC_URL; needed for chain reads or simulation. | Configured RPC for the profile chain. |
| Args | Task args.json. | Executable args or accepted webhook snapshot. |
| Secrets | Root and task .env values after filtering. | Bound project secrets. |
| Storage | Task storage.json; saved with --persist. | Per-executable, versioned persistent storage. |
| Transactions | No signing or broadcast. | Submitted through the profile and gas route. |
| Logs | Terminal. | Console and authenticated management API/CLI. |
Runtime choices
Daytona uses a managed sandbox associated with the executable. The gVisor adapter starts a fresh isolated container for each run. gVisor is selectable only when configured by the deployment. Existing executables without a runtime setting use Daytona.
Use ctx.storage for durable state in either cloud runtime. Files, globals, process lifetime, and callback invocations are not a persistent-state contract.
Simulation is a distinct operation
thyme run --simulate runs task logic and asks the RPC to simulate returned calls from SIMULATE_ACCOUNT. It does not reproduce account setup, Roles wrapping, paymaster policy, gas settlement, or scheduler behavior. Its per-call fallback can differ from a batched transaction; read the CLI simulation reference.
Cloud Simulate executes the bundle and records the calls it would return. It does not submit transactions, commit storage, or meter usage, and ends as skipped. This preview is not a promise that account authorization and on-chain submission will succeed.
Callbacks
Local runs invoke task-side onSkip and onError when applicable. Use --simulate-callbacks to exercise receipt callbacks with simulated payloads. Real onSuccess and onFail need a cloud submission outcome; see lifecycle callbacks.
Limits
Cloud task and receipt-callback sandbox calls default to a 30-second timeout each. Keep network operations bounded and avoid unbounded polling inside a task. Local memory and timeout controls do not establish cloud parity; see local run options and runtime limits.
There is no built-in local scheduler or watch mode. Use local runs to validate code, then inspect a cloud simulation and controlled execution in the target deployment.