Skip to content
Orvanta Docs

Upgrading to 6.0.0

Orvanta 6.0.0 is a major, breaking release. It ships a smaller platform: one container image instead of two, no low-code Apps or UI builder, a reduced runtime list, a restructured git-sync repository layout, and licence-tier limits that are now enforced by the running instance rather than only sold on the pricing page. This page is the complete breaking-change list. Read it before you upgrade — several of these changes delete data during the upgrade migration, and one of them can stop the server from booting if you skip the pre-flight check below.

One image, tier decided by the licence

Section titled “One image, tier decided by the licence”

Orvanta used to ship two builds: a Teams-only image (--features teams, sometimes called OTE) and the fuller Enterprise image (OEE). From 6.0.0 there is one container image — the same one for every self-hosted deployment and for Orvanta Cloud. Which capabilities you get is decided entirely by your licence’s tier at runtime, not by which image you downloaded.

If you’re used to reading a feature note as “requires the OEE build,” read it as “requires the Business or Enterprise tier” instead — same requirement, no longer tied to a separate image. Wherever this page or the rest of the docs used to say OTE/OEE, it now says Trial, Solo, Teams, Business, or Enterprise, the same five tiers described in Editions.

If you self-host and previously ran the OTE/Teams image or built with --features teams: that target no longer exists. Rebuild or re-pull using the single published image, with no --features override, or --features enterprise_edition explicitly.

Apps and the UI builder removed

Section titled “Apps and the UI builder removed”

Low-code Apps, the app editor, raw apps, public apps, and the UI builder are gone — hard-dropped, with no export path. If you had Apps in a workspace, the app definitions do not survive the upgrade.

The auto-generated form Orvanta builds when you run or test a script or flow is unaffected and is the only generated UI the platform produces now — see Auto-generated UIs. If your workflow depended on the Apps canvas, a custom app-based dashboard, or the app CLI commands, there is no direct replacement; the run form is the closest built-in equivalent.

Runtime reduction

Section titled “Runtime reduction”

6.0.0 supports 17 languages, down from roughly 29. Kept: TypeScript (Bun), JavaScript (Bun’s Node.js compatibility mode), Python, Java, Kotlin, PHP, Go, Rust, Ruby, Dart (Business and Enterprise tiers), Bash, PostgreSQL, MySQL, BigQuery, DuckDB, GraphQL, and REST. Removed: Deno, Nu, C#, Ansible, PowerShell, MS SQL Server, Snowflake, OracleDB, R, Groovy, MongoDB (as a script language — the data-migration MongoDB connector is unaffected), and running a Docker container from a bash script (the # docker annotation).

In the platform’s ScriptLang enum the 17 are bun (TypeScript), bunnative (JavaScript), nativets (REST: a fetch-only native TypeScript script), python3, java, kotlin, php, go, rust, ruby, dart, bash, postgresql, mysql, bigquery, duckdb and graphql. There is no separate rest identifier, and none for Node.js, which is bunnative. Dart is the only one of the 17 with a tier gate: creating a Dart script requires the Business tier or above (dart_runtime in the edition matrix).

This is a hard drop, not a soft disable. The upgrade migration deletes, irreversibly:

  • Every script whose current deployed version is in a removed language (an older, removed-language version underneath a script that has since moved to a surviving language is deleted on its own, without touching the surviving version).
  • Every flow or flow version with a step in a removed language, at any nesting depth — inside a branch, a loop, an AI agent’s tool list, a failure handler, or a preprocessor.
  • Every queued, running, or completed job in a removed language, and anything the migration cannot leave in a consistent state around it — for example, an in-flight flow run is deleted whole if any of its steps (finished or still queued) used a removed language, even though the flow definition itself may survive.
  • Everything that referenced a deleted script or flow by path or version: schedules, triggers, drafts, favourites, saved inputs, and deployment history.

