Runs on Atlassian and Data Handling
Scriptbox is a pure Forge app: its code runs in Forge functions, its data lives in Forge storage, and it declares no external network permissions. Your scripts never leave Atlassian — there is no vendor server holding your Jira data, because there is no vendor server at all.
This page says exactly what that covers, what Scriptbox stores, and where the edges are.
Where Scriptbox runs
| Piece |
What it uses |
| Compute |
Forge functions on Atlassian's Node.js 22 runtime — the console resolver, event and schedule triggers, the scripted-field value function, workflow rules, the Automation action and the Rovo actions |
| Background work |
A Forge queue consumer that runs migration analyses, one script per invocation |
| Storage |
Forge storage, including its encrypted secret store for Secret Variables |
| Migration conversion |
Atlassian's Forge LLM service (@forge/llm), used only when you run a Migration Analysis |
| Behaviours |
A Custom UI frame inside the Jira issue form, running the same QuickJS sandbox in the viewer's browser |
No egress. The manifest declares no external permissions, and the app's code makes no outbound calls. Scripts cannot either: there is no fetch inside the sandbox, and jira.* takes a site-relative path, never a URL — the host picks the origin, so a script cannot redirect a call off-site.
Runs on Atlassian. forge deploy reports the app as eligible for the Runs on Atlassian programme. The badge itself is awarded by Atlassian; check the Marketplace listing (TODO-LINK:marketplaceListing) for its current status.
Data residency follows your site. Everything Scriptbox keeps is in Forge storage, which follows the host product's residency.
What Scriptbox stores
| Data |
Where |
How long |
| Script source, name and description |
Forge storage (plain) |
Until you delete the script |
| Script versions |
Forge storage (plain) |
Newest 20 per script |
| Run history (console, schedule and listener runs) |
Forge storage |
Newest 25 per script |
| Execution log entries — what ran, its logs, result and the triggering event payload (capped at 8,000 characters) |
Forge storage |
30 days, and at most 200 entries per listener, job, field or behaviour (1,000 per workflow rule type) |
| Listener, job, field and behaviour configuration |
Forge storage |
Until deleted |
| Scripted-field value cache |
Forge storage |
Until the issue changes, the script changes, or you clear it — Forge storage has no expiry, so entries for deleted issues linger until Clear cache |
Per-script storage data |
Forge storage, namespaced per script |
Until deleted by the script or with the script |
| Secret variable values |
Forge's encrypted secret store |
Until you delete the variable |
| Migration uploads and conversions |
Forge storage |
Until you delete the analysis |
A few things worth knowing before you put sensitive material anywhere:
- Script source is plain storage. It is snapshotted on every save and readable by every admin in the editor and version history. Put credentials in Secret Variables, never in source.
- Execution logs keep the event that fired. For a listener, that payload can contain issue text and user details from your site, for up to 30 days.
- Behaviour scripts are visible in the browser. A behaviour's compiled script is published to Jira and sent to every user who opens a matching issue form — anyone can read it with the browser's developer tools. See Behaviours.
- Migration sends source to the Forge LLM. Uploaded Groovy and TypeScript is stored as-is and sent to the model for conversion. The analysis flags hard-coded credentials, but it does not mask them first — remove secrets from files before you upload them.
Deleting data
- Deleting a script removes its versions, run history and its script-scoped
storage data.
- Uninstalling Scriptbox deletes the installation's Forge storage, as for any Forge app.
For how Scriptbox handles personal data on your behalf, see the vendor privacy policy: TODO-LINK:privacyPolicy.