Alpha · open source · MIT

Casals

Run the same app for many owners on the Internet Computer. Casals creates each owner's canisters, rolls out your upgrades and keeps them funded, while each owner decides when to upgrade.

Fully on-chain The conductor is a canister. No off-chain worker sits in the deploy path.
Owner-approved upgrades You propose; each owner's baton approves. A failed upgrade rolls back all of that owner's canisters.
Cycles treasury Every canister is topped up by policy, and every top-up lands in the audit log.

> pip install ic-casals
> casals up tests/e2e/orchestras/minimal/casals.json --yes --local

Open the demo Read the docs

Casals

General-purpose canister lifecycle orchestrator for the Internet Computer — built for managed multi-tenant IC deployments with shared upgrade governance

What Casals is built for

Many instances of the same application, for many owners — and one team that has to keep every one of them upgraded, funded and safe.

Multi-tenant SaaS

One backend and frontend per customer. The customer owns the instance; the vendor ships the updates.

White-label apps

The same code under many brands. Each brand decides when it takes the next version.

Per-DAO deployments

Treasury, voting, forum — a set of canisters per DAO, operated by a shared team, governed by that DAO.

Agencies and studios

One team maintaining canisters for many clients under a single multisig, with scoped access per client.

Architecture design rationale

Why Casals — in eight steps

SNS

Token · swap · public DAO

Multisig

N of M signers · IC controller of every canister

↓

Multisig signs every install · upgrade · top-up… for every canister of every user… and for the shared infrastructurecontrols Casals only · highest authorityhighest authority · backstopfunds the treasury · signs nothing else

↓

casals-backend

conductor · IC controller of the orchestra

cycles treasury

casals-frontend

the team's console

casals-wasms

WASM registry · sha256

commanders

scoped permissions

↓controls

more users →

Orchestra

Infra

your application

backend frontend index assets

shared · one for all users

registry installer ledger

Users

user1 · user decides

baton backend frontend ···

user2 · user decides

baton backend frontend ···

…

···

more canisters →

01Step 1 of 8

An application is several canisters

On the Internet Computer an application is not one canister: a backend, a frontend, often more.
Each canister has IC controllers. Only they can install code, upgrade, top up cycles, stop or delete it.

Therefore Someone has to hold the controller keys.

02Step 2 of 8

Someone must control them — a multisig

The usual answer is an SNS: token, swap, public DAO. Not every project wants that for its infrastructure.
The alternative is a multisig: it becomes the IC controller of every canister.
Every install, upgrade and top-up is a proposal that N of M people sign.
Safe, simple, sufficient — for a handful of canisters.

Therefore A committee holds the keys. It works until the fleet grows.

03Step 3 of 8

The application grows

Features add canisters: index, assets, workers.
One instance is now a list of canisters that must be upgraded together.
The committee still signs each change, one canister at a time.

Therefore Growth along one axis: more canisters per instance.

04Step 4 of 8

Every user needs their own set

Multi-tenant: each user gets its own instance — backend, frontend and the rest.
A list of lists — users × canisters. A second axis of growth.
The committee now signs for every canister of every user.

Therefore Instances multiply. But not every canister belongs to one user.

05Step 5 of 8

Some canisters serve everyone

A registry of users, an installer, a shared ledger: infrastructure, not a user's instance.
They exist once, and change on a different rhythm than user instances.
The committee now signs for all of it. A multisig is people: it cannot top up cycles at 3 am, or roll out two hundred upgrades one signature at a time.

Therefore Two kinds of canisters, two axes of growth — and a multisig that is impractical for day-to-day operations.

06Step 6 of 8

Name the grid, hand it to a conductor

Section — a group with a shared role: Infra, Users. Stand — one instance inside it: the shared infrastructure, user1, user2. The whole grid is the orchestra.
Day-to-day operations need an operator that is a canister, not a committee: casals-backend, the conductor, becomes the IC controller of every orchestra canister.
casals-frontend is the team's console: orchestra tree, upgrades, cycles, WASM catalog. The multisig controls only these two — highest authority, rarely needed.
Commanders: team members with scoped permissions per section or stand.

Therefore The team can operate. The user has to trust the team.

07Step 7 of 8

The baton: the user decides

