Self-hosted Workato alternative for on-premises and air-gapped networks

Self-hosted Workato alternative for on-premises and air-gapped networks: when the agent model stops working

When your security policy blocks outbound connections from the Workato on-prem agent, or the network is air-gapped, the answer is to run the whole automation runtime inside the network, with n8n or Windmill as the main candidates. The agent is not the only problem. Workato's on-prem agent makes only outbound connections to Workato over a TLS WebSocket tunnel and needs no inbound firewall ports, so a policy that forbids that outbound path is really a constraint on the cloud control plane. Moving the agent does not fix it, because the recipes, scheduling, logs and connector management still depend on that cloud service.

Before you shortlist either tool, read the licenses closely. n8n is licensed under the Sustainable Use License, which permits use only for your own internal business purposes or for non-commercial or personal use, and files with .ee in their name need a valid n8n Enterprise License. Confirm with your legal team that your intended use fits those terms, and that any embedded or redistributed use is covered. Windmill's source code under AGPLv3 and Apache-2.0 is open, but its prebuilt Community Edition images include proprietary code that is free for internal use only, and managed services or resale need a commercial license.

Your first check is whether the candidate runs with zero outbound calls. Ask each vendor for the list of external endpoints its license check, telemetry and update features contact, and test the install on an isolated network segment before committing. Then plan how connectors, container images and updates will reach the isolated network, since any package or image carried across the boundary should be verified for integrity and authenticity. Those verification steps are the part of the work that most often adds cost, so scope them in writing with your implementation partner.

What an air-gapped or on-prem constraint requires from the platform

An on-prem or air-gapped network changes what the automation platform must do on its own. The requirements below cover runtime independence, a self-contained deployment, controlled transfer of software into the boundary, and credential handling, and each one is something to verify in a pilot before committing to a platform.

No runtime dependency on a vendor cloud

The platform must start, run workflows and process triggers without calling a vendor service. Workato's on-prem agent avoids inbound ports by making outbound WebSocket connections to Workato's cloud, so that model does not transfer to an isolated network. Ask each candidate which features need an internet endpoint, including license validation, telemetry, update checks and hosted AI features, and test workflows with egress blocked at the firewall.

Self-contained deployment inside the network

Plan the whole runtime as local components: the main application, a PostgreSQL database and worker processes that read and write workflow data inside the boundary. n8n queue mode, for example, passes executions through Redis to workers that use PostgreSQL, and Windmill workers pull jobs from a PostgreSQL queue. Confirm which containers, images and Helm charts the install needs and whether an external PostgreSQL service such as AWS RDS, GCP Cloud SQL or Azure is acceptable inside your network.

Verified packages across the boundary

Every container image, package, connector and update must enter the isolated network through a controlled transfer. Kubernetes documents pulling control plane images in advance and pointing installs at a private registry, and Security Onion updates from newer ISO media in airgap mode. Set up a mirror, record hashes and signatures for each artifact, and keep a written process for who approves an import. This is the control that NERC CIP-013-2 asks utilities to address for vendor software and patches.

Connector and update ownership

Connectors are code that talks to your internal systems, so decide who builds, reviews and patches them. Ask whether the platform ships connectors as packages that can be mirrored, or whether custom connectors can be written locally. Windmill and n8n let teams write code for systems without a vendor connector, which moves maintenance to your staff. Document the update cadence and the test environment where each new release is verified before it reaches production.

Local secrets and credential handling

Credentials for internal systems must be encrypted and stored inside the boundary. In n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read stored credentials, which makes key distribution and rotation a design item. Windmill Enterprise lists external secret backends such as Vault and AWS Secrets Manager. Confirm where keys live, who can read them and how rotation happens without an internet connection.

Remote access rules for utilities

Operators of high or medium impact BES Cyber Systems under NERC CIP-005-7 must route Interactive Remote Access through an Intermediate System with encryption and multi-factor authentication, and must detect and disable active vendor sessions. If your automation platform reaches operational systems, place its administrative interface behind that access path and confirm with compliance staff which assets fall in scope. Outside that sector, use the same pattern as a general design choice for administrative access.

Which open-source platforms fit an offline runtime, and where they fall short

