Once you accept the argument that a Canadian region of a US-owned cloud isn't Canadian hosting — because the CLOUD Act binds the company, not the datacenter — the next question is practical: what does a fully sovereign Canadian stack actually look like, layer by layer? Which layers have a mature Canadian-owned option, and which are still thin?
This is that map. "Sovereign" here means the stricter bar: Canadian-owned and Canadian-controlled, not merely data resident in Canada. For the reasoning behind that distinction, see our sovereignty page; for the wider ecosystem inventory, the State of Canadian Cloud Infrastructure post.
The stack, layer by layer
Status is deliberately honest — Solid means a mature Canadian-owned option exists; Workablemeans it's usable with a caveat worth understanding; Thinmeans the Canadian ecosystem doesn't yet have a strong answer and you're making a trade-off.
| Layer | Sovereign Canadian option | Status |
|---|---|---|
| App / compute hosting | Canner — Montreal, Canadian-owned | Solid |
| Managed database | Canner managed Postgres (per project, Montreal) | Solid |
| Object storage | Canner object storage (S3-style, Montreal) | Solid |
| Product analytics | Canner cookieless analytics (no consent banner, Montreal) | Solid |
| Scheduled jobs / SQL | Canner scheduled jobs + scheduled SQL queries | Solid |
| DNS | Cloudflare — DNS + TLS issuance only, no proxying or traffic transit | Workable |
| TLS certificates | Let's Encrypt (ISRG, non-profit CA) | Workable |
| Payments | Helcim or Moneris (Canadian) vs. Stripe (US) | Workable |
| Transactional email | Self-hosted (Postfix) or a Canadian relay | Thin |
| CDN / edge cache | No Canadian CDN at scale — serve from the Montreal origin (Canner caches at origin) | Thin |
| LLM / AI inference | Open models on Canadian GPU compute vs. US model APIs | Thin |
What Canner covers in one place
The whole top block — compute, managed Postgres, object storage, cookieless analytics, scheduled jobs and scheduled SQL — runs on Canner, in Montreal, under Canadian ownership. That's the core of most web applications, sovereign by construction and with nothing to assemble: push a repo or a folder and it's live over HTTPS in about thirty seconds, with a Canadian-law DPA and residency attestationavailable for your compliance file. You are not stitching together a database service, a storage bucket, an analytics vendor, and a cron runner from four different companies and hoping each one's jurisdiction holds.
Where the ecosystem is still thin — and what to do
A reference architecture that pretended every layer had a great Canadian answer would be marketing, not engineering. Three layers still force a trade-off:
- Transactional email. Deliverability at scale is dominated by US providers. You can self-host outbound mail (Postfix on a Canadian host) to keep it sovereign, at the cost of running your own reputation, or accept a US relay for deliverability and keep only the message metadata flowing through it. Match the choice to how sensitive the mail content is.
- Payments. Stripe is the default, and it is US-owned. Canadian-owned processors exist — Helcim (Calgary) and Moneris — and are a genuine sovereign option; the trade-off is developer ergonomics and coverage. Card data is also PCI-scoped regardless, which narrows what actually needs to be sovereign here.
- CDN / edge and AI inference.There is no Canadian CDN at national scale, so the sovereign move is to serve from a Canadian origin and cache there rather than at a foreign edge — which is exactly how Canner's caching works. For AI, the US model APIs (OpenAI, Anthropic) have no Canadian-owned equivalent at the frontier; running open-weight models on Canadian GPU compute keeps inference sovereign when the workload allows it.
The point isn't that a perfect sovereign stack exists today — it's that the coreof one does, the thin layers are known and bounded, and each remaining trade-off can be made deliberately rather than by accident. If you're a Canadian team assembling this, start with the layers that are already solid and make the thin ones explicit decisions in your architecture doc.