Why a Google SecOps SOAR alternative for air-gapped networks starts with the boundary
If your network cannot accept a cloud SOAR reaching inside through remote agents that pull tasks over the Publisher proxy, the first decision is where the automation platform itself will live. Shuffle or Tracecat can both run fully inside your own boundary, with no runtime dependency on a vendor-hosted control plane. That answer only holds if the rest of the detection path moves with it. The SOAR layer cannot be self-hosted while alerts still arrive through a bundled SIEM whose data path leaves your network, so the SIEM and its ingestion pipeline must be replaced or rebuilt inside the boundary as well.
Start by mapping every connection the current setup makes. List each remote agent, each Publisher proxy path, every ingestion source and every place where case data or enrichment results are stored. Then classify each flow as internal only, one-way out or bidirectional. The NERC CIP-005-7 standard, which covers electronic security perimeters for certain energy sector systems, shows the kind of documented access control auditors expect at a boundary. Your own controls may differ, so confirm the relevant framework with your assessor before you design around it.
The topic facts do not establish that Google's model cannot be configured for some networks, so confirm this with Google in writing before you assume it cannot. Ask specifically whether any SOAR component can run without outbound connectivity, whether any agent can operate without the Publisher proxy, and what happens to playbook execution and case history if the link is cut. Record the answers. Those answers, not general marketing claims, should decide whether a migration is needed.
What an air-gapped or on-premises boundary requires from SOAR
A SOAR platform inside an isolated network has to run without outside connections, pull its images and packages from inside the boundary, and control who reaches it and how. The cards below set out each requirement, the fact that supports it, and what to confirm before you commit to Shuffle or Tracecat.
No runtime internet access
Google SecOps reaches your internal systems through remote agents that pull tasks over a proxy, which assumes an outbound path exists. A self-hosted platform inside an air-gapped network must run every workflow, app and integration without calling out at runtime. Tracecat documents an air-gapped Kubernetes deployment with no runtime internet access, and Shuffle's hybrid model needs no inbound firewall ports for a local Orborus. Confirm which apps and connectors call external endpoints, such as threat intelligence feeds, and whether each one can point to a local service.
Private image registries
Shuffle runs each app as a versioned Docker container, and Tracecat deploys on Kubernetes through Helm. Both require images to come from a registry your network can reach. For Kubernetes control planes, kubeadm can fetch images ahead of time and point kubeadm init at a private registry with the --image-repository flag. Ask who mirrors images into the boundary, how new app versions are tagged, and whether the Shuffle docs' guidance to use the latest Docker tag for stable releases fits a change-controlled environment.
Offline updates and package verification
Updates arrive on physical or transfer media, not from the internet. NERC CIP-013-2 is a regulatory example that requires supply chain procurement to address verification of software integrity and authenticity for vendor software and patches. Apply that test to every container image, app specification and Python package crossing the boundary. Ask the vendor for signed release artifacts and a documented offline update path, and record who checks each transfer before it is installed.
Controlled remote access and MFA
NERC CIP-005-7 is a regulatory example for high and medium impact BES Cyber Systems. It requires interactive remote access to pass through an Intermediate System with encryption and multi-factor authentication, and it expects methods to detect and disable active vendor sessions. If your SOAR console or vendor support path reaches the boundary, route it through that controlled point. Outside utilities, the same pattern is a useful design choice, but it is not a universal rule. Confirm how the platform's admin console and vendor access are routed before go-live.
Local authentication and secret encryption
Your boundary may not allow a cloud identity provider. Shuffle supports SAML single sign-on from version 0.9.16 and OpenID Connect from 1.0.0, both available on-premises, so you can point it at a directory inside the network. Shuffle also encrypts saved app credentials in OpenSearch with AES-256 using SHUFFLE_ENCRYPTION_MODIFIER. Store that secret outside the platform, back it up, and never change it, because losing or changing it breaks every saved app authentication. Tracecat lists SSO as an enterprise feature, so confirm it before relying on it.
Where Google SecOps SOAR meets the constraint and where it does not
The first question for an isolated network is not whether Google SecOps SOAR has integrations, but where its control plane runs and how it reaches your systems. Google SecOps SOAR is delivered as a cloud service. Its remote agents sit inside your network, make outbound connections, and pull tasks from the platform through the Publisher proxy, so the integrations execute locally while orchestration, case data and playbook logic live in Google's environment. That model is neutral and works well where outbound connectivity is permitted and the data path is acceptable. For a network that prohibits outbound sessions or requires alert data to stay inside a defined boundary, the reader should map each flow explicitly: which alerts leave the boundary, which case fields are stored in the cloud, and which of those flows a security authority would need to approve.
The supplied facts do not document a fully disconnected deployment of Google SecOps. Do not assume that an air-gapped option exists or that it covers the SIEM, the SOAR, or both. Ask Google, in writing, for the current deployment options, the exact traffic that the remote agents and Publisher proxy generate, where case and playbook data are stored, whether any component can operate with no internet route, and what happens to automation when the cloud connection is interrupted. Ask for the answers as they apply to your contract and region, and keep the written responses in the compliance file. If Google confirms that its platform requires a cloud connection, the question for your architecture becomes whether an isolated network can accept that dependency at all.
If the answer is no, the practical options are to run an orchestration platform entirely inside your boundary. Shuffle and Tracecat both document self-hosted paths, with Tracecat listing an air-gapped Kubernetes deployment with no runtime internet access. Plan for what that move requires: a local registry for container images, a process for importing vetted app and integration updates, and ownership of backups and upgrades. The decision also changes what you give up. Google SecOps SOAR is sold alongside its SIEM, so moving SOAR alone means deciding how alerts reach the new platform from the existing SIEM, and whether that SIEM can run in the same boundary.
Which open-source platforms fit an on-premises SOAR under this constraint
Shuffle has the widest set of documented deployment patterns in this group, and every server component can run inside your boundary. Its server side is a frontend, a Go backend API on port 5001 and an OpenSearch document database. Orborus polls the backend for jobs, starts a worker for each workflow execution, and the worker starts app containers. The Shuffle install guide lists Docker and Kubernetes as installation methods.
- Docker Compose: A single server suited to evaluation or a small team. The install guide says the default Compose setup is not scalable without changes and needs at least 4 GB of RAM.
- Docker Swarm: A distributed Docker deployment across several hosts, with the backend and frontend scaled across servers and more than one Orborus node so workflows keep running if one fails.
- Kubernetes with Helm: The pattern for high availability. Plan an OpenSearch cluster, optional Memcached for a shared cache, and NFS for shared files when you run several backends.
- Hybrid cloud plus local Orborus: Shuffle Cloud hosts the control plane while a local Orborus runs workflows without inbound firewall ports. The control plane sits outside your boundary, so do not use this pattern under a strict air gap.
- Key handling: Saved app credentials are encrypted with AES-256 using the
SHUFFLE_ENCRYPTION_MODIFIERsecret. Losing or changing it breaks every saved app authentication, so store it in your secrets manager.
Confirm which pattern your network boundary allows and whether every app image can be mirrored into your private registry before you choose.
Tracecat combines workflows, cases, structured tables and AI agents in one platform, and its documentation covers a self-hosted air-gapped Kubernetes path. Its stack is Python with FastAPI on the backend, Next.js on the frontend, Temporal for durable workflow execution, PostgreSQL for data, an S3-compatible object store and nsjail for sandboxing. The core repository is licensed under AGPL-3.0, and the Tracecat documentation covers the deployment options.
- Docker Compose: A single-host deployment for evaluation or a contained pilot.
- Kubernetes with Helm: A standard cluster deployment through a Helm chart. You operate Temporal, PostgreSQL and the object store alongside it.
- Air-gapped Kubernetes: A documented deployment with no runtime internet access. Confirm that every image and chart dependency, including Temporal, can be mirrored into your registry.
- AWS ECS Fargate through Terraform: Documented, but it runs in a cloud account, so it only fits an isolated boundary if that account sits inside the boundary.
- Enterprise features: SSO, multi-tenant workspace management and Git version control integration are listed as enterprise features under a separate license. If your identity model depends on them, price the Enterprise Edition into your plan.
Ask Tracecat in writing which features your air-gapped design needs, because the free edition and the enterprise gates differ.
StackStorm is an Apache 2.0 licensed, event-driven automation platform described for auto-remediation, incident response, troubleshooting and deployments. Sensors emit events, and rules trigger actions in response. It is closer to operations automation than to a case-driven SOAR, so treat it as an option to evaluate for response automation rather than a default. The StackStorm releases page lists its versions.
- License: Apache 2.0, a permissive license that allows self-hosting without a per-user or per-ingestion fee from the project.
- Release and runtime: The 3.9.0 release, dated January 12, 2025, supports Python 3.8 to 3.11 and moved to pymongo 4.x. Check these against your interpreter and database baseline.
- Event-driven model: Suited to automated remediation and infrastructure response that follows a defined trigger.
- Case management gap: The project description does not list case management, an analyst queue or approval flows. Confirm what you would have to build yourself.
- Offline packaging: Confirm the install method and pinned dependencies you can mirror into an isolated network before you plan the build.
Review the 3.9.0 release notes against your build pipeline before committing an isolated network to StackStorm.
n8n is not one of the recommended options for this constraint. It appears here so the licensing position is clear before anyone proposes it. Its Sustainable Use License permits internal business use and non-commercial or personal use, and files marked .ee require a valid n8n Enterprise License. The n8n LICENSE.md file sets out the terms, and the project is source-available, not OSI open source.
- Permitted use: Internal business use is allowed under the license text, but the full terms should be reviewed for your specific deployment.
- Enterprise files: Any .ee file requires a valid Enterprise License, so a build that touches them carries a license obligation.
- OSI status: The project is source-available and is not OSI open source, which matters if your policy requires OSI-approved licenses.
- Scope questions: Ask legal whether any hosting, redistribution or service model falls outside internal use.
- Written position: Ask the vendor how the license applies to an air-gapped deployment and get the answer in writing.
Get a written licensing position before using n8n for security automation in a regulated environment.
How Shuffle, Tracecat and StackStorm compare on licensing, edition limits and offline fit
This table compares the three open-source options on license, edition split, offline deployment, SSO and what sits behind a paid tier. Read it as a checklist: items marked for verification change with each release, so confirm them against the current edition before you commit.
| Criterion | Shuffle | Tracecat | StackStorm |
|---|---|---|---|
| License | Backend under AGPL-3.0, workflows, docs, apps and app specifications under MIT | AGPL-3.0 core, with packages/tracecat-ee and enterprise feature gates under a separate paid license | Apache 2.0 for the core platform |
| Paid edition limits | All features in the open-source edition; paid tiers differ in limits, scaling and support, and limits are enforced since v2.1.1 | Multi-tenant workspace management and Git version control integration are Enterprise features | No commercial edition described in the supplied material; confirm with the vendor |
| Offline or air-gapped deployment | Docker Compose, Docker Swarm or Kubernetes with Helm; no internet dependency is documented, but confirm image mirroring for your registry | Documented air-gapped Kubernetes deployment with no runtime internet access | Self-hosted on your own servers; confirm the offline packaging and dependency steps for your environment |
| Single sign-on | SAML since 0.9.16 and OpenID Connect since 1.0.0, with per-tenant enforcement; SAML is being deprecated on Shuffle Cloud | Authentication and SSO are described as enterprise features; verify whether your deployment needs the paid edition | Not covered in the supplied material; confirm with your identity team |
| Database and runtime | OpenSearch document store, Orborus runtime polling the backend, app containers per execution | PostgreSQL, Temporal for durable workflows, S3-compatible object store, nsjail sandboxing | Event-driven rules and actions; confirm the MongoDB dependency and version for your release |
| Minimum footprint | Install guide states a minimum of 4 GB of RAM; the default Compose setup is not scalable without changes | Multiple services including Temporal and PostgreSQL; plan capacity on your own sizing tests | Not covered in the supplied material; size against your own rule volume |
| Release currency | v2.3.0 published on GitHub; use the latest Docker tag for stable releases | 1.2.0 released on GitHub; confirm the tag your team pins | 3.9.0 released January 12, 2025; supports Python 3.8 to 3.11 |
How to deploy Shuffle or Tracecat entirely inside your boundary
This sequence takes a SOAR platform from sizing and offline image preparation through a running, backed-up instance that receives alerts from your own SIEM, with no step depending on outbound internet access.
Size the platform and choose the deployment model
The platform owner and the architecture lead decide which product fits the boundary and how large the first build must be. Shuffle's install guide states a minimum of 4 GB of RAM and warns that the default Docker Compose setup is not scalable without changes, so a single-server Compose build is suitable only for evaluation. Shuffle documents Docker Swarm and Kubernetes with Helm for production, while Tracecat documents Docker Compose on a single host and an air-gapped Kubernetes deployment. Confirm the sizing for your alert volume and your high availability requirement with the vendor before procurement. The step is done when the team has a written architecture diagram, a node count and a named owner for each component.
Build the Kubernetes cluster without internet access
The cluster engineer prepares the control plane images on a connected staging host, then moves them into the boundary. The kubeadm documentation describes running kubeadm config images list and kubeadm config images pull in advance, so the nodes never need to reach a public registry. On the isolated network, kubeadm init is pointed at your private registry with the --image-repository flag. Record the Kubernetes version and every image digest in the change record so later upgrades start from a known baseline. The step is done when kubeadm init completes and all nodes report Ready with no outbound connections.
Mirror container images and app containers
The platform engineer copies every image the stack needs into the internal registry: the Shuffle frontend, backend, Orborus and worker images, OpenSearch, and any Shuffle app containers the team plans to run. For Tracecat, the mirror includes its API, frontend, Temporal, PostgreSQL and object store images. Pull by digest rather than by floating tag, because the Shuffle docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes, and a floating tag can change between staging and the boundary. Scan each image in the registry with the scanner your security team already approves. The step is done when a manifest test deploys from the internal registry alone and the registry log shows no pulls from external hosts.
Set and back up the encryption secret
The security engineer generates SHUFFLE_ENCRYPTION_MODIFIER and stores it in the organization's approved secrets store, not in a shared configuration file. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using this value, and the Shuffle docs warn that losing or changing it breaks every saved app authentication. Store two offline copies under separate custody, and document the restore procedure in the runbook. Test a restore on a non-production instance before any integration is built. The step is done when a restore test decrypts a saved test credential and the custodians have signed the custody record.
Configure OpenSearch or PostgreSQL and object storage
The data engineer deploys the storage tier that the chosen product needs. For Shuffle, the configuration docs recommend an OpenSearch cluster for high availability, optional Memcached for a shared cache, and NFS for shared files when running several backends. For Tracecat, provision PostgreSQL for application data and an S3-compatible object store for files and artifacts, both inside the boundary. Enable snapshots or backups for each store and test one restore into a separate environment. The step is done when the cluster health check passes, a snapshot restores successfully, and the backup job's output is reviewed by someone other than its operator.
Bring apps and packages across the boundary with verification
The integration engineer moves app definitions, Python dependencies and custom content through a controlled transfer path. Shuffle apps are built from OpenAPI specifications in the App Creator or written with the Shuffle app SDK, and they run as versioned Docker containers, so each app is a reviewable artifact. Tracecat custom actions can be synced from Git, which gives the team a commit history to review. Check the integrity and authenticity of every package against the publisher's published checksums or signatures before it crosses, and log the approver. The NERC CIP-013-2 requirement for verifying software integrity and authenticity is a useful model for this evidence even outside the electricity sector. The step is done when each imported artifact has a recorded hash and an approval record.
Configure Orborus workers or Tracecat workers for execution
The platform engineer deploys the execution layer that runs playbooks. In Shuffle, Orborus polls the backend for jobs and starts a worker for each workflow execution, so the team should deploy more than one Orborus node so that workflows keep running if one fails. Confirm that the worker can reach only the internal systems it needs, and block all egress to the public internet from the worker subnet. In Tracecat, Temporal runs durable workflow execution, so verify its persistence and failover settings. The step is done when a test workflow runs to completion on each worker, and a forced restart of one node does not lose the run.
Rewire alert sources from the SIEM
The detection engineer repoints alert delivery from the SIEM to the new platform. Confirm first which SIEM is retained, since the SOAR-only move leaves the SIEM in place, and whether that SIEM can forward to a webhook or syslog endpoint inside the boundary. Start with low-volume, low-risk alert types and compare the case count in both systems for a fixed period you choose. Keep the old SOAR connection disabled but not deleted until the rollback window closes. The step is done when a set of alerts produces matching cases in the new platform, and the operations lead signs the cutover record.
What auditors and regulators ask to see for an isolated SOAR
An isolated SOAR is judged on what crosses the boundary, who can reach it and whether its automation can be reconstructed later. The six items below are the records most often requested in assessments of OT and regulated environments, and each one links to the others.
Architecture and boundary diagrams
Auditors want a current diagram showing where Shuffle or Tracecat runs, which networks it can reach, and which direction each connection is initiated. For an air-gapped design, the diagram should show every point where files, images or updates enter, such as a one-way transfer station or a removable media process. Check that the diagram matches the deployed Docker Compose, Kubernetes or Helm topology, including the Orborus runtime nodes that start app containers.
SBOM and image provenance records
Every container image, app package and Python dependency carried across the boundary needs a record of its origin, version and checksum. This is the evidence behind NERC CIP-013-2 supply chain controls, which expect software integrity and authenticity to be verified for vendor software and patches. Ask for a software bill of materials for each release you import, and keep the signed or hashed artifact alongside it.
Change logs for offline updates
Offline upgrades are a common audit finding because they happen outside normal change tooling. Record each transfer with the artifact name, source media, approver, date imported and the test run that preceded production. Shuffle's docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes, so the log should show which tag was deployed and why.
Remote access and MFA configuration
Where a regulator applies an electronic security perimeter model, remote access must pass through a controlled intermediate point with encryption and multi-factor authentication. Document the configured identity provider, the MFA method for each role, session timeouts and how vendor sessions are detected and disabled. For Shuffle, retain the SSO configuration, including whether SAML or OpenID Connect is enforced per tenant.
Backup and encryption key custody
Shuffle encrypts saved app credentials in OpenSearch using the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that value breaks every saved app authentication. Auditors will ask who holds this secret, where it is stored, how it is backed up and who can retrieve it. Keep a custody record with named holders, storage location, rotation history and a tested restore that shows the database and secret can be recovered together.
Workflow execution logs
Evidence of automated response needs a trail showing which workflow ran, what triggered it, which apps executed each action and what the outcome was. Shuffle counts app runs as its licensing unit, so the same logs also show usage. Confirm that execution history is retained long enough for your incident records and is exported to the boundary's log store, since an isolated platform cannot rely on a vendor-hosted audit trail.
What does it cost and take to replace Google SecOps SOAR on an isolated network?
What drives the effort of moving Google SecOps SOAR onto an isolated network?
The main drivers are the number of playbooks, the number and type of integrations, how often you must update the platform offline, and the skills your team already has. Each playbook has to be rebuilt as a Shuffle workflow or a Tracecat workflow, and each integration needs either a Shuffle app built from an OpenAPI specification or a Python app written with the Shuffle app SDK, or a Tracecat custom action. Offline updates add work because you must bring each new release across the boundary and verify it before deployment. Ask for an inventory of playbooks and connectors before any quote, since that inventory sets most of the scope.
Can our team run an air-gapped SOAR platform without outside help?
Yes, if you have people who can operate Kubernetes or Docker, manage an offline image registry, write or maintain integrations, and review workflow changes. Shuffle documents single-server Docker Compose, Docker Swarm and Kubernetes with Helm charts, and Tracecat documents an air-gapped Kubernetes deployment with no runtime internet access. Teams without that background usually need help with the first build, the offline update process and the integration work. A fixed-scope engagement, agreed in writing, can cover some or all of that work while your staff keep ownership of the platform.
How long does a replacement take on an isolated network?
The timeline depends on the scope agreed in writing, so no fixed figure applies. Scope includes the number of playbooks to rebuild, the number of integrations to replace, the hosting design, the offline update path, and whether high availability is required. Shuffle's configuration docs recommend an OpenSearch cluster, shared storage and more than one Orborus node for high availability, which adds build and testing time. Ask for a written plan with milestones and acceptance tests, and ask which items depend on your change approval and access windows.
What does the client need to provide for an isolated SOAR deployment?
You need to provide a network access plan that defines how software, container images and rules cross the boundary, an internal container registry that holds every image the platform needs, and named owners for each app and integration. Kubernetes can be built without internet access by pulling control plane images in advance and pointing kubeadm at a private registry. Shuffle also needs a secret for encrypting saved app credentials, so you must decide who holds it and how it is backed up, because losing or changing it breaks every saved app authentication. Shuffle requires at least 4 GB of RAM for its install.
Does the Shuffle app run metric or the Tracecat paid edition change the cost?
Yes, it can. Shuffle prices its paid licensing on app runs, which count actions that actually execute in a workflow, while triggers and skipped actions are not counted. Users, apps and workflows are unlimited, and Shuffle says all features are in the open-source edition, with paid tiers differing in feature limits, scaling and support. Tracecat's repository places multi-tenant workspace management, Git version control integration and authentication and single sign-on in its Enterprise Edition. Confirm in writing which features your use case needs and whether they fall under a paid tier before choosing a platform.
Do we have to replace the SIEM as well as the SOAR?
No. SOAR replacement can proceed without changing the SIEM, but the alert feed must then reach the new platform across your boundary. Google SecOps bundles the SIEM and SOAR, so moving the SOAR alone means you must repoint alert ingestion and decide how logs and detections reach the new system. If you also need an on-premises SIEM, Security Onion supports full installs without internet access and Wazuh publishes an offline installation guide, but each has its own sizing and maintenance work. Confirm your detection and log retention requirements before choosing the scope.
What recurring costs should we expect after the platform is live?
Recurring costs include the infrastructure that hosts the platform, the internal registry and storage, the staff time to maintain workflows and integrations, and the offline update cycle for each release. Shuffle's release tags are updated frequently, and the docs recommend the latest Docker tag for stable releases, so you must test and carry each update across the boundary. If you use a paid tier or external support, those fees recur as well. Ask any vendor or partner for the recurring items in writing, separately from the one-time build work.
What you give up from the bundled SIEM when SOAR moves in-boundary
Moving SOAR alone means you stop getting the bundled SIEM data path. In Google Security Operations, alerts, entities and enrichment reach the SOAR side from the same platform that ingests your logs. When Shuffle or Tracecat runs inside your boundary, that path disappears. Something else must produce the alerts, normalize the events and hand them to the automation platform through a webhook, API, queue or syslog feed. Before you design the playbooks, list every alert source your current workflows depend on, note which ones come from the SIEM, and decide which of those will keep feeding the new platform and which will be replaced.
Self-hosted detection can fill part of that gap, and two examples publish offline guidance. Wazuh documents an offline installation guide for systems without internet connectivity, and its vulnerability detection can use an offline vulnerability repository in place of its cloud threat intelligence feed. Security Onion supports full installs without internet access, ships NIDS, YARA and Sigma rules on its ISO, and updates from newer media in airgap mode through its soup tool. Either can produce alerts for Shuffle or Tracecat to consume, but neither replaces a full SIEM's search, retention and correlation features, so confirm which of those you still need.
Confirm integration fit with your chosen SIEM before you commit to a platform. Ask the SIEM vendor or your own engineers which alert formats, APIs and event delivery methods it supports, whether it runs fully offline in your environment, and what retention and search capacity it needs. Then check whether the automation platform has an app or connector for that source and what it takes to build one. Shuffle's app creator works from OpenAPI specifications, and Tracecat supports custom actions, so a source with a documented API is easier to connect than one that only writes files.
How DeployOpen deploys SOAR inside an isolated boundary
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For Google SecOps SOAR alternatives, that means running Shuffle or Tracecat entirely within your boundary, with the integrations, identity and evidence your assessors will ask for.
How we scope
- Written scope covers which automation use cases move, and which stay in Google SecOps during the transition.
- We inventory the internal systems each workflow must reach, and confirm which need inbound or outbound paths inside the boundary.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy Shuffle or Tracecat on Docker, Kubernetes or an air-gapped cluster in your environment, with components pulled from an internal registry.
- We configure OpenSearch or PostgreSQL backups, secret handling and single sign-on to match your identity controls.
- We test workflow execution, app credentials and failover paths, then document the results for review by your assessors.
How we hand over
- You receive architecture diagrams, runbooks, configuration records and the workflow inventory with owners named.
- We document the offline update path, including how each package and container image is verified before it crosses the boundary.
- Handover includes walkthroughs with the teams who will maintain workflows, apps and the platform after go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, agreed separately from the initial scope.
- Security testing of the deployed platform, including its apps and API surface, can be scoped alongside the build.
- We prepare systems, controls and evidence for compliance assessments; independent auditors and certification bodies issue the actual reports.