This table compares n8n, Windmill, Node-RED and Activepieces on how each runs fully inside an isolated network, its license terms for internal use, and its SSO and provisioning gaps. Read each row as a question to put to the vendor before procurement, since offline catalog and update behavior is often not stated in public documentation. The main takeaway is that licensing and identity features vary by edition, so the edition you choose matters as much as the platform.

Platform	Offline self-hosting	Internal use license	SSO, SCIM and gaps to confirm
n8n Community	Runs without a license key using Docker Compose or Kubernetes. No cloud dependency is required.	Sustainable Use License: internal business use permitted. Confirm this fits your use case.	No SAML SSO on this edition. Confirm the offline update path for new releases.
n8n Business	Self-hosted only. Enabled by adding a license key to a self-hosted install.	Same Sustainable Use License. Files with .ee in their name need an Enterprise License.	SAML SSO included. Confirm SCIM support and how the license key is validated offline.
n8n Enterprise	Self-hosted or cloud. Multi-main high availability is available for self-hosted deployments.	Enterprise License covers .ee files. Confirm the terms that apply to your internal deployment.	SAML SSO included. Confirm SCIM and log streaming behavior in isolated networks.
Windmill Community	Docker Compose or Kubernetes Helm charts with external PostgreSQL. Works without internet access once images are mirrored.	Prebuilt images include proprietary code free for internal use. Source builds fall under AGPLv3 and Apache-2.0.	Limited to 3 workspaces, 50 users and 4 groups. No SAML or SCIM on this edition.
Windmill Enterprise	Self-hosted Enterprise Edition. Confirm how license keys and updates reach hosts with no internet access.	Commercial license for the enterprise edition. Confirm internal use terms in the contract.	SAML and SCIM, audit logs, Vault and AWS Secrets Manager support. Confirm the offline update process.
Node-RED	Runs as a Node.js application on local hosts. Check that every community node you need can be installed from a local mirror.	Apache-2.0 license, OpenJS Foundation project. Permits internal use without a commercial agreement.	No built-in SAML or SCIM in the core project. Confirm add-on options and their licenses.
Activepieces	Self-hosted install of the MIT-licensed core. Confirm whether piece packages install with no internet access.	MIT core. Content under packages/ee and the ee app directory uses a separate commercial license.	SSO and provisioning may sit in commercially licensed code. Confirm which features need that license.

How n8n and Windmill differ inside a restricted network

When n8n runs at a scale that needs separated responsibilities, its queue mode splits the work. The main instance receives triggers and webhooks and hands each execution to Redis. A pool of worker processes picks up those executions and reads and writes workflow data in PostgreSQL. Inside a restricted network, every one of these components must be deployed, patched and monitored by your own team, and none of them can be pulled from a public registry at the moment of need.

Four moving parts: the main instance, Redis, the worker pool and PostgreSQL each need their own sizing, backup and monitoring plan.
Shared encryption key: the main instance's encryption key must be shared with every worker and webhook processor so they can decrypt credentials stored in the database. Treat that key as a top-tier secret and distribute it through your secrets process.
Webhook processors: if you run separate webhook processor nodes, they need the same key and must be reachable only from the networks that should send events.
High availability is Enterprise-only: multi-main setups, which run several main instances, are restricted to Enterprise self-hosted deployments and are not available in the Community edition.
Image provenance: mirror every container image and dependency into your internal registry and record its version.

Before committing to this layout, confirm with n8n which license tier your use requires and which setup your security team will accept for the shared key.

How to deploy the chosen platform without internet access

This sequence moves a self-hosted automation platform, its database and its vetted packages across an approved boundary so it runs and receives updates without outbound connections. The output is a verified, documented install inside the network with a known package inventory and a defined update path.

