Canner, a Canadian deployment platform out of Québec, published a category-by-category inventory of Canadian cloud infrastructure in May 2026. The finding: roughly 92% of the developer-operations tooling a Canadian team relies on sits under foreign jurisdiction. Upper Harbour's Canadian Technology Sovereignty Index reaches the same place from the other direction — of 768 mapped tools, 80% of those advertising Canadian data residency remain CLOUD-Act-exposed because their parent company is US-controlled.

The inventory is worth reading in full. The summary is this: in most categories, Canadian sovereign options don't exist at scale, or don't exist at all.

The Map

Compute (IaaS): Options exist. OVHcloud (French-owned, Québec data centre), KeepSec (Canadian, open-source-based), ThinkOn (Canadian, sovereign focus), TELUS sovereign cloud, Bell-SAP partnership. The ThinkOn-Hypertec-Aptum-eStruxture consortium launched what they called Canada's first end-to-end sovereign government cloud in October 2025. This is the strongest category. Basic VMs, storage, networking — viable. Managed services, serverless, managed Kubernetes, ML infrastructure — not available from Canadian providers.

PaaS: Canner itself. Before Canner, nothing. No Canadian equivalent to Vercel, Netlify, Railway, or Render.

CDN: Nothing. No Canadian-owned CDN with distributed edge purge at scale. Bunny CDN (Slovenian) has Canadian PoPs. Cloudflare, Fastly, Akamai — US-incorporated, CLOUD-Act-exposed. The category is empty.

Database as a Service: Nothing. No Canadian equivalent to RDS, PlanetScale, Supabase, or Neon. Canner offers managed Postgres as part of its platform. Standalone DBaaS with read replicas, auto-scaling, branching — doesn't exist under Canadian jurisdiction.

DNS: Nothing. No Canadian authoritative DNS provider comparable to Cloudflare DNS, Route 53, or NS1. DNS is the first point of contact for every web request, and for most Canadian companies, that first contact is American.

Transactional Email: Nothing. No Canadian equivalent to SendGrid, Resend, Postmark, or Amazon SES.

Monitoring and Observability: Nothing. No Canadian equivalent to Datadog, New Relic, Grafana Cloud, or Sentry. Application logs, user behaviour data, system telemetry — all flowing to American-owned services.

CI/CD: Nothing. No Canadian equivalent to GitHub Actions, GitLab CI, CircleCI, or Buildkite. Every automated build and deployment pipeline runs on foreign-owned infrastructure, processing source code and deployment artifacts.

The Conventional Response

Canner's analysis is honest about why the gaps exist: infrastructure is capital-intensive and slow to monetize, and Canadian venture capital has historically preferred SaaS companies with higher margins and faster growth. The recommendation is to wait — for government procurement preferences to create demand pull, for Canadian VCs to recognize that the infrastructure layer is where long-term value accrues, for Canadian companies to build managed services on open-source foundations.

This is the correct analysis if you believe the solution is Canadian commercial cloud. It's also a recipe for waiting five to ten years for categories that may never be filled. Canadian VCs didn't avoid infrastructure by accident. They avoided it because the economics are bad for small markets. A Canadian CDN competing with Cloudflare's global edge network requires capital expenditure that doesn't pencil out for a country of 40 million people. A Canadian DBaaS competing with AWS RDS requires engineering depth and operational scale that few Canadian companies can sustain.

The gaps aren't market failures waiting to be corrected by better incentives. They're structural features of a small market trying to replicate the infrastructure layer of a global one. The question isn't how to fill them with Canadian companies. The question is whether filling them with companies is the right approach at all.

The Practical Response

The categories Canner identifies as missing — CDN, DBaaS, DNS, transactional email, monitoring, CI/CD — are all things you can run yourself. Not in theory. In practice, today, on hardware you own or lease, with FOSS tools that are production-grade.

DNS: PowerDNS, Knot DNS, BIND. Run authoritative DNS on a Proxmox node with a secondary on a different provider. You get anycast by putting nodes in different networks. It's not Cloudflare's global edge, but for a community organization serving a local audience, it doesn't need to be. DNS is lightweight. A 2-core VM handles millions of queries per day.

Database: PostgreSQL. Run it on your own hardware. pgBackRest for backups, pgBouncer for connection pooling, Patroni for HA if you need it. This is what AWS RDS runs under the hood. The managed part is convenience, not capability. A community organization running Postgres on a Proxmox VM with nightly backups and WAL archiving has the same database engine that powers major financial institutions. The difference is you can see it, audit it, and control it.

