On your own infrastructure
The entire platform runs on hardware you own, in a datacentre you choose. Nothing about detection, storage or analysis depends on a connection to us.
SOC 2 Readiness
24/7 Security Monitoring
Canadian-Based SOC
GuardsArm Platform
Deployment & Data Residency
Your infrastructure. Your region. Your access model. No telemetry path out.
Most security platforms ask you to accept that your detection data lives somewhere you do not control. For regulated, sovereign and air-gapped operators that is not a trade-off to be negotiated — it is a disqualifier. GuardsArm is deployed inside your boundary, and nothing about it depends on reaching us.
- Self-hosted
- Private cloud
- Air-gap capable
- White-label
The constraint
For some buyers, residency is the whole evaluation
Security telemetry is the most sensitive data an organisation holds. It records who accessed what, which systems are exposed, where the controls are thin, and what happened during an incident. The standard delivery model asks you to send all of it to a third party and accept their assurances about handling.
A great many organisations cannot accept that, and not because of preference. Data-sovereignty law, classification rules and contractual obligations to their own customers make it a condition they must meet before capability is even discussed.
GuardsArm inverts the model. The platform is deployed inside your boundary and the analysis — including the AI — happens there. Residency stops being a clause you negotiate and becomes a property of where the software runs.
A promise that your data is handled correctly elsewhere is a different thing from your data never going elsewhere.
Deployment models
Where you can run it
In your private cloud
Deploy into your own cloud tenancy when you would rather not run metal. The boundary is still yours: your account, your region, your key management.
Fully air-gapped
Dependencies are self-hosted, so the platform operates with no internet egress at all — including the AI. For classified and operational-technology environments this is the only workable model.
Delivered under your brand
Service providers run one deployment across many customers, each isolated from the others, presented in a console carrying their own name rather than ours.
Residency
What the questions actually resolve to
Written against the hosted delivery model rather than any named vendor, because what differs is structural rather than contractual.
| The question | Hosted security platform | GuardsArm |
|---|---|---|
| Where does security telemetry physically rest? | In the vendor's region, under their account. | On the infrastructure you deployed to, under your account, in your region. |
| Who can technically access it? | Vendor staff, governed by their internal policy and your contract. | Whoever your access model permits. There is no vendor access path. |
| What happens when a regulator asks? | You produce the vendor’s attestations and sub-processor list. | You point at your own environment. There is no sub-processor to disclose. |
| Can it run with no internet egress? | No — the model depends on reaching the vendor. | Yes. Dependencies are self-hosted, including the AI. |
| What happens if the vendor relationship ends? | Export windows, then deletion on their schedule. | The data was never anywhere else. Nothing has to be retrieved. |
Where a hosted service meets your obligations it may well be the easier choice. This page exists for the organisations it does not.
Ownership
What you operate, and what we ship
You own
The infrastructure, the data and its retention, the access model, and the decision about what gets collected. Security data never leaves your boundary, so residency is a fact of the deployment rather than a contractual promise.
GuardsArm ships
The detection content, the behavioural analytics, the ATT&CK mapping, the endpoint agents, the response engine and the AI analyst — delivered as signed packages and container images you install.
Neither of us sends anywhere
There is no telemetry path out of your environment. That is the architectural property the rest of the platform is built around, and it is why air-gapped deployment is supported rather than merely tolerated.
The detail
Deployment facts
Including what is not generally available yet, stated plainly rather than left to be discovered during a proof of concept.
- Deployment
- Self-hosted on premises or in your private cloud, as container images plus signed package repositories.
- Topology
- Single-node deployments.
- High availability
- Multi-node clustering is on the roadmap. The clustering daemon exists but HA is not yet generally available.Roadmap
- Air-gap
- Air-gap friendly. Dependencies are self-hosted through an internal package mirror, so the stack runs without internet egress.
- Licensing
- Self-hosted licensing rather than per-gigabyte or per-event cloud metering.
- Data security
- Encryption and authentication throughout, with per-tenant data isolation and field-level controls.
- Retention & DR
- Native index lifecycle management with rollover and retention, plus snapshot-based backup and disaster recovery.
Bring your constraints
Regulated, sovereign, air-gapped, multi-tenant, or simply unwilling to export telemetry — those are the conversations this deployment model exists for.
24/7 SOC Monitoring Available