Build the mirrored image and package inventory
On a connected staging network, your platform or integration engineers pull every container image, Helm chart, language package and connector artifact the chosen platform needs, then record each one in a written inventory with its version and checksum. For Kubernetes clusters, kubeadm config images list and kubeadm config images pull fetch the control plane images in advance, so the cluster does not need to reach public registries later. For smaller installs using Docker Compose, the inventory lists each image referenced in the compose file. The step is done when the inventory matches the deployment manifests line for line.
Push artifacts to a private registry
Your platform team loads the staged images and charts into a registry hosted inside the boundary, then points the deployment at it. For Kubernetes, kubeadm init accepts the --image-repository flag so control plane images resolve to the private registry rather than a public one. Confirm the registry path in each manifest, including any sidecar or database images the platform pulls at start. The step is done when a test node can pull every image in the inventory with no route to the internet.
Transfer and verify artifacts across the boundary
Your security team moves the bundle through your approved cross-domain or media process, which is governed by your own procedures and any accreditation you hold. On the inside, an engineer recomputes the checksum of every file and compares it with the staging record, and reviews the software bill of materials for each component. Mismatches stop the transfer. This is where the supply chain controls described in NERC CIP-013-2 are relevant for utilities, which require verification of software integrity and authenticity for vendor software and patches. The step is done when every artifact matches its recorded checksum and the verification log is signed off.
Deploy PostgreSQL and the platform inside the boundary
Your platform engineers deploy PostgreSQL, either as a self-managed instance or an internal managed service, and then the automation platform's main and worker components using the mirrored images. Windmill documents support for external PostgreSQL such as AWS RDS, GCP Cloud SQL and Azure, and n8n queue mode uses PostgreSQL for workflow data alongside Redis for passing executions to workers. For n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read stored credentials, so record where that key is held. Confirm the database backups and the key escrow process before any production workflow runs. The step is done when all services report healthy and a test workflow runs end to end on internal systems only.
Vet connectors before they enter the platform
Your integration owners review each community or vendor connector, node or script before it is placed in the offline registry. The review covers source code, declared network endpoints, required credentials and the license of the package. Compare the licensing position first: n8n is under the Sustainable Use License, Activepieces is MIT with its ee directories under a commercial license, and Windmill's prebuilt Community images contain proprietary code. Record the approved connector versions in the same inventory from step one. The step is done when every connector in production has a signed review record and a version pinned in the inventory.
Load the license key for a paid edition
If you choose a paid edition, a licensed administrator enters the license key on the platform host so the platform enables the Business or Enterprise features. n8n's hosting documentation states that without a license key it runs as the free Community edition, and that a Business or Enterprise key enables those editions. Windmill's Enterprise Edition is a separate purchase with its own terms. Confirm with the vendor whether the license is validated online, or whether an offline activation or file-based key is available for your network, since this determines whether the platform can start with no outbound connection. The step is done when the edition shown in the admin console matches your purchase record.
Confirm the update path with the vendor
Before go-live, your platform owner asks the vendor in writing how new releases, security fixes and connector updates reach an isolated network. Ask whether images and packages can be downloaded as media, whether release signatures are published for verification, how long the vendor supports older versions, and whether license validation requires connectivity at upgrade time. Repeat the step-two to step-three cycle for each update, and file the release notes with the inventory. The step is done when the written answers are on file and a dry-run upgrade completes in a test environment.
Document the install and rehearse recovery
Your platform team writes the runbook: inventory location, registry paths, encryption key custody, backup and restore steps, and the procedure for importing the next media set. They then restore the database and the platform from backup on an isolated test host to prove the runbook works without the internet. Keep an evidence pack with the verification logs, configuration and test results, which helps assessors reviewing the deployment, although the assessment itself is performed by the independent auditor or certification body. The step is done when a restore from backup succeeds and the runbook has been reviewed by someone other than its author.

Licensing and operating risks to settle before go-live

A self-hosted replacement for an on-premises iPaaS moves licensing, edition choice and operations into your hands. The six decisions below are the ones that most often surface late, after workflows are already built and dependent on a platform.

n8n internal use limits

n8n's main codebase is licensed under the Sustainable Use License, which permits use only for your own internal business purposes or for non-commercial or personal use. Running it for your own staff is generally within that grant, but offering workflows as a service to other organizations, or redistributing the software, is not. Have counsel confirm that your intended use, including any partner or contractor access, fits the license text before you commit. This is a source-available license, not OSI open source.

Enterprise-only files in n8n

Files with .ee in their name or directory are not covered by the Sustainable Use License and require a valid n8n Enterprise License. Check which features your design depends on, such as SAML single sign-on or multi-main high availability, because building on them without a license creates a dependency you cannot run legally. Ask n8n to confirm in writing which components your deployment will load, and keep license keys under the same change control as the platform.

Windmill image terms versus source builds

