Run safely
Choose a runtime
Understand Browser, Desktop, Extension, and the services a workflow needs.
The runtime executes your graph. Select it before testing a workflow that depends on network access, local files, credentials, or persistent State.
Browser#
Use Browser for a quick start and ordinary in-page execution. Core examples run without installing anything. The page and browser must remain available for browser execution and scheduling.
HTTP requests are subject to browser CORS, mixed-content, and private-network restrictions. A request blocked by those rules may need a different runtime even when the URL and credentials are correct.
Desktop#
Desktop runs through the paired local runtime and supports capabilities unavailable to a browser page. Email delivery requires Desktop because a browser cannot open an authenticated SMTP connection.
Check Get the app for release availability and pairing instructions. Desktop downloads are being prepared; development builds can be run from the project. The runtime process and its device must remain available when work is due.
Extension#
Extension is another local execution option. Get the app shows browser-store availability and instructions for loading a development build. Connect the extension from the app and confirm it is available before starting a run. Local file access and SMTP require Desktop.
RPC and saved workflows#
Blokboard Cloud RPC requires sign-in. You can configure a Custom RPC, or use Desktop or Extension with Public RPC where supported. The network selected for a blockchain node must agree with the workflow’s Test mode.
Saving a workflow to an account does not by itself provide an always-running execution host. Runtime availability still determines whether it can run.
Cloud RPC credits#
Free accounts receive 300 credits once, shared across Solana and Ethereum. Credits do not reset. Open Cloud RPC settings to see your remaining credits, credits used, and request count. A request and a credit are different units: one node can make several requests, and different methods have different costs.
| Operation | Cloud RPC credits |
|---|---|
| Standard Solana RPC request, such as a balance read | 1 |
| Higher-cost Solana queries, such as program-account or asset queries | Usually 10 per request; some methods cost more |
| Ethereum network check | 0, still counted as a request |
| Ethereum block number | 10 |
| Ethereum ETH balance | 20 |
| Solana subscription data | 2 per 100,000 bytes, including an initial 2-credit reservation |
Both Ethereum nodes check the network before reading. The check adds a request without adding credits. The Ethereum example reads a block number and a balance: one complete run uses 30 credits and four requests. Test mode uses the same credit prices.
HTTP credits are reserved before a request is sent. A request that fails after forwarding still consumes its reservation. Retries are additional requests. Custom RPC and Public RPC do not spend Blokboard credits; their own service limits still apply.
Credits and busy-service errors#
A 429 response can mean two different things. An insufficient-credits message includes the call’s cost and your remaining balance; waiting does not replenish that balance. Choose another configured RPC route if you have exhausted it.
A Cloud RPC is busy message means requests arrived too quickly for the service, even if credits remain. Wait before retrying, reduce concurrent reads, or space repeated work out with Wait and a longer schedule interval. An API response may include Retry-After with a suggested delay. Avoid immediately rerunning a large wallet loop.
Moving between runtimes#
Recheck connection setup, file access, wallet access, and State after changing runtimes. Values stored locally in one runtime are not automatically transferred to another.
Next: connections and scheduling.