Reviewed on 05/10/2026

Create Your First Script

Phase 5 — Scripts & Automation · OpenFrame Onboarding

The library is a great start, but sooner or later you'll want your own script — your install routine, your cleanup, your health check. The editor makes it straightforward, and you can test it against a real device before it goes anywhere near production. Let's build one.

Before you start

• Decide what the script does and which OS it targets — that drives the shell type.
• Have the script body ready (or be ready to write it in the editor).
• Know whether it needs inputs — command-line arguments, environment variables, or neither.

Open the editor

Go to Scripts → Scripts List → Add Script. You'll get the New Script form.

Fill in the basics

1. Supported Platform — toggle Windows, MacOS, or both. There's also a Run as User option (Windows only) for scripts that need to run in the logged-in user's context rather than as system.
2. Name — something scannable, e.g. Clear Temp Files.
3. Shell Type — pick the language: PowerShell, Batch, Bash, Python, Nu, Deno, or Shell. Match it to your target OS (PowerShell/Batch for Windows; Bash/Shell for Linux/macOS; Python is cross-platform).
4. Category — file it so it's findable later.
5. Timeout — how long (in seconds) to let it run before OpenFrame kills it. Default is 90; raise it for long-running installs.
6. Description — say what it does in plain language. Future-you will be grateful.

Define inputs (optional)

If your script takes parameters, declare them here:

• Add Script Argument — an Argument plus a Value. Leave the value empty to make it a flag.
• Add Environment Var — a name plus a value, passed into the script's environment.

Pick the convention your code reads. If your script reads $env:NAME / os.environ / $NAME, use Environment Vars. If it reads positional/--flags, use Script Arguments. Mixing them up is the #1 reason a script "ignores" its input — see Run a Script on a Device for the full explanation.

Write the body

Scroll to Syntax and write (or paste) your code in the line-numbered editor. Keep it idempotent where you can — a script that's safe to run twice is a script you'll trust at scale.

Test before you save

Click Test Script. OpenFrame opens a Select Device picker (search, Device Tags filter, online/OS status) — choose a known device and run it for real. This is the step that catches a wrong table name, a bad path, or a variable you wired up wrong, before you roll it out. Confirm the result, fix, repeat.

Save

Click Save Script. It appears in your Scripts List with the shell type, OS, and category you set, and its "…" menu and detail page let you edit or run it later.

Quick checklist

• Set Supported Platform (and Run as User if needed)
• Named it, picked the Shell Type, set a sensible Timeout
• Wrote a clear Description
• Declared inputs in the right place — Argument vs Environment Var
• Used Test Script against a real device before saving
• Saved and confirmed it's in the library

What's next

You can now run your script on demand (Run a Script on a Device) or set it to run automatically — Schedule a Script covers recurring runs and device assignment. To read what came back, see Script Results & Output Logs.

Based on OpenFrame v0.9.19. Screens and defaults may shift between releases — when in doubt, what's in your console wins.