Windmill source compiled without the enterprise feature flag is under AGPLv3 and Apache-2.0. The prebuilt Community Edition images include proprietary code that is free for internal use, while managed services or reselling require a commercial license. If you plan to offer Windmill to other business units through a managed service, or to resell it, the prebuilt image terms may not fit. Decide early whether to run prebuilt images or build from source, and record which one is in production.

Community edition limits

Windmill's Community Edition is free to self-host with unlimited executions, but it is capped at 3 workspaces, 50 users and 4 groups as of October 2026. A workspace layout that separates business units, environments or customers can reach that cap quickly. Map your intended workspace, user and group counts against these limits and confirm current figures on the pricing page, since limits change between releases.

Cost of enterprise identity and audit features

Single sign-on, provisioning and audit logging are typically the features regulated teams need first, and they sit in paid editions. In Windmill Enterprise these include SAML, SCIM, audit logs, and external secret backends such as Vault. In n8n, SSO and LDAP, Git environments and log streaming are limited to the Business and Enterprise plans. Price these as recurring license lines in your quote, and ask vendors which features are included for self-hosted deployments versus cloud.

Update cadence and offline patching

Windmill publishes releases frequently, and its latest release as of October 2026 was v1.840.0. Inside an isolated network, every upgrade, container image and connector package must be pulled outside, checked for integrity and authenticity, then carried across the boundary. Set a patch window, a staging environment for testing each release, and a rollback plan. Also confirm how your vendor delivers security fixes for the edition you chose.

Questions teams ask before running automation offline

What drives the cost and effort of an air-gapped Workato replacement?

The main drivers are the number of recipes and connectors to rebuild, how many of those connect to systems inside the isolated network, and how much of the platform you must mirror locally. Each recipe needs its logic rebuilt, its on-prem connections recreated and its credentials handled again. Scope also grows with the number of environments, the identity integration and the test evidence you need to keep. Ask for an inventory of recipes and connectors before comparing any quote, since that inventory is what separates a small rebuild from a large one.

Which costs are one-time and which recur in an offline automation platform?

One-time costs usually include design, rebuilding workflows, connector work, initial hardening, documentation and migration testing. Recurring costs include hosting and storage, staff time for patching and upgrades, backups, monitoring, and any commercial license or support contract. For an offline network, add the recurring cost of moving each vendor update through your transfer process and re-verifying it. Ask any provider to split its quote into these two groups so you can see what continues after go-live.

Can our internal team run an offline automation platform without outside help?

Often yes, if the team already operates containers, PostgreSQL and a secure update process, and has someone who can write and test workflows. The harder parts are usually the offline update path, connector testing against internal systems and evidence collection for assessors. Teams with little exposure to these areas often bring in an implementation partner for the rebuild and hand over operations afterward. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in the client's own infrastructure, including air-gapped networks, under a written scope.

How long does a migration off Workato take?

The duration depends on scope: the number of recipes, the connectors that reach internal systems, the environments, the identity integration and how much testing and documentation is required. DeployOpen agrees timelines in writing as part of a fixed scope before work starts, so ask for a timeline tied to a written inventory and deliverables rather than a general estimate.

What does the migration need from our side?

Plan for access to the recipe inventory, the list of systems each automation touches, named business owners who can confirm expected behavior, and a test environment inside the network. You will also need the people who manage the transfer path for software packages and container images, identity administrators for SSO, and someone who can recreate on-prem connections and credentials under your secrets policy. Agreeing these responsibilities in the written scope avoids delays at cutover.

How does the license choice change the cost of a self-hosted replacement?

License terms can change the cost more than the software itself. n8n is licensed under the Sustainable Use License, which allows use for your own internal business purposes, but files with .ee in their name require a valid n8n Enterprise License. n8n's pricing page lists a free self-hosted Community edition and a Business plan at 667 euros per month billed annually that is currently self-hosted only, with SSO and LDAP, Git environments and log streaming in Business and Enterprise. Windmill's Community Edition is free with limits of 3 workspaces, 50 users and 4 groups, while its self-hosted Enterprise Edition starts at $120 per month. Confirm current terms with each vendor and have legal review them against your use case, because license terms can change.

Will auditors accept a self-hosted automation runtime inside our network?

