Canic is a Rust toolkit and operator CLI for building and running Internet Computer canister fleets. Its capabilities are deliberately separable: use the runtime facade without Fleet installation, add authentication without scaling, or use the host-side backup tools without giving application canisters access to files, credentials, or operator authority.
Install the published operator CLI at the same version as the canic crate
used by your canisters:
cargo install --locked canic-cli --version <version>
canic --versionFor a checkout of this repository:
make installThen choose the path that matches what you are doing:
- Build a first managed canister: Minimal managed Fleet
- Install and operate Canic: Installing Canic
- Configure roles and topology: Canic configuration
- Work on Canic itself: Contributor rules and testing guide
Canic uses the installed icp binary for replica, canister, snapshot, and
restore operations. Supported versions and upgrade guidance are maintained in
INSTALLING.md.
rust-toolchain.toml pins internal Rust 1.97.1;
published crates declare MSRV 1.91.0 in Cargo.toml.
Each feature has a short guide of its own. The guides explain the capability and its authority boundary, then point to the detailed contracts and runbooks.
Lifecycle and build macros, stable-memory helpers, timers, typed calls, metrics, and configuration-derived runtime context for Rust canisters.
Endpoint guards, delegated subject tokens, root-managed chain-key proof renewal, issuer proofs, role attestation, and explicit caller/subject binding.
Coordinator-backed Fleet installation, one root and Wasm Store per occupied Subnet, qualified artifacts, registries, directories, and root-owned platform effects.
Reusable Component Specs and Groups, bounded placement, service roles, dynamic child trees, sharding pools, scaling pools, and reduction-only limits.
Role-aware Wasm builds, stable build provenance, evidence comparison, and passive policy gates.
The host backup domain and current canic backup / canic restore workflows
remain available. They resolve exact canisters from terminal current ensure
inventory rather than historical install or recovery evidence.
Optional runtime APIs for product blob storage, with the non-billing integration kept separate from Cashier-backed billing support.
App setup, network trust, local replicas, builds, evidence, diagnostics and the reviewed Fleet ensure workflow.
Explore operations and diagnostics
The complete feature index is in docs/features.
Prequel Wars is the external stateful demonstration and downstream proving ground for Canic. It maps game planets to application Subnets and exercises managed IcyDB Components, direct scoped ingress, retirement evidence, reusable estates and a bounded Galactic War Room Fleet overview.
The game stays in its own repository. Canic owns only generic infrastructure, lifecycle, authorization, retirement and observatory contracts; it does not vendor game code or make canonical infrastructure depend on the demo.
- An App is checked-in source and configuration.
- A Fleet is one installed instance of an App on one network.
- A workspace is the local checkout containing configuration and operator state; it is not a deployment identity.
- A Component Spec is a reusable blueprint. A concrete Component is one deployed occurrence with its own identity, root, state, and limits.
- A Fleet Subnet Root owns lifecycle effects for Components on its physical Subnet. The Fleet Coordinator owns Fleet-wide planning and publication.
See CONFIG.md for the App vocabulary and Fleet ensure for the separate operator-owned desired Fleet contract.
- crates/canic — public canister facade
- crates/canic-core — shared runtime, models, policy, and protocols
- crates/canic-control-plane — root, Coordinator, and Store runtime support
- crates/canic-cli — published
canicoperator binary - crates/canic-host — host-side build and Fleet reconciliation
- crates/canic-backup — backup and restore domain contracts
- apps — reference App configurations and canister packages
- docs — architecture, contracts, operations, designs, and audits
Detailed ownership and dependency rules live in AGENTS.md.
Canic is pre-1.0. Release transitions are reinstall-only unless an explicit design says otherwise; same-release retry, backup, and recovery remain durable operational contracts. Read the current implementation status for the exact completed boundary rather than relying on a version-specific summary in this landing page.
The repository is being opened for wider use; issues and pull requests are currently limited to the core team.
MIT. See LICENSE.