Settings
Every script carries the same settings panel, split into Metadata, Runtime, Generated UI, and Triggers. This page goes through each option in depth.
Metadata
Section titled “Metadata”Summary
Section titled “Summary”An optional short, human-readable title for the script, shown wherever Orvanta lists it. Leave it blank and the UI falls back to the script’s path. Orvanta AI can generate one for you from the script’s code.
A script’s path is its identifier — <owner>/<name> — and it’s how the script is referenced elsewhere (webhooks, the CLI, other scripts calling it). The owner segment is either a specific user (u/<username>/...) or a folder shared by a group (f/<folder>/...); which one you pick determines who gets access by default.
Description
Section titled “Description”Free-text, markdown-supported instructions for whoever runs the script — what it does, what its inputs mean, anything a caller needs to know that isn’t obvious from the schema.
Language
Section titled “Language”Orvanta runs scripts in a wide range of languages and language-shaped integrations: TypeScript (Bun or Deno), Python, Go, Bash, PowerShell, Nu, PHP, Rust, C#, Java, Ruby, R, Kotlin, and Ansible, plus SQL dialects (PostgreSQL, MySQL, MS SQL, BigQuery, Snowflake, OracleDB, DuckDB), MongoDB, Groovy, and templated REST calls, GraphQL queries, and Docker containers. Dart is available on Enterprise builds only.
A workspace can hide languages it doesn’t use and reorder the rest — the ordering is shared by every script, workflow, and app editor in the workspace, and only a workspace admin can change it.
Script kind
Section titled “Script kind”Specializing a script into one of the script kinds — Trigger, Approval, Error handler, or Preprocessor, with plain Action as the default — is also set here.
Runtime
Section titled “Runtime”Runtime settings control how a script executes once it’s queued, not what it does.
Concurrency limits
Section titled “Concurrency limits”Caps how many jobs of this script (or an inline copy of it running as a workflow step) can run at once — extra jobs wait in the queue instead of running in parallel. Enterprise only.
Debouncing
Section titled “Debouncing”When jobs with matching debounce characteristics arrive faster than the configured window, debouncing cancels the pending ones and lets only the latest go through, instead of running every one of them.
Worker pool tag
Section titled “Worker pool tag”Assigns the script to a specific worker pool (tag), so it only runs on workers provisioned for its needs rather than the workspace’s default pool. Set the tag from the script editor’s settings once at least one custom pool exists on the instance.
Caches a run’s result for a set duration, keyed on its inputs. A later run with identical inputs, inside that window, returns the cached result immediately instead of executing again.
Timeout
Section titled “Timeout”Caps how long a single run of this script is allowed to take; Orvanta stops execution once the timeout is reached.
Perpetual script
Section titled “Perpetual script”See Perpetual scripts — the script restarts automatically after each run ends, until cancelled.
Dedicated workers
Section titled “Dedicated workers”Pins the script to a warm worker process instead of spawning a fresh runtime per job, which matters most for interpreted runtimes with real startup cost (Python3, Deno, Bun, and Bunnative) — can reach over 1500 requests/s per dedicated worker. Compiled/native runtimes are already close to that speed without it. Enterprise only, and not available on Orvanta Cloud.
Delete after use
Section titled “Delete after use”Deletes a job’s logs, arguments, and result the moment it completes and its result has been returned — irreversibly. It only has an effect when the script is called via a synchronous webhook or as a workflow step; triggered standalone any other way, nothing gets deleted. Instead of immediate deletion you can set a retention period (in seconds) and have the same cleanup happen on a delay — useful if you want a short window to inspect a run before it’s gone. Both immediate deletion and the retention period are Enterprise-only, available per-script and per-workflow-step.
High priority script
Section titled “High priority script”Assigns the script’s jobs a priority from 0 to 100 within their queue; higher-priority jobs jump ahead of lower-priority ones waiting in the same queue. Enterprise only.
Runs visibility
Section titled “Runs visibility”Hides this script’s manual runs from everyone except the user who triggered them — including the script’s own owner(s). Whoever runs it manually from the advanced run menu on a deployed script can override this for that specific run.
Generated UI
Section titled “Generated UI”Individual arguments on the main function accept extra constraints — min/max, pattern, enum of allowed values, and similar — that flow straight into the script’s JSON Schema and, from there, into its auto-generated form.
Triggers
Section titled “Triggers”A script or workflow doesn’t have to be run manually — any of the following can call it instead.
Webhooks
Section titled “Webhooks”Every script and workflow gets a webhook the moment it’s created, with sync and async variants; which one you call determines whether the request waits for the result or returns immediately with a run ID.
Schedules
Section titled “Schedules”Runs a script or workflow on a cron-style schedule — the fit for anything recurring: nightly jobs, periodic polling, recurring exports.
Routes
Section titled “Routes”A custom HTTP route path (rather than the default webhook URL) that maps incoming requests to a script or workflow, letting you expose a stable, readable endpoint instead of the generated one.
Websocket
Section titled “Websocket”Keeps a connection open to a WebSocket server and runs a script or workflow each time a message arrives.
Postgres
Section titled “Postgres”Watches a Postgres database — a whole database, a schema, or specific tables — and runs a script or workflow when rows are inserted, updated, or deleted.
Subscribes to topics on a Kafka broker and runs a script or workflow per message received, for streaming events out of a Kafka-based pipeline as they happen.
Subscribes to subjects on a NATS broker and runs a script or workflow per message received.
SQS triggers
Section titled “SQS triggers”Polls an Amazon SQS queue and runs a script or workflow per message received, for event-driven work off an AWS queue. A preprocessor script, if the runnable has one, can reshape the raw SQS message before the rest of the script or workflow sees it.
MQTT triggers
Section titled “MQTT triggers”Subscribes to topics on an MQTT broker and runs a script or workflow per message received. As with SQS, a preprocessor can transform the raw MQTT payload first.
Assigns the script or workflow its own inbound email address (via the instance’s SMTP setup) — sending a message to that address runs it, with the email’s contents available as input.