Auditors assess the controls around the system rather than the hosting model alone. A self-hosted runtime can support evidence for access control, change management, supply chain verification and logging, but it does not certify compliance by itself. For example, NERC CIP-013-2 addresses verification of vendor software and patches, which applies to what you bring across an isolated boundary. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications; independent auditors and certification bodies do that. Confirm the relevant control set with your assessor before design starts.

Evidence auditors and assessors ask for under an air-gapped design

An air-gapped automation platform is only as credible as the evidence behind it. The items below show an assessor that nothing leaves the boundary unchecked, who holds which licenses, and how the platform recovers. DeployOpen prepares this evidence, but independent auditors and assessors issue any assessment outcome.

Network diagrams with no outbound paths

Show every segment that hosts n8n or Windmill, its main instance, workers, PostgreSQL and any secrets backend, and mark every permitted flow between them. Assessors look for the absence of a route to the internet, so the diagram should also list the firewall rules that deny egress and where they are enforced. Confirm the diagram matches the live rule set, not the design intent, by sampling it during a review.

Inventory and integrity checks for transferred packages

Keep a register of every container image, package, connector and workflow file carried across the boundary, with its source, version and checksum. Record who approved each transfer and which scan ran on it before import. This is the evidence behind the supply chain control in NERC CIP-013-2, which asks how vendor software and patches are verified for integrity and authenticity. Confirm the exact verification method with your assessor before the first transfer.

License records for each edition in use

Record which n8n or Windmill edition runs in each environment, the license key or contract that covers it, and the terms that apply. n8n is source-available under the Sustainable Use License, and files with .ee in their name need a valid Enterprise License. Windmill's prebuilt Community images include proprietary code that is free for internal use only. Assessors will ask whether the use matches those terms, so keep the records current when editions change.

Access control and SSO configuration

Export the role assignments, the SSO configuration and the list of accounts that can edit workflows or view credentials. For n8n, SAML single sign-on is part of the Business and Enterprise plans, so confirm which edition supports the identity setup you document. Show how privileged accounts are reviewed and how access is removed when people leave. Keep the encryption key handling documented, because workers need it to read stored credentials.

Backup and restore tests for PostgreSQL and secrets

Keep recent restore records that prove the PostgreSQL database holding workflows and execution history, and the secrets store or encryption key, can be recovered together. A backup that restores the database without the matching key leaves credentials unreadable. Record the restore date, the person who ran it, and the result. Confirm the recovery time and retention targets with your own business owners, since no default is supplied here.

Change logs for updates and upgrades

Keep a dated log of each platform upgrade, patch, connector change and workflow release, with the approver and the offline source media used. Offline updates arrive as new packages, so the log should tie each version to the verified package in the inventory. Assessors often sample a few changes and trace them back to an approved request and a tested rollback. Check the release notes for each version before approving it.

How to move existing recipes into the self-hosted runtime

This sequence turns Workato recipes into tested, self-hosted automations one environment at a time, so each cutover is backed by an inventory, a rebuilt flow set and verified connections to internal systems. The output is a documented migration that the network owner and integration team can sign off on.

