An on-premise deployment runs the full platform inside infrastructure you operate, whether that is a private datacenter, a dedicated VPC, or your own Kubernetes cluster, while retaining an outbound path for vulnerability-data updates. It is the middle ground between multi-tenant cloud and a fully sealed air-gapped install: you keep all code and findings inside your boundary, but you skip the manual offline-bundle transfer because the platform can pull signed updates directly. This FAQ explains the footprint, the upgrade path, who holds the keys, and how to decide between on-prem, dedicated VPC, and air-gapped.
Frequently Asked Questions
What is the difference between on-premise and air-gapped? On-premise keeps the platform inside your infrastructure but allows a controlled outbound connection for vulnerability-database updates, so refresh is automatic. Air-gapped removes that connection entirely and requires you to carry signed data bundles across the boundary by hand. Both keep your source, SBOMs, and findings inside your control; the difference is purely whether an update channel exists.
What infrastructure do I need to run it on-prem? The platform ships as containers and runs on Kubernetes or OpenShift, so a standard cluster with persistent storage and a Postgres-compatible database covers the baseline. Sizing scales with the number of projects and scan frequency rather than user count. You can run it on-metal, in a private cloud, or in a dedicated VPC in a public cloud you already control.
Who controls the encryption keys and the database? You do, in every on-prem deployment. The datastore lives in your infrastructure, and you can bring your own KMS or HSM so that key material never leaves your control. Safeguard operates the software but does not hold your keys, your ciphertext, or a copy of your data.
How do vulnerability updates reach an on-prem install? The platform pulls a signed vulnerability-database bundle over an outbound HTTPS connection to a single, well-known endpoint you can allowlist, and it verifies the signature before applying. Only advisory data flows inward; no code, SBOM, or finding flows outward. If your policy forbids any outbound connection at all, that is the signal to move to an air-gapped deployment instead.
Does the AI triage engine run locally on-prem? Yes. Griffin AI runs inside your cluster against locally hosted model weights, so reachability and exploitability analysis happen on your infrastructure with no inference calls leaving the boundary. Your code is never sent to an external model endpoint. This is the same local-inference design used in the air-gapped tier.
How do platform upgrades work on-prem? Upgrades are delivered as signed container images that you roll out through your normal Kubernetes deployment process, on your schedule and inside your change-management windows. There is no forced auto-update, which matters for teams under strict change control. Because releases are versioned and signed, rollback is a redeploy of the prior image.
Can I integrate on-prem with GitHub, GitLab, or my internal SCM? Yes. On-prem connects to internal or self-hosted source control such as GitHub Enterprise Server, self-managed GitLab, Bitbucket Data Center, and Azure DevOps, all over your internal network. The same software composition analysis and SBOM generation run in your own CI/CD. Nothing about the integration requires the public internet beyond the advisory-data pull.
What is the ecosystem and SBOM coverage compared with cloud? It is identical. On-prem generates the same CycloneDX and SPDX SBOMs, covers the same package ecosystems, and runs the same container and infrastructure-as-code scanners as the multi-tenant cloud. The engine is one codebase deployed in different topologies, so you do not lose capability by self-hosting.
How is licensing validated without sending usage data out? Licensing is validated against a signed entitlement file, so there is no usage-metering call that reports your activity back to us. The outbound connection exists only to fetch advisory data, and even that is optional if you switch to offline bundle imports. Your scan counts and project names stay inside your network.
Is on-prem suitable for regulated or government workloads? It is a common choice for exactly those, because keeping data on infrastructure you control simplifies many control mappings. The architecture is built toward FedRAMP HIGH and DoD Impact Level requirements, and SOC 2 Type II is in progress; to be honest about the distinction, "built toward" is not the same as "authorized," and formal authorization depends on your environment and accrediting body. The compliance page states exactly what is certified versus underway.
How much operational overhead does self-hosting add? You take on running a Kubernetes workload: monitoring, backups, storage, and applying upgrades. For teams that already operate clusters this is modest; for teams without platform engineering capacity, the managed cloud is usually the better fit. Be honest with yourself about your operational capacity before choosing self-hosted.
Can I start in the cloud and move on-prem later? Yes. Because the engine is the same across deployments, migrating means standing up the on-prem instance and re-pointing your integrations; your SBOM and finding history can be exported and imported. Many teams pilot in the cloud and move sensitive projects on-prem once the value is proven. The deployment comparison walks through the migration path.
What does on-prem cost compared with cloud? On-prem is a quoted tier because it includes deployment support and a private update pipeline rather than shared infrastructure, whereas the cloud has published self-serve tiers. The security capabilities are identical across both. See pricing for the current structure or request a scoped quote.
To scope a self-hosted deployment, review the software composition analysis and Griffin AI capabilities, confirm what is certified on the compliance page, and talk to our team about sizing. Full deployment documentation is at https://docs.safeguard.sh.