Node
coda-node is the runtime for connecting your own QPU or simulator backend to Coda. Run it near your hardware to bring the device online for Coda users.
Use these guides when you operate quantum hardware and want Coda users to submit jobs to your QPU through the Coda API, SDK, or MCP server.
Demo: Teams
Teams let an organisation manage self-hosted QPUs as shared resources. Managers can create teams, and team owners can invite members, create team-owned bootstrap tokens, transfer QPUs into the team, and manage shared devices. Members can view team QPUs and create tokens for shared hardware.
Demo: Connect a self-hosted QPU
This demo shows how to connect a self-hosted QPU to Coda with coda-node.
What the Node does
The Coda cloud compiles user circuits into Coda’s native gate IR, then handles queueing jobs for your QPU. coda-node handles the cloud-facing work:
- Connects to Coda with a one-time node token or persisted JWT credentials.
- Starts a managed VPN tunnel when the node is configured for VPN mode.
- Sends heartbeats so the QPU appears online.
- Receives queued jobs from Coda.
- Calls your executor with
NativeGateIRand a requested shot count. - Signs and delivers execution results back to Coda by webhook.
Your integration owns the hardware-specific work: translating the native gate IR into device commands, running the experiment, and returning counts.
Documentation
- Integration Guide: implement an executor, configure a device YAML, and start a node.
- Protocol: understand provisioning, queued jobs, heartbeats, webhooks, and credential persistence.
- QubiC Example: see how
coda-qubicconnects a QubiC backend to Coda.
Runtime boundaries
coda-node owns authentication, connectivity, job consumption, result delivery, health checks, and graceful shutdown. Your backend package owns device configuration, circuit translation, hardware control, calibration handling, and result normalization.
This separation lets Coda use one node protocol while each hardware team keeps its own device-specific software.