The migration logs each deletion by path as it runs, and separately warns (without deleting) about anything left dangling — a surviving flow step that calls a now-deleted script, a schedule handler that points at one, a worker group still listening on a removed language’s tag. Read the migration output before assuming the upgrade only did what you expected. If you have removed-language scripts or flows you still need, export or otherwise capture them before upgrading — once the migration runs, they’re gone, and the down-migration only restores the database enum’s shape, not the deleted rows.

Default language for a new script is now TypeScript (Bun).

The DAG flow canvas

Section titled “The DAG flow canvas”

DAG Flow — the original node-based flow model — now renders and edits on the same visual canvas as BPMN Flow: gateways for branches, a loop container instead of a bracket pair, a dedicated error lane, and n8n-style editing (quick-add, drag-to-reorder, copy/paste, group collapse). It is the only DAG canvas: the classic canvas and its toggle are gone. Nothing about the OpenFlow artifact format changed — this is a rendering and editing change only. See The shared canvas.

Git sync: type-first layout, YAML metadata

Section titled “Git sync: type-first layout, YAML metadata”

A git-synced repository’s on-disk layout changed from mirroring internal database paths (f/<folder>/<name>.<ext>) to being organised by object type first: scripts/<folder>/<name>.<ext>, flows/dag/<folder>/<name>/flow.yaml, flows/bpmn/<folder>/<name>.bpmn (+ sidecar), flows/cmmn/…, decisions/dmn/…, resources/, variables/, schedules/, triggers/<kind>/, and users/<user>/… / groups/<group>/… for what used to be u//g/-prefixed paths. Metadata sidecars are now written as YAML (.script.yaml, .bpmn_flow.yaml, …) instead of JSON. Nothing about how paths are stored or how permissions resolve in the database changed — this is a serialization-only mapping.

This is a hard cut, both directions:

  • The server (native git sync and the workspace export/tarball) only ever writes the new layout from 6.0.0 onward.
  • A pre-6.0.0 repository laid out the old way isn’t rewritten in place, and native sync warns when it pushes into one. Re-initialise the repository (a fresh “initialise repository” export/ZIP, or a fresh push to an empty remote) rather than trying to reconcile the old layout by hand.
  • A repository that still has old-style .json metadata sidecars is flagged rather than silently reparsed — 6.0.0’s parser only recognises the new .yaml metadata.
  • The CLI’s sync pull/sync push/init move to the new layout too; a pre-6.0.0 CLI cannot read a 6.0.0-synced repository, and a 6.0.0 CLI does not read the old layout. Upgrade the CLI and the platform together.

Pre-flight check — trigger paths. 6.0.0 adds a database constraint requiring every trigger’s path to match f/<folder>/<name>, u/<user>/<name>, or g/<group>/<name>. If any trigger predates that constraint and doesn’t match it, the upgrade migration refuses to run and the server will not boot until it’s fixed. Run this before upgrading, and rename anything it returns:

SELECT t, workspace_id, p AS path FROM (
  SELECT 'http_trigger' AS t, workspace_id, path AS p FROM http_trigger
  UNION ALL SELECT 'websocket_trigger', workspace_id, path FROM websocket_trigger
  UNION ALL SELECT 'kafka_trigger', workspace_id, path FROM kafka_trigger
  UNION ALL SELECT 'nats_trigger', workspace_id, path FROM nats_trigger
  UNION ALL SELECT 'postgres_trigger', workspace_id, path FROM postgres_trigger
  UNION ALL SELECT 'mqtt_trigger', workspace_id, path FROM mqtt_trigger
  UNION ALL SELECT 'sqs_trigger', workspace_id, path FROM sqs_trigger
  UNION ALL SELECT 'gcp_trigger', workspace_id, path FROM gcp_trigger
  UNION ALL SELECT 'azure_trigger', workspace_id, path FROM azure_trigger
  UNION ALL SELECT 'email_trigger', workspace_id, path FROM email_trigger
  UNION ALL SELECT 'native_trigger.script_path', workspace_id, script_path FROM native_trigger
) r WHERE p !~ '^[ufg](\/[\w-]+){2,}$';

