Trust

Security & data residency

Last updated: 5 July 2026

Canopyd is built for people who look after other people's servers, so we hold ourselves to the standard we'd expect from any tool inside our own network. This page describes where your data lives, how it moves, and what we do to protect it.

Where your data lives

All Canopyd services and data are hosted on Microsoft Azure in the UK South region (United Kingdom). That includes the web application, databases, telemetry snapshots and backups. We do not replicate or transfer customer data outside the United Kingdom.

  • Application hosting: Microsoft Azure, UK South.
  • Databases: Azure-hosted SQL Server, UK South. Each customer company has its own dedicated database.
  • Backups: stored within the same UK region with point-in-time restore.

Encryption

  • In transit: every connection — browser to console, agent to platform — uses HTTPS/TLS. Plaintext HTTP connections from agents are rejected outright.
  • At rest: databases and backups are encrypted at rest using Azure storage encryption.
  • Secrets: agent keys are never stored in plaintext on our side — we keep only a SHA-256 hash. On your servers, the key sits in the operating system's secret store (DPAPI on Windows, a root-only file on Linux, the System Keychain on macOS), never in a config file.

Agent security

The monitoring agent is deliberately boring, in the best way:

  • Outbound only. The agent makes outbound HTTPS calls to the platform. You never open an inbound firewall port for Canopyd.
  • One-time enrolment. A server joins with a single-use enrolment token that expires after 15 minutes. The token is exchanged for a unique per-server key.
  • Signed payloads. Every message the agent sends is HMAC-SHA256 signed with its key and timestamped. Requests outside a ±5 minute window, or whose signature doesn't verify, are rejected — which defeats both spoofing and replay.
  • Instant revocation. An administrator can revoke any server's key from the console in one click. Compromise of one server never affects another — every key is unique.

What the agent collects — and what it doesn't

The agent collects operational metrics only:

  • CPU, memory, disk and network utilisation, load average and uptime.
  • The list of installed services/daemons: their identifiers, display names and running state.
  • Basic OS information (edition, architecture, kernel version) and the server's hostname.

The agent does not read, index or transmit:

  • File contents, documents or databases on the monitored server.
  • Screenshots, keystrokes or user activity.
  • Application-level data, logs or credentials.

Tenant isolation

Canopyd is multi-tenant at the account layer and single-tenant at the data layer: each customer company's monitoring data is stored in its own database. Users authenticate against a central directory and are routed to their company's database at sign-in. There are no shared tables of customer telemetry and no cross-tenant queries.

Access control

  • Role-based access inside each company: Viewers see dashboards, Operators can act (start services, wake devices), Administrators manage users and enrolments.
  • Sessions expire after inactivity and sign-out is enforced server-side.
  • Platform-level administration (managing companies) is restricted to Canopyd staff accounts.

Resilience & backups

All platform state — including configuration, enrolments and telemetry — lives in the customer database, so a single database backup captures everything needed to restore service. Backups are taken automatically and retained within the UK.

Reporting a vulnerability

If you believe you've found a security issue in Canopyd, we want to hear about it before anyone else does. Email info@canopyd.com with enough detail to reproduce the issue. We'll acknowledge your report promptly, keep you informed while we fix it, and won't take action against good-faith research.

Questions about security, compliance or data residency that this page doesn't answer? Contact us at info@canopyd.com — happy to go deeper.