MIRCO DEPLOY

From blueprint.To running authority.

Deploy turns a Studio manifest into infrastructure, then refuses to call the network ready until placement, node health, quorum and restart safety match the selected operating model.

DEPLOYMENT RUNWAY · CONCEPTSTUDIO MANIFEST RECEIVED
RUNTIMENATIVE
CONSENSUSBFT
OPERATIONSBFT4
SOVEREIGNTYDEDICATED
PROTECTIONEXPLICIT
01
INGESTManifest
02
PREPAREPackages
03
PLACENodes
04
VERIFYQuorum
05
READYServe
BFT4 requires 3-of-4 quorum before ready.Restart safety mandatory
PLACEMENT WORKSPACE

Choose where it runs.
Keep the fault model honest.

Infrastructure target and topology are different decisions. Deploy can place the same network architecture on local, Docker, VPS or other qualified infrastructure without pretending the operational guarantees are identical.

DEPLOYMENT PLAN · CONCEPT
NODE PLACEMENT

BFT4 on Local

Four validator identities are represented independently. A real deployment must preserve authority boundaries and restart-safe identity handling.

OPERATIONAL TRUTH

Deploy is not “servers are up.”

A MIRCO deployment is ready only when infrastructure and authority agree with the selected operating model.

PLACEMENTNodes exist where planned

Infrastructure location is recorded without redefining sovereignty or consensus.

IDENTITYValidator authority is preserved

Restart or replacement must not manufacture a new authority identity.

QUORUMThe selected fault model is live

BFT readiness depends on reachable validator quorum, not merely process health.

RECOVERYRestart safety is proven

A network that cannot restart safely is not deployment-ready.

RESTART SAFETY

A network that only works once
is not ready.

MANDATORY GATE

Stop. Restart. Recover authority. Rejoin safely.

Deploy must treat restart safety as part of the operating contract. Node boot success is insufficient if identities, quorum or recovery state cannot be restored without ambiguity.

Stopcontrolled shutdown
Persiststate + identity
Restartsame authority
Rejoinquorum-safe
Readyevidence restored
READINESS GATES

Deploy may refuse to continue.

The safest deployment behavior is sometimes to stop, show the reason, and require the architecture or infrastructure to be corrected.

QUORUMEnough authority must be reachable.

BFT4 needs 3-of-4 quorum. SOLO remains a development/continuity profile and is not BFT.

PRIVACYRequested privacy must exist.

If a deployment requires a privacy capability that is unavailable in the active environment, Deploy must not silently weaken the request.

READINESS-GATED PROFILESPoW / custom profiles need evidence.

Studio may request them. Deploy should realize them only when the active implementation and readiness evidence support the selected profile.

DEPLOY TRUTH MODEL

Infrastructure state and network truth
are not the same thing.

01Process health

Is the node process alive?

02Validator reachability

Can required authority participate?

03Quorum

Can the selected consensus profile actually make progress?

04Restart safety

Can the network recover without authority ambiguity?

05Readiness

Why does MIRCO say this deployment is ready?

MIRCO DEPLOY

Make the blueprint real.
Call it ready only when it is.

From local and Docker to qualified VPS/BFT4 deployment — the deployment surface stays tied to the network’s real fault and authority model. Additional models appear only when their readiness is established.

Public launch pricing: Self-host Community is $0. Managed BFT4 starts at $1,299/month, BYOC AutoOps at $499/month + cloud, and XRPC paid plans at $49/month. See pricing →