The team can now upgrade a user's canisters. The user needs both protection from that power and autonomy over their own instance.
A baton per stand. The team proposes and advises — recommends a version, prepares the rollout — but the user decides: approve, or not.
Once approved, the baton runs the upgrade across all of that user's canisters as one unit — snapshot, stop, install, verify, roll back.

Therefore Team advises and operates · user decides · multisig remains the backstop.

08Step 8 of 8

Two more pieces: a WASM registry and a treasury

casals-wasms — a certified file registry: chunked upload, sha256 computed on-chain, pinned per release. Every install streams the WASM from it; only authorized WASMs, and the conductor verifies module_hash afterwards. user1 and user2 provably run the same build.
Cycles — the conductor holds a native treasury that the multisig funds. A cycle policy per section, stand or canister; an on-chain autopilot (or an off-chain monitor paying from the same treasury) refills before anything runs dry. Every top-up is an audited event.

Therefore Code and cycles both flow from Casals — on-chain, verifiable, audited.

The result: four layers of authority

Who can change what — and who must agree. Numbers refer to the step that introduced each layer.

Multisig

Highest authority · IC controller of Casals and of every baton · rarely used

↓

casals-backend · casals-frontend

Conductor and console · day-to-day create / upgrade / cycles · commanders with scoped permissions

↓

Baton — one per stand

Team proposes and advises · user decides · upgrades the whole stand as one unit

↓

Stand canisters

backend · frontend · … — per user, plus the shared infrastructure

Casals never embeds voting. It executes approved actions.

Vocabulary

Canister — one deployed canister. Only its IC controllers can install code, upgrade, top up, stop or delete it (step 1)
Multisig — N-of-M committee. Highest authority; IC controller of Casals and of every baton (step 2)
Stand — one instance: the shared infrastructure, user1, user2, … (step 6)
Section — a group of stands with a shared role: Infra, Users, … (step 6)
Orchestra — the whole grid of sections and stands one Casals conducts (step 6)
Conductor — casals-backend. IC controller of the orchestra; runs day-to-day lifecycle on-chain. casals-frontend is its console (step 6)
Commander — a team principal with scoped permissions on a section or stand (step 6)
Baton — per-stand governor. The team proposes and advises, the user decides; upgrades the stand as one unit (step 7)
WASM registry — casals-wasms. Certified file store every install streams from; sha256 on-chain, authorized list, module_hash verified (step 8)
Treasury — cycles held by the conductor, funded by the multisig, spent by policy per section, stand or canister (step 8)

The sheet is a genesis document, not a control loop

Day one only — casals up reads the sheet once, builds the orchestra, hands the conductor to the multisig. After that the document is history, not instruction.
Reconcilers assume complete authority, reachable convergence, and that every difference is drift. Terraform and Kubernetes get all three; a governed orchestra gets none.
Authority is on-chain and shared — a file has none. A signer added by proposal, a redeemed access code, a baton that ran an upgrade: all legitimate, none of it in your document.
Convergence needs other people — an N-of-M approval may never come. A loop that reads waiting as failure nags forever; it should file a proposal and stop.
The orchestra is an actor too — stands minted at runtime, a tenant growing a canister. Not drift, the system working — true with a single controller too.
Therefore — the chain is the truth, casals export regenerates the sheet, a diff is a report (plan, oracle), never an enforcer. Never assert the file over the chain.

Running today: gos.earth

Many governance operating systems on one shared machine — conducted by Casals.

GOS — Governance Operating System

The operating system of a society, rewritten as software: who belongs, who decides, what the treasury may spend, which rules execute without asking anyone. One realm is one such system, on its own canisters.

GOS-as-a-Service — gos.earth

The control plane that hosts many of them side by side. A community deploys a GOS; gos.earth registers it as a realm, provisions the canisters, keeps them funded and current. The community remains sovereign over its own system.

How it uses Casals

The registry accepts a deploy; the installer asks the Casals conductor.
The conductor creates the realm as a new stand in Deployments, streams the GOS build from casals-wasms and funds it from the treasury.
A new GOS release rolls out realm by realm; each realm's baton (Casals and the realm itself) must agree before the upgrade lands.

Multisig

↓

casals-backend

conductor · treasury

casals-wasms

GOS builds

↓controls

gos.earth orchestra

Infra

installer

realm-installer

realm-registry

backendfrontend

Deployments

realm alice

batonbackendfrontendtoken

realm bob

batonbackendfrontendtoken

…

···