Security & reliability

Where your scripts run, what you hand us, and what happens when something fails.

Rawtoh is a hosted service that holds the keys to your channel and runs your code. This page says plainly how that code is isolated, where your credentials live, and what breaks (and what doesn't) when a piece goes down.

Where your scripts run

Triggers and actions run on Rawtoh's servers, in a dedicated JavaScript runtime. Each execution gets its own isolated sandbox, configured with hard limits. Scripts have no filesystem, no network of their own and no access to other organizations: everything they can do goes through the rawtoh globals (modules, storage, logs).

Timeouts are enforced inside the runtime itself, so a while (true) is stopped like anything else. A script that times out or crashes is reported as a failed process; its sandbox is thrown away and a fresh one takes its place. Other automations, yours or anyone else's, keep running.

No event is dropped

Every event goes through a persistent queue. The runtime acknowledges a message only once the event and the processes it spawned are committed to the database, so a crash mid-run never loses an acknowledged event: the queue delivers it again. Delivery is at-least-once and the event insert is idempotent, so a replay doesn't create duplicates. Cooldowns (throttle and debounce) are stored in the same shared queue, so several runtime workers coordinate without one of them being a single point of failure.

What you hand us

• Twitch and Discord tokens: stored on the module's server, scoped to your organization, and sent only to the provider they belong to. Revoke them any time from Twitch or Discord, or by deleting the account in the module.
• OBS WebSocket password: stored on the OBS module's server, never in browser storage. With the local OBS module, it never leaves your machine.
• AI keys you bring: stored per organization and used only to call the provider you chose. The platform key is never exposed to scripts.
• Module key pairs: each module instance authenticates with an Ed25519 key pair; private keys are encrypted at rest with AES-256-GCM, bound to the row they belong to.

Scripts never see any of these. A script talks to a module by name; the module holds the credential and makes the call.

What happens when something is down

• Rawtoh is down. Triggers stop firing and the Board stops responding. Nothing else changes: OBS keeps streaming, your chat keeps running, your scripts and storage are untouched. Events that modules managed to deliver are queued and processed when we are back.
• The OBS browser tab is closed, or the PC went to sleep. Calls to OBS fail with an explicit OBS is not connected error, visible in the Activity, and resume as soon as the tab is back. For a live show, use the local OBS module below instead of a tab.
• OBS itself is closed. Same error, and the local OBS module retries every 5 seconds until OBS answers.
• Your script fails. The process is recorded with the error and the module calls that did go through. No other automation is affected.

OBS without a browser tab

The local OBS module is a single binary that runs next to OBS on the streaming PC. It speaks obs-websocket on one side and Rawtoh on the other, with the same events and methods as the hosted OBS module. The browser is out of the loop: nothing to keep open, nothing a tab suspension can interrupt. It reconnects to both OBS and Rawtoh on its own.

# OBS → Tools → WebSocket Server Settings: enable, note the password
# Rawtoh → Modules → Instances → create an instance → copy the enrollment token
module-local-obs --state-dir ~/.config/rawtoh-obs --obs-password '...' --enroll rth_e_...
# next runs
module-local-obs --state-dir ~/.config/rawtoh-obs --obs-password '...'

Measured in production, a Board tap reaches OBS in about 60 ms end to end; an event reaches your script in under 10 ms. That is fine for scene switches and shoutouts. If you need frame-accurate cuts, keep those on a local switcher and let Rawtoh drive it.