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.

2

Multisig

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

↓

6

casals-backend · casals-frontend

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

↓

7

Baton — one per stand

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

↓

1

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)

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

…

···