Everything in this book so far ran on your laptop. This chapter is about the day the same file runs inside Skode — what stays identical, what becomes real, and what the platform promises about safety.
Deploying
A skript deploys by giving Skode the file: paste it into Automate → Skript in your workspace, attached to the workflows it should serve. The file is the deployment artifact — the same bytes you ran locally, which is the whole reason the simulator exists. There is no build step, no transpilation, no environment configuration inside the language.
What stays the same
The language. All of it — parsing, indentation, variables, arithmetic, string interpolation, every condition form, all three loops, functions, stop, the error philosophy. A file that passes skript check parses in production, full stop, because both run the same grammar. And a file whose trace shows a given sequence of decisions for given inputs will make those same decisions in production for those inputs.
What becomes real
Five things cross from printed to actual, and they are exactly the five you would guess:
| In the simulator | In production |
|---|---|
| events are demo data | events are your real leads, forms, messages, invoices, deals |
score it with ai simulates from signals | real AI scoring over the full record |
reply / send print the message | messages go out on the real channel |
assign, add tag, create task print | records change; tasks appear on real lists |
wait 2 days is instant, and says so | the run genuinely resumes two days later |
Two of these deserve a second sentence. Scoring: production scores will not numerically match simulated ones — do not encode simulator-specific thresholds you discovered by trial; encode business thresholds you chose on purpose. Waiting: a production wait really schedules; the world can change before the continuation runs, so re-check what matters after a long pause rather than trusting a variable set three days ago.
The sandbox promises
Production Skript runs inside the same guardrails you have already met, plus the platform's own:
- Loops are capped — the thousand-pass
whileguard is enforced in production exactly as locally, so no skript can spin forever. - Recursion is capped at sixteen levels, same error, same wording.
- No raw network, no filesystem, no imports. A skript touches the world only through its nine actions, every one of which is mediated, logged and rate-limited by Skode. There is no sentence in the language that can reach anywhere else — safety by vocabulary, not by review.
- Runs are isolated. Each event gets a fresh namespace; a skript cannot corrupt another run's variables, and a failing run fails alone, in its own trace, without taking a queue down with it.
- Every run leaves a trace. The same step-by-step account you have been reading locally is recorded for production runs — so "what did the automation do to this lead?" is a lookup, never a mystery.
A deployment ritual that works
Teams converge on some version of this; you may as well start with it.
skript checkclean — structural errors never leave the laptop.- Every branch exercised once with pinned dials (
--score,--data), trace read end to end. - The awkward-customer runs: empty email, zero budget, weird characters in the name.
- Comments at the top of the file: what event, what it does, which command lines tested it.
- Deploy, then watch the first few real traces — not because the logic might differ (it will not) but because real data always has one more shape than you imagined.
That last point is the honest heart of automation work. The language can guarantee its own behaviour, and does; the world guarantees nothing, and the craft is arranging your skripts so the world's surprises land in a create task for a human instead of a wrong message to a customer. Skript's contribution is that the arrangement — the actual logic — is never the mystery.