Why an air-gapped SOC needs a SOAR it can run without FortiGuard
Shuffle and Tracecat can both run fully offline once container images, app updates and documentation are carried across the boundary, so the real decision is which features you give up or pay for, not whether the core engine works without a vendor connection. FortiSOAR ties licensing to FortiGuard, to FortiManager or to a manually supplied entitlement file, so an air-gapped SOC has to plan that entitlement path before the network closes. Both open-source options remove that dependency for the core engine, but they do not remove the need for a transfer process. Treat every image, app version and rule update as an item that crosses an approved boundary, with a record of what was checked, by whom and when.
The transfer process is the main work. Shuffle runs its server components, its Orborus runtime and every app as versioned Docker containers, so the images for your chosen install path (Docker or Kubernetes) and each app image your playbooks call must be pulled on a connected host, scanned and loaded into an internal registry. Tracecat's documented air-gapped option is Kubernetes with no runtime internet access, which means the Helm chart, the Python backend and Next.js frontend images, Temporal, PostgreSQL and the S3-compatible object store all need local copies. Ask each vendor for the exact image list for the version you pin, avoid tracking the nightly tag in a closed network, and test a restore from the mirrored set before go-live.
The trade-offs sit in edition gating and licensing. Shuffle states that all features are available in its open-source edition, while its paid tiers differ in feature limits, scaling and support, and since v2.1.1 those limits are enforced. Shuffle's paid licensing counts app runs, so confirm in writing whether enforced limits require any license check that reaches the vendor. Tracecat's single sign-on, multi-tenant workspace management and Git version control integration are Enterprise Edition features under a separate license, so a team that needs SSO should price that edition before choosing. Put these questions into the written scope and ask each vendor to confirm offline license behavior in writing.
What an air-gapped boundary requires from a SOAR platform
A SOAR platform inside a closed network has to run without a vendor phone-home, accept software across the boundary in a verifiable way, and keep vendor access controlled. The cards below set out the four requirements that connect those concerns, and each one is a check to run against FortiSOAR, Shuffle and Tracecat before you commit.
No runtime internet access
Confirm that the platform starts, authenticates users, runs playbooks and writes logs with no outbound calls. Shuffle documents a hybrid model where a local Orborus needs no inbound firewall ports, but that model assumes a cloud backend, so an isolated deployment should use the self-hosted architectures instead. Tracecat documents an air-gapped Kubernetes deployment with no runtime internet access. Ask each vendor to list every external endpoint the product contacts at runtime, including update checks and telemetry, and test those in a staging enclave.
Offline image and package intake
Every container image, app package and content update crosses the boundary through a controlled path. Kubernetes lets you pull control plane images ahead of time and point the installer at a private registry, which is the pattern to copy for SOAR images. Shuffle apps run as versioned Docker containers, so each app image needs to be mirrored and pinned. Record the source, hash and approver for each artifact, and confirm how each vendor's update path works without a live connection.
Integrity and authenticity checks
Software crossing an isolated boundary should be verified before installation. NERC CIP-013-2 asks utilities to address verification of software integrity and authenticity in their supply chain procurement processes, and this is the control that governs package intake. Ask vendors how they sign releases, publish checksums and document provenance for apps and content. Your team should verify signatures on the staging side and keep the verification record with the change ticket. Whether CIP-013-2 applies to you depends on your entity registration and asset classification, so confirm that with your compliance lead.
Controlled vendor remote access
Vendor support sessions into a closed network are a common path for compromise, so plan for them as a designed exception. NERC CIP-005-7 requires that Interactive Remote Access to high and medium impact BES Cyber Systems pass through an Intermediate System with encryption and multi-factor authentication, and that active vendor sessions can be detected and disabled. Apply the same pattern to any SOAR platform: a jump host, session recording and a documented kill switch. Confirm with your auditor whether this standard or a similar control applies to your environment.
License model that does not phone home
Licensing is a runtime dependency when it checks a vendor service. FortiSOAR fetches license entitlements from FortiGuard and needs FortiManager or a manual entitlement file in closed networks. Shuffle licensing is counted per app run and the open-source edition enforces limits between editions since v2.1.1, so confirm how limits are checked and whether any check needs a network call. Ask each vendor for written confirmation of offline license validation, the renewal process and what happens when a license cannot be refreshed.
Where FortiSOAR licensing depends on vendor contact
The first question for an air-gapped team is not whether FortiSOAR runs without internet access but how its license entitlements are refreshed when the network cannot reach the vendor. FortiSOAR fetches license entitlements from FortiGuard, and in closed networks the supplied route is either FortiManager or a manual entitlement file. Each route puts a dependency on the vendor side of the boundary, so the license state of the platform is tied to a process that someone on your team must own and repeat. Treat that process as an operational control, not as a procurement detail.
Before you commit to the closed-network design, get written answers from Fortinet on several points. Ask how renewals are delivered and whether a renewed entitlement can be applied to an isolated system without FortiGuard connectivity, and which steps your team performs on each renewal. Ask how often entitlements need refreshing, what happens to a running instance when an entitlement lapses or cannot be refreshed, and whether a grace period exists. Ask what the manual entitlement file contains, who issues it, and whether it is tied to specific hardware or instance identifiers. Confirm these details in the contract and the vendor's current documentation, since they determine how much of your staffing and change calendar the licensing process will consume.
Update media raises the same questions. Ask Fortinet whether platform and content updates for an isolated FortiSOAR deployment arrive as signed packages you can carry across the boundary, how those packages are verified, and whether connector and module updates follow the same route as platform releases. Your own supply chain procedures will need to record how each package was checked before it enters the enclosure, in line with the software integrity and vendor patch verification expected under NERC CIP-013-2 where it applies. For Shuffle or Tracecat, the equivalent question is whether you can mirror images and app updates on your own schedule, which the next sections compare directly.
Shuffle and Tracecat against FortiSOAR for offline operation
This table compares how FortiSOAR, Shuffle and Tracecat handle licensing, container delivery, runtime, updates and identity when the network has no internet access. Read each row as a question to put to the vendor and to your own team before a cutover. The main takeaway is that licensing and update delivery need the most confirmation, while Shuffle and Tracecat both offer container-based deployment that can be mirrored into an internal registry.
| Offline requirement | FortiSOAR | Shuffle | Tracecat |
|---|---|---|---|
| License activation | Fetches entitlements from FortiGuard; closed networks need FortiManager or a manual entitlement file | Licensing is priced by app runs; limits are enforced since v2.1.1. Confirm behavior with no external license check | Core is AGPL-3.0; Enterprise code needs a separate paid license. Confirm how it is activated offline |
| Container images in a closed network | Confirm with Fortinet how offline packages and updates are delivered | Runs on Docker or Kubernetes; mirror the images into an internal registry and pin tags | Documented air-gapped Kubernetes deployment with no runtime internet access; mirror images internally |
| Runtime and execution | Confirm the components that must reach FortiGuard or FortiManager during normal operation | Orborus polls the backend and starts a worker and app containers; all of it runs inside your network | Temporal runs durable workflows, with PostgreSQL, an S3-compatible store and nsjail sandboxing, all self-hosted |
| Integration updates | Connector updates depend on the vendor's delivery channel. Confirm the offline process | Apps are versioned Docker containers built from OpenAPI specs or the Python SDK, so they can be imported offline | Custom actions sync from Git, so an internal Git server can carry them. Confirm the sync path stays inside the boundary |
| Platform upgrades | Confirm how the offline upgrade bundle is obtained and validated | Track Docker tags: latest for stable and nightly for experimental. Test each new tag before mirroring | Release 1.2.0 is the latest version supplied. Mirror and test each release in a staging enclave |
| Single sign-on | Confirm which identity protocols work against an internal directory | SAML was added in 0.9.16 and OpenID Connect in 1.0.0, available on-premises | SSO is an Enterprise feature under the paid license. Confirm it fits your offline identity design |
| Multi-tenant separation | Confirm tenant isolation options for the deployment model you choose | Per-tenant SSO enforcement is available; confirm tenant isolation against your own requirements | Multi-tenant workspace management is an Enterprise feature under the paid license |
| Credential and key recovery | Confirm where vault and export data is kept and how it is restored | Saved credentials are AES-256 encrypted with SHUFFLE_ENCRYPTION_MODIFIER. Losing it breaks all app authentications | Confirm how the encryption and database secrets are backed up, stored and restored inside the enclave |
How to deploy Shuffle or Tracecat fully offline
This sequence takes a closed network from an inventory of every image, package and rule file to a tested SOAR deployment that can receive vetted updates through a controlled transfer path. Each step ends with a check you can confirm before moving on.
Build an offline artifact inventory
Your platform team lists every item the deployment needs before anything crosses the boundary: container images for the frontend, backend, OpenSearch, Orborus and app containers for Shuffle, or the Tracecat services, PostgreSQL, Temporal, the S3-compatible store and nsjail for Tracecat, plus Helm charts or Compose files, app specifications and the install guide version. Record each item with its version tag, digest and checksum. Confirm the tags you plan to use against the Shuffle releases page or the Tracecat releases page, and confirm the current Shuffle tag guidance in the configuration docs. Done when the inventory has a named owner and every item maps to a source you can reproduce.
Mirror container images to an internal registry
Pull each image in the inventory on a connected staging host, verify its checksum, and push it to a private registry inside the enclave. Update every manifest, Compose file and Helm value to reference the internal registry path rather than a public one. If you deploy Shuffle on Kubernetes or Tracecat on a cluster, the same pre-staging idea applies: the kubeadm documentation shows how control plane images can be listed and pulled ahead of time, and the --image-repository flag points kubeadm at a private registry. Done when a clean host inside the enclave can pull every image with no outbound network access and every pull is logged.
Deploy the Shuffle or Tracecat core services
For Shuffle, deploy the frontend, the Go backend API on port 5001, OpenSearch and at least one Orborus node, using the single-server Compose or Kubernetes Helm architecture. Note that the default Docker Compose setup is not scalable without changes and needs at least 4 GB of RAM. For Tracecat, deploy the backend, frontend, PostgreSQL, Temporal, the S3-compatible object store and worker services, using its air-gapped Kubernetes option where it fits your standards. Confirm that no service attempts an outbound call during startup by checking the logs and egress rules. Done when the UI loads from inside the enclave and a test workflow runs end to end.
Configure and back up the encryption secret
Set SHUFFLE_ENCRYPTION_MODIFIER before saving any app credential, because Shuffle uses it to encrypt saved app credentials and API keys in OpenSearch with AES-256. Store the value in your secrets manager, and document that changing or losing it breaks every saved app authentication. For Tracecat, record the equivalent encryption and secret settings from its configuration documentation. Back up OpenSearch or PostgreSQL data, object storage and the secret together in a way that lets you restore them as a set. Done when a restore test on a separate host recovers a working workflow with its saved credentials.
Plan for losing contact with the vendor
Decide in advance how the platform behaves when no vendor service is reachable, because a closed network will not have it. Shuffle's architecture is self-contained once images are local, and its hybrid option with Shuffle Cloud is not available in a closed network. Tracecat's air-gapped option removes runtime internet access. Confirm with each vendor that licensing, telemetry and app updates do not require a callback, and ask in writing which paid features are enforced locally. Shuffle's open-source edition includes all features, and its limits are enforced from v2.1.1, so confirm your edition in writing. Done when a written runbook covers license state, offline operation and the escalation path.
Stage app and version updates through a verified path
Bring app and platform updates across the boundary as signed or checksummed bundles on approved media, following your change process. Shuffle apps are versioned Docker containers built from OpenAPI specifications or the Python SDK, so each app image and its specification travel together. Tracecat custom actions can be synced from Git, so mirror the Git repository internally and verify commits before they reach production. Verify software integrity and authenticity for each package, which is the control behind NERC CIP-013-2 when that standard applies to you. Done when each update has a recorded hash check, an approver and an entry in your configuration history.
Test updates in a staging enclave
Build a staging enclave that mirrors production's images, configuration and secret handling, but holds no live alert sources. Apply each staged update there first, run your regression workflows, confirm that saved app credentials still authenticate, and check that Orborus picks up jobs and that outbound traffic remains blocked. Include a rollback test that restores the previous image set and backup. Promote to production only after the staging run passes and the results are recorded. Done when staging evidence exists for every update and the rollback has been exercised once.
How updates and vendor contact behave when the link is lost
How do app updates reach an air-gapped Shuffle installation?
Nothing reaches an air-gapped Shuffle installation automatically, so you pull each release and app image outside the network, verify it, then load it into your internal registry. Shuffle apps run as versioned Docker containers built from OpenAPI specifications or written with the Python app SDK, which makes each app image a discrete item to review. The Shuffle docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes, so in a closed network pin exact version tags and move them only after review in staging. Tracecat custom actions sync from Git, so an internal Git server plays the same role there. Confirm with Shuffle how each release and app is versioned, and whether any app calls external endpoints at runtime.
What happens to saved app credentials if the encryption secret changes?
Saved app credentials become unusable, so the encryption secret must be treated as a controlled value. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. The Shuffle configuration docs warn that losing or changing this secret breaks all saved app authentications. Store it in your own secrets manager, use the same value on every backend node, and keep a copy that matches each backup you take, because a restore without the matching secret leaves workflows in place but unable to authenticate. Any change requires re-entering each stored credential, so schedule rotations as change-controlled events. Confirm the rotation procedure with Shuffle before you plan one.
Do Shuffle workflows keep running if the vendor is unreachable?
Yes, provided the images and apps they need are already inside your network, because a self-hosted install does not call vendor servers to execute workflows. Orborus polls the backend for jobs, starts a worker for each workflow execution, and that worker starts the app containers. The Shuffle configuration docs recommend more than one Orborus node so workflows keep running if one fails. What stops is anything that needs a fresh download, such as a new app image, an updated release tag or an unmirrored dependency. Tracecat's air-gapped Kubernetes deployment is documented with no runtime internet access, and its workflows run on Temporal for durable execution. Confirm which features in each product need outbound contact, and test them in staging before cutover.
How do you handle a broken vendor image in a closed network?
Roll back to the last known good image already held in your own registry, which is why keeping mirrored history matters. Keep at least the previous version of every Shuffle and app image mirrored, deploy by exact version tag rather than a floating tag, and never let a stable tag update reach production without a staging run. The same pattern applies to cluster images: kubeadm can list and pull control plane images in advance, and the --image-repository flag points kubeadm init at your private registry. Record the checksum of each image from the verified transfer in your change log so you can show which artifact ran and when. If a broken release cannot be rolled back, confirm with Shuffle how to pin the prior release and whether its database changes block a downgrade.
How do you test restores of a self-hosted SOAR platform offline?
Restore into an isolated staging environment with no route to production alert sources, using the same encryption secret that was active when the backup was taken. Check that OpenSearch data loads, that workflows and cases are present, that at least one saved app authenticates, and that a test workflow runs through Orborus and its app containers from start to finish. Repeat the test on a schedule so you learn about gaps before an incident forces a restore. Confirm the backup method for OpenSearch and your storage layer against the Shuffle configuration docs, and confirm the same for Tracecat's PostgreSQL and object store. Record the results, including what failed, in your operational evidence.
How do you verify vendor software and patches before carrying them into a closed network?
Verify the integrity and authenticity of every release, app image and patch on the transfer workstation before it crosses the boundary. If your organization is subject to NERC CIP-013-2, its supply chain procurement processes must address verifying software integrity and authenticity for vendor software and patches, and this check is the control behind that requirement. In practice, confirm which checksums or signatures each vendor publishes, verify them against the downloaded files, record the hashes in your change log, and rescan images after they are loaded into the internal registry. Ask each vendor which verification method it provides and how it signs app images. Confirm the exact control mapping with your compliance lead and auditor.
Can DeployOpen run the offline update and restore process for us?
DeployOpen can plan, implement, back up, upgrade, document and support self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. For this scenario that can cover the image mirroring path, the review and staging steps, restore testing and the runbook for a broken release. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing upgrades and continuous support are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports or attestations.
Evidence an assessor will ask for under an offline SOAR
An offline SOAR deployment is only as credible as the records behind it. The six items below are the artifacts an assessor typically asks to see, and they connect because each one proves that what runs inside the boundary is what was approved, transferred and tested. DeployOpen prepares this evidence, but independent auditors and certification bodies draw the conclusions.
Signed artifact inventory and hashes
List every container image, Shuffle app image, rule set and installer that crosses into the enclave, with its version, source, checksum and signature status. For Shuffle, record the exact Docker tag in use, since the docs recommend the latest tag for stable releases and nightly for experimental changes. Ask who verified each hash before import, and keep the verification output with the inventory so an assessor can reproduce the check.
Transfer log for each media import
Every removable media or one-way transfer into the isolated network needs a log entry: who requested it, what was carried, the media identifier, the scan result, the approver and the import time. This is the record that ties the artifact inventory to the actual boundary crossing. Without it, the inventory describes what should have entered rather than what did.
Internal registry manifest
Document the private registry or mirror that serves container images inside the network, including repository names, image digests and the pull paths that Kubernetes or Docker Compose files reference. For Kubernetes-based deployments, the kubeadm image repository setting should point at this registry. Confirm that no workload resolves images from a public registry, and keep a dated manifest for each sync.
Configuration and encryption key custody
Record where the Shuffle encryption secret and the database and backup keys are stored, who holds them, and how they are rotated. Losing or changing the SHUFFLE_ENCRYPTION_MODIFIER secret breaks every saved app authentication, so an assessor will expect a documented escrow and a restore procedure. Keep custody records separate from the configuration files they protect.
Test restore results
Restore the OpenSearch data and workflow configuration into a separate offline environment at a set interval, and record the date, the backup set used, the steps taken and the outcome. Check that saved workflows execute after restore and that app credentials decrypt correctly. A backup that has never been restored is not evidence of recovery, so keep the failed attempts as well as the passing ones.
Vendor remote session access records
Any vendor engineer who connects for support, such as for a patch or an incident, needs a session record. Capture the approved access request, the method, the time window, the systems touched and the disconnection evidence. NERC CIP-005-7 is an example of a standard that expects active vendor remote access to be detectable and disable-able, so an offline SOAR should not depend on an always-on vendor channel.
What an offline deployment costs and who pays for each part
The largest difference between an offline Shuffle or Tracecat deployment and a FortiSOAR one is who pays for each component, so start by separating the software from the operation. Shuffle's backend is AGPLv3 and its apps and workflows are MIT, and all features are available in the open-source edition, with paid tiers differing in feature limits, scaling and support. Tracecat's core is AGPL-3.0, while code in its enterprise package and enterprise feature gates falls under a separate paid license. Ask the vendor in writing which features you would need in an isolated network and whether any of them sit behind a paid tier, including SSO, multi-tenant workspaces and air-gapped support. Those answers, not the license headline, set your subscription line.
Infrastructure is the second line and it recurs. Shuffle runs on OpenSearch (Elasticsearch also works) and Tracecat on PostgreSQL, an S3-compatible object store and Temporal, so you carry storage, backups and compute for each plus the high-availability layout you choose. Shuffle's install guide sets a minimum of 4 GB of RAM for a single node, and its high-availability guidance adds an OpenSearch cluster and more than one Orborus node. Your own sizing, not a vendor figure, should drive hardware, so request a written architecture from your implementation partner. The mirroring and transfer process is a cost too: every container image, app and Helm chart crossing the boundary needs a staging host, a verification step for integrity and authenticity under your supply chain control, and a person who signs off each import.
Staff time is usually the largest recurring cost and the least visible. Someone must patch the platform, rebuild Shuffle apps from OpenAPI specifications or update custom Python actions, retest playbooks against each release, and rotate the SHUFFLE_ENCRYPTION_MODIFIER secret handling without losing saved credentials. Each update cycle repeats the mirror, scan and test steps, so budget for it per release, not once. FortiSOAR sizing and licensing are covered on the cost comparison page. For your quote, ask for a fixed scope that lists installation, mirroring procedure, the first year of update cycles, staff training and any retainer for ongoing support, with each item priced separately and a named owner on both sides.
Questions buyers ask before choosing an offline SOAR
How much does an offline SOAR cost compared with FortiSOAR?
Shuffle's open-source edition has no license fee, but the total cost comes from the parts you run yourself: servers, storage, database administration, staff time and migration work. Shuffle states that all features are available in the open-source edition, and its paid tiers differ in feature limits, scaling and support. Its paid licensing is metered on app runs, meaning actions that execute in a workflow, while users, apps and workflows are unlimited. Tracecat's core is AGPL-3.0, but multi-tenant workspaces, SSO and Git version control sit in a separate Enterprise license. Recurring costs include hosts, backups, patching and the people who maintain integrations. Ask each vendor for a quote built from your written scope, with every component priced on its own line.
How long does an air-gapped SOAR deployment take to set up?
No supplied figure gives a standard duration, so the answer depends on scope: the number of hosts, integrations, and the approvals needed to move images and packages across your boundary. Shuffle's install guide sets a minimum of 4 GB of RAM and warns that its default Docker Compose setup is not scalable without changes, so a production build is a separate step. For Kubernetes, the kubeadm documentation shows how to list and pull control plane images in advance and point kubeadm init at a private registry, which lets you prepare the cluster before it is isolated. Ask each vendor for a written sequence of steps, and mark which steps depend on your change board or media transfer process. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
What skills does our team need to run Shuffle or Tracecat offline?
Plan for Linux and container administration, Docker or Kubernetes operations, and database skills for the platform you choose. Shuffle uses an OpenSearch document database with a Go backend, and its Orborus component starts workers and app containers. Tracecat uses FastAPI, Next.js, Temporal, PostgreSQL and an S3-compatible object store. Someone must also build and maintain integrations: Shuffle's App Creator builds apps from OpenAPI specifications, and apps can be written in Python with the app SDK. Tracecat can sync custom actions from Git. Key handling matters too. Shuffle encrypts saved app credentials with a secret named SHUFFLE_ENCRYPTION_MODIFIER, and losing or changing that value breaks every saved app authentication. Store it in your secrets process before the first workflow runs.
Can our own team run an air-gapped SOAR without an outside partner?
Your team can run it alone if it already has the skills listed above and time to build runbooks. Shuffle and Tracecat are both self-hostable and documented, and both publish air-gapped or offline-capable paths. The harder work is operational: mirroring images, controlling update packages, backing up OpenSearch or PostgreSQL, and designing high availability. Shuffle's configuration docs recommend an OpenSearch cluster, NFS for shared files when running several backends, and more than one Orborus node so workflows keep running if one fails. If you want outside help, DeployOpen plans, implements, customizes, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. Ongoing support is available as a retainer, and most work is fixed-scope.
How do we update apps and images without internet access?
Use a controlled pipeline: pull images and packages on a connected staging system, mirror them into an internal registry, transfer them through your approved media process, and verify integrity before deployment. Check software integrity and authenticity at every step. For utilities, NERC CIP-013-2 asks procurement processes to address verification of vendor software and patches, so confirm whether that standard applies to your environment. Pin versions in the offline environment rather than following floating tags. Shuffle's docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes, so the nightly tag does not belong on a production air-gapped host. Shuffle apps run as versioned Docker containers, which makes version pinning practical. For Tracecat, its air-gapped Kubernetes deployment has no runtime internet access, so ask the vendor how new connector versions and custom actions should be staged.
What happens to our SOAR when it loses contact with the vendor?
A self-hosted deployment should keep running its workflows on your servers, but the supplied facts do not describe every license check or telemetry path, so confirm offline behavior in writing before purchase. Shuffle has actively enforced the limits between its open-source and enterprise editions since v2.1.1, so ask how license state is evaluated when there is no outbound connection. Shuffle's hybrid model, where a local Orborus needs no inbound firewall ports, connects to Shuffle Cloud and does not apply to a closed network. Test the failure case in a lab: block outbound traffic, run workflows, restart services and confirm that credentials, workflows and case data remain available. Document the result as part of your readiness evidence.
Do Shuffle and Tracecat meet our SSO and access control requirements?
Shuffle meets common SSO needs in its open-source edition: it added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, both available on-premises, with per-tenant SSO enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so an on-premises build should plan around OpenID Connect. Tracecat documents authentication and single sign-on as enterprise features, so include that edition in your cost comparison if SSO is mandatory. For regulated environments, NERC CIP-005-7 requires interactive remote access to pass through an intermediate system with encryption and multi-factor authentication where it applies, and DeployOpen prepares systems, controls and evidence for compliance assessments. Independent auditors and certification bodies issue the reports and certifications.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For a FortiSOAR replacement in a closed environment, we start with the offline boundary, the license and update model, and the people who will run the platform after handover.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which playbooks, connectors and alert sources move into the offline platform.
- We map every container image, app package and update path that must cross the isolated boundary.
- We confirm which deployment architecture fits your environment, such as single-host Docker Compose or Kubernetes.
How we build
- We stand up the platform inside your cloud accounts, data centers or air-gapped network.
- Container images and dependencies are mirrored through a controlled transfer process into a private registry.
- We configure encryption secrets, single sign-on and high availability according to the agreed design.
- Playbooks or workflows are rebuilt and tested against the connectors your analysts actually use.
How we hand over
- Deliverables include architecture diagrams, runbooks, backup and restore procedures and offline update steps.
- We document how each software package is verified for integrity and authenticity before it enters the network.
- Operators are trained on workflow maintenance, the update process and what to do when vendor contact is lost.
- Compliance evidence is prepared for your assessors, though independent auditors and certification bodies issue any opinion.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Security testing of the deployed platform, its integrations and its AI features can be scoped separately.
- Upgrade packages are staged, tested in a non-production environment and then carried across the boundary.
- Ask us to confirm the retainer scope, response expectations and upgrade cadence in writing before signing.