If an upgrade has already failed on this, roll back to the previous image, rename the offending triggers, and upgrade again.

This section covers only what changes at upgrade time — see Git sync repository layout for the full layout table, how to generate a ready-to-push repository with “Initialise repository,” and the CLI hard cut in detail.

Git sync: pinned deploy targets

Section titled “Git sync: pinned deploy targets”

Every git-sync entry now carries a pin (remote and branch) set by a workspace admin. A deploy whose git_repository resource no longer resolves to the pin is refused, and GitHub App installation tokens are scoped to that one repository. On first boot after upgrading, a one-shot backfill pins every existing entry to what its resource resolves to at that moment, and raises a critical alert listing what was pinned and what could not be resolved. Check that alert after upgrading. An entry that is still unpinned is pinned by a workspace admin’s first deploy through it; any other deployer is refused until an admin re-pins it. See Git sync repository layout.

Git sync: GitHub App remote format

Section titled “Git sync: GitHub App remote format”

If a workspace’s git-sync repository uses is_github_app: true, the resource URL is now validated against exactly three accepted forms, all resolving to github.com:

  • https://github.com/<owner>/<repo> (an optional .git suffix and trailing slash are accepted and normalised away)
  • ssh://git@github.com[:22]/<owner>/<repo>
  • the scp-style form, git@github.com:<owner>/<repo>

A URL with embedded credentials (https://user@github.com/...), a non-default port, a query string, or a fragment is refused. GitHub Enterprise Server is not supported for GitHub App sync — only github.com.

Two things that used to silently work now don’t:

  • A renamed repository. GitHub used to serve a redirect from the old name, and Orvanta followed it. 6.0.0 pins http.followRedirects=false for GitHub App git operations (closing a token-leak path where a redirect could hand your installation token to an unintended host), so a rename now fails outright. Update the workspace’s resource URL to the repository’s current name.
  • Any other git remote that redirects across scheme or host — for example a Gitea or GitLab PAT-based remote that 301s from http to https, or from one host to another. Credential delivery is now pinned to the exact scheme://host[:port] you configured; a redirect target is never handed the credential. Set the resource URL to the final location instead of relying on the redirect.

GitHub App configuration also changed. The Instance Settings option for a self-managed GHES App is gone — it had no backend behind it. Every instance authenticates through its own GitHub App, configured entirely by environment variable (GITHUB_APP_ID, GITHUB_APP_PRIVATE_KEY, and friends), targeting github.com/api.github.com only. See Git Integration.

Licence-enforced tier limits

Section titled “Licence-enforced tier limits”

Several capabilities that Orvanta has always sold per tier were, in practice, only ever enforced by which image you ran (OTE vs. OEE) — never by the licence itself. Now that there’s a single image, they’re enforced by the licence at runtime instead:

  • Job-run retention is capped per tier: 30 days on Trial, Solo, and Teams; 90 days on Business; unlimited on Enterprise. A configured retention longer than your tier allows is clamped, both when you set it and continuously as the cleanup job runs — a licence downgrade takes effect without a restart.
  • Private package registries require the Enterprise tier, but only for authenticated registries — an npm, PyPI, Go, Maven, or similar registry setting that carries a credential (a token, a password, or user:pass@ in the URL). A plain mirror or proxy URL with no credential works on every tier, so a firewalled or air-gapped self-hoster below Enterprise can still point package installs at an internal mirror; they just can’t authenticate to a private one.
  • Turning off self-approval on an approval step requires the Enterprise tier, enforced when the flow is saved.
  • Prometheus /metrics and OpenTelemetry trace/metric export both require the Business tier or higher.

If your instance is unlicensed or below the required tier for one of these, it now degrades to the tier’s limit instead of continuing to work the way an OEE build previously did regardless of licence.

@orvanta/cli package licence

Section titled “@orvanta/cli package licence”

The published @orvanta/cli npm package’s license field changed from pointing at a repository file that no longer exists to UNLICENSED. This is a metadata correction, not a change in how you’re licensed to use the CLI itself.

Section titled “Related”