Export the recipe inventory from Workato
The integration lead, with an account that has the privilege Workato requires for lifecycle exports, builds a manifest and downloads the zip of JSON recipe and dependency files, following Workato's own export documentation. Store the package in the inventory system inside the network boundary, since it contains business logic and may reference internal endpoints. Done when every recipe in scope is listed in a spreadsheet with its owner, trigger, connectors, environment and business criticality.
Classify recipes by value and dependency
The integration lead and the business owners of each flow rank recipes by business value, risk and the number of internal systems they touch. Mark which flows depend on on-prem agent connections, lookup tables or other recipes, because those dependencies determine rebuild order. Done when the team agrees on a short list of first-wave flows and a parking list for flows to retire or rebuild later.
Stand up the self-hosted runtime in a test enclave
The platform team deploys the chosen runtime, such as n8n or Windmill, in an isolated test network with the same container and database layout planned for production, using Docker Compose or Kubernetes as the vendor documentation describes. Mirror the image sources and packages through an approved internal path, because the air-gapped transfer process must be proven before production. Done when the test instance starts, stores its data in the intended database, and an administrator can log in.
Rebuild first-wave flows as the specification
Developers rebuild each first-wave recipe in the target runtime, using the exported JSON as the functional specification for triggers, steps, field mappings and error handling. Map each Workato connector to a node or script in the target platform, and note any connector with no equivalent so it becomes a custom integration. Credentials and connections are recreated by hand in the new runtime, as they are with other exported automation formats such as Zapier and Make, so the team records each connection owner. Done when each rebuilt flow has a side-by-side comparison document covering inputs, outputs and known gaps.
Validate on-prem connections to internal systems
The integration team and the owners of internal systems test each rebuilt flow against non-production copies of those systems, confirming that the runtime reaches each endpoint through approved network paths and that credentials, certificates and service accounts behave as expected. Check failure handling, retries and alerting by forcing errors in the test enclave. Done when every connection passes a documented test script and the results, including any unresolved issues, are signed off by the system owners.
Run parallel outputs and compare results
Operate the rebuilt flows alongside the Workato originals for a period the business owners agree in advance, comparing outputs, record counts and error logs to confirm equivalent behavior. Keep Workato as the system of record until the comparison shows the expected results. Done when the comparison log shows no unexplained differences and the owners accept the results in writing.
Cut over by environment and retire Workato
Move flows environment by environment, starting with the lowest-risk environment, and disable the matching Workato recipes only after the target version is confirmed live. Update runbooks, access reviews and the change management record for each cutover, and set up backups and version control for the new flows. Done when all in-scope recipes are running in the self-hosted runtime, the Workato recipes are stopped and archived as the retained evidence, and the license and access decisions are recorded.

How DeployOpen plans an air-gapped automation deployment

DeployOpen plans and implements self-hosted automation platforms inside the client's own network, whether that is a private cloud account, a data center or an air-gapped segment. Work starts only after scope, deliverables and timelines are agreed in writing. For an air-gapped automation deployment, the written scope usually has to name the platform (for example, n8n or Windmill), the Community or Enterprise edition, the set of connectors and internal systems to reach, the offline update path and the license terms that apply to each component. Most engagements are fixed-scope, so the reader should expect the agreement to list what is in and out, such as whether connector rebuilds for on-premises systems are included and who owns the credentials and encryption keys.

The first planning decisions are usually about the boundary. DeployOpen's planning work typically covers how images, packages and connector code are staged across the isolated boundary and checked before they enter, how the workflow runtime reaches internal systems without outbound connections, and how administrators authenticate. Before scoping, ask the vendor or your own team to confirm which features are included in the edition you plan to run, since several capabilities discussed on this page (SSO, Git environments, multi-main high availability and air-gapped support) can sit behind paid tiers. Document these answers in the statement of work so later decisions do not depend on memory.

Ongoing support, upgrades and continuous testing are available as retainers, which fits the offline update cycle that air-gapped platforms require. A retainer covers the work after go-live, such as applying vetted releases, reviewing configuration drift and keeping backups tested. DeployOpen does not publish a price list. A quote follows from the written scope, so the most useful preparation is an inventory of target systems, expected automation volume, the number of environments and the compliance evidence your assessors will request. Ask for a quote that separates one-time implementation work from recurring retainer work, and ask which items depend on licensing decisions you have not yet made.

How DeployOpen works on this

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source automation platforms inside your own infrastructure, including air-gapped networks. For an on-prem constraint, we treat the offline package set, connector dependencies and update path as part of the design from the first week of scoping.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope lists which Workato recipes, on-prem systems and network paths the automation platform must reach.
We record which outbound connections are blocked, so connector and update requirements are settled before any build.

How we build

We deploy the chosen platform, such as n8n or Windmill, inside your network using its documented self-hosting method.
We stage container images, connector packages and libraries through an internal registry and check their integrity before import.
We rebuild flows against internal systems, test credential handling and confirm that encryption keys are managed as your controls require.

How we hand over

You receive architecture, runbooks and the offline update procedure, written for your own operations team.
We document licensing terms for the edition deployed, including which features need a paid license key.
Handover includes evidence for your compliance assessors, which DeployOpen prepares but independent auditors and certification bodies assess.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Each upgrade cycle includes staging the new release, re-verifying the package set and updating the runbooks.
Ask us in the quote how support covers offline updates, security testing of flows and changes to connectors.