Develop with Canopy
Develop an application locally, connect it to other systems, and introduce process, network or supported enclave boundaries as requirements become clearer.
Canopy is a framework, generator, integration toolset and runtime used with your editor and CMake build. RPC provides the communication foundation; the surrounding components support the work of building, integrating and protecting the application.
CIDL is Canopy’s canonical interface definition language: a language-neutral way to describe types and interfaces without writing C++. Build integration generates C++ projections, proxy/stub code, supported serialisers and schema artifacts. Generated JavaScript clients connect supported browser and Node.js paths.
CMake incorporates generation into the application build. CIDL formatting tools and a VS Code syntax-highlighting extension support authoring. The extension currently provides basic editing, not a full language server.
REST/OpenAPI tooling, WebSocket/AsyncAPI integration, Proto3 and JSON Schema artifacts, and MCP adapters expose defined interfaces. Application bindings, metadata and access policy remain part of the integration.
A portal generator packages protocol documents and public schema artifacts into a browsable integration reference. Other teams can inspect the contract using familiar formats.
Typed calls, callbacks, distributed references and composable transports support stateful applications. Blocking and coroutine builds serve different execution requirements; telemetry makes runtime relationships inspectable.
SGX transports, enclave-compatible runtime components, attestation backends and protected sessions support a defined protected workload. Deployment policy determines which evidence is acceptable.
Crossing the boundary
Describe the application contract.
Develop and test locally.
Connect services and tools.
Place selected work in an enclave.
Check evidence against policy.
Decide which code and data belong inside the protected boundary. Compose access to networking, storage and other host services explicitly; validate what comes back.
Use generated interfaces and reusable transports for calls, callbacks, errors and ownership. Network latency, failure handling and enclave restrictions remain real design constraints.
Appraise hardware evidence against an approved workload policy and bind that decision to the protected session. Choose the verifier, reference values and freshness rules.
Provision keys, define configuration and upgrade policy, and test availability and recovery. A working enclave build is one stage in qualifying a deployment.
Integration in practice
Cerberus combines a typed application core with browser, REST, event and advisory interfaces. Its recorded EFDI integration publishes synthetic telemetry through a Zenoh bridge. That specific delivery path illustrates how Canopy can fit alongside existing infrastructure.
Published contracts give teams a starting point. Data meanings, authentication, topic registration and failure behaviour still need agreement and testing.
C++ is Canopy’s first implementation language. CIDL gives non-C++ users a canonical authoring language for that contract. The application-facing contract is designed to outlast any one language binding. Its language-independent types and interfaces provide the foundation for additional language implementations, with generated JavaScript clients already available for supported browser and Node.js paths. Additional runtimes are planned; the Rust workspace is currently being rewritten. The concrete hardware evidence presented here concerns Intel SGX; other TEE backends need their own implementation and qualification.
Start with one application interface and one boundary, then evaluate the generated output and runtime behaviour against your requirements.
Use the components to support zero-trust access decisions or confidential joint processing: contributors can appraise agreed code before sending private inputs, and the application releases only permitted results.
Explore the application designs →