Provider adapter framework
TypeScript · API design · SDKs
Define a stable contract for authentication, provisioning, billing data, health and lifecycle actions while allowing each provider API to stay different underneath.
The directory makes Canadian providers easier to find. The next step is a unified interface that connects to those providers through modular API adapters—so a company can change the provider behind a service without rebuilding how its team works.
We are defining the contributor pathway now. Repository, licence and governance decisions remain open.
Your Canadian stack
Services from independent providers, managed together.
Domains
Sites
Mailboxes
Storage
Quick actions
KanataCloud would not become the infrastructure provider. It would become the consistent operating layer: one place to see services, take common actions and understand cost and health while independent Canadian companies continue to run the underlying systems.
One workspace and one operating model.
Shared concepts, policy and orchestration.
Independent adapters for each provider API.
The architecture is a proposal. Contributor review will shape the security model, adapter contract and first production integrations.
A common interface lowers the cost of trying a Canadian provider. Teams gain choice without accepting a new dashboard and workflow for every service, while providers gain a shared route into organizations that need more than one part of their stack.
Registration, records, nameservers, renewals and transfers.
Deployments, virtual machines, health, scaling and usage.
S3-compatible storage, snapshots, retention and recovery.
Mailboxes, transactional delivery and team services.
Certificates, firewalls, CDN controls and incident state.
Canadian inference, model access and privacy-conscious data services.
This is early enough for contributors to influence the contracts and boundaries that will be expensive to change later. We need people who care about dependable systems, clear product behaviour and Canadian digital capacity.
TypeScript · API design · SDKs
Define a stable contract for authentication, provisioning, billing data, health and lifecycle actions while allowing each provider API to stay different underneath.
Security · IAM · applied cryptography
Design tenant isolation, OAuth and API-key flows, encrypted credential storage, audit trails and least-privilege access from the beginning.
React · product engineering · accessibility
Turn inconsistent provider concepts into a coherent workspace without hiding differences that matter to cost, reliability or data residency.
Distributed systems · queues · observability
Build normalized events, job handling, retries, health reporting, observability and recovery for actions that cross independent provider systems.
The public product already provides a typed, containerized base. The production orchestration layer should be chosen through threat modelling, provider discovery and contributor review rather than a speculative architecture diagram.
Infrastructure software needs a durable operating model. Several paths are worth testing, but any commercial relationship must be disclosed and must never buy directory placement or ranking.
Use wholesale or reseller APIs where they improve provisioning and support, with the commercial relationship made visible.
Charge for optional team controls, policy, audit history, consolidated reporting or managed migration while keeping discovery public.
Let providers fund adapter development without buying prominence, exclusivity or a favourable comparison.
Offer paid onboarding and integration help to organizations that need a guided move across several services.
Tell us what you build, which workstream you care about and what a credible contributor programme should look like. Until the public repository opens, this page is the project brief.