CDN: For most community deployments, a CDN is solving a problem you don't have. A reverse proxy (Nginx, Caddy, Traefik) on a VM with reasonable bandwidth serves static content faster than most communities need. If you genuinely need edge caching, varnish in front of your origin handles 95% of use cases. The "global edge network" matters if you're serving content to users across six continents. A fire hall serving its community doesn't need 300 PoPs. It needs one server that works.

Transactional Email: Postfix with DKIM, SPF, and DMARC. The hard part isn't the software — it's IP reputation. Getting deliverability right takes operational attention, but it's a solved problem. Postal is a FOSS mail delivery platform designed for transactional email. For community-scale volume (hundreds to low thousands of messages per day), this is straightforward. If you're sending millions, you need a specialist. Most communities aren't sending millions.

Monitoring: Prometheus and Grafana. The stack that Datadog and New Relic built their products on top of. Run it yourself. The data stays on your hardware. For alerting, AlertManager handles routing. For logs, Loki or VictoriaLogs. None of this requires a vendor. The operational knowledge to set it up is well-documented and widely shared.

CI/CD: Gitea Actions, Forgejo Actions, Woodpecker CI, or just Drone. Self-hosted runners on your own hardware. Source code and build artifacts never leave infrastructure you control. Gitea and Forgejo are actively developed, have CI pipelines that are compatible with GitHub Actions syntax, and run on a single binary. For a community organization, this is a 30-minute setup.

What Self-Hosting Actually Requires

This is the part that doesn't get said enough. Self-hosting is not free. It trades vendor cost for operational cost. You need someone who can patch, monitor, back up, and respond when things break. The Synapse security release on July 28 — 11 vulnerabilities, 6 rated high severity, affecting the homeserver software running 78.3% of federated Matrix servers — is a concrete example. If you run Synapse, you need to update. If you don't, you're running vulnerable software on the open federation.

But here's the thing: when Synapse has 11 CVEs, you can read the advisories, assess the risk to your specific deployment, patch on your schedule, and verify the patch. When a hyperscaler has a vulnerability, you find out when they deign to notify you, you patch on their schedule, and you take their word that it's fixed. The CLOUD Act exposure of "Canadian data residency" offerings from US-owned providers is itself a vulnerability — one you can't patch, can't audit, and can't see.

The operational burden of self-hosting is real. It's also the point. Operational capacity is what sovereignty actually requires. Not a Canadian vendor. Not a procurement preference. The ability to run your own infrastructure, understand what it's doing, and maintain it over time. That's what we help communities build.

The Pattern That Works

The communities that successfully run their own infrastructure share a pattern:

  1. One or two people with operational interest. Not necessarily sysadmins. People who are willing to learn and maintain. A retired IT worker at a fire hall. A city clerk who runs the town's website. A community organizer who likes Linux.

  2. FOSS stack on commodity hardware. Proxmox on a used Dell server. Nextcloud in an LXC container. Matrix in another. Postgres in a third. No licensing fees, no vendor lock-in, no per-user pricing. The hardware cost is one-time. The software cost is zero. The cost is labor.

  3. Backups that are tested. Not backups that exist. Backups that have been restored from, on a schedule, by the person who would do it at 2 AM when the disk fails. This is the single most important operational practice and the one most commonly skipped.

  4. Documentation that a successor can follow. The bus factor problem. If one person runs the server and leaves, the server dies. Documentation — what runs where, how to restart things, where the backups are, what the passwords are (in a password manager, not a text file) — is what makes infrastructure survive its original operator.

  5. Federation where it matters. Matrix federated with other community servers. Nextcloud with federated sharing. Not isolation — network membership on terms the community controls.

This pattern doesn't require Canadian VCs to invest in infrastructure. It doesn't require government procurement reform. It doesn't require waiting five years for a Canadian CDN that may never come. It requires a server, FOSS software, and someone willing to run it.

The Gaps Are the Point

Canner's inventory is valuable because it makes the gaps visible. The conventional reading is: these gaps need to be filled by Canadian companies. The practical reading is: these gaps demonstrate that the commercial cloud model doesn't serve small markets, and waiting for it to is a strategy with no timeline.

The FOSS infrastructure stack — Proxmox, Nextcloud, Matrix, Keycloak, Postgres, PowerDNS, Prometheus, Gitea — fills every category in Canner's inventory. Not with a Canadian vendor. With software you run yourself, on hardware you control, under laws you can see.

The gaps aren't a problem to solve with nationalism. They're a problem to solve with ownership. The tools exist. The question is whether communities will use them.