> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blockops.network/llms.txt
> Use this file to discover all available pages before exploring further.
# Deployment models
> Managed, hybrid and self-hosted deployments, and who holds the key shares in each.
The signing cluster is the custody boundary. Where its nodes run, and therefore who holds the key shares, is the choice that defines your deployment model. The API, the operation ledger and chain operations are the same in every model.
| | **Managed** | **Hybrid** | **Self-hosted** |
| :------------------------------ | :----------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------- |
| **Who operates the MPC nodes** | Blockops operates all nodes. | Blockops operates the API and part of the cluster; your institution operates one or more nodes in its own infrastructure. | Your institution operates all nodes in infrastructure it controls. |
| **Who holds the key shares** | Blockops. | Split. Neither Blockops nor the institution holds enough shares to reach the signing threshold alone. | Your institution. |
| **Who can produce a signature** | The Blockops-operated cluster, only through the platform's policy and approval flow. | Only Blockops and the institution together. | Only the institution's cluster. |
| **What you run** | Nothing. | One or more signing nodes, and the infrastructure under them. | The signing cluster and its supporting services. |
| **What Blockops runs** | Everything. | The API, ledger, chain operations, and its share of the cluster. | The API, ledger and chain operations; deployment tooling, monitoring, upgrade and recovery workflows for your nodes. |
| **Fits** | Teams that want the platform without operating signing infrastructure. | Institutions that want a cryptographic veto over every transaction while Blockops carries most of the operations. | Institutions with custody, regulatory or infrastructure-control requirements that put key material inside their own perimeter. |
## Managed
Blockops operates a three-node signing cluster with a **two-of-three** threshold on independent infrastructure, so that no single machine, account or administrative domain holds enough to sign. Blockops also runs the observability, backup and recovery workflows for the cluster. You integrate with the API and the console; the cluster is not exposed to you directly.
The three substrates are chosen to be different rather than identical, each with its own provider boundary, identity system, secret store and operations path. The aim is to remove correlated failure, so that compromising one provider, one identity system or one operations team never reaches the signing threshold.
## Hybrid
Your institution runs one or more nodes of the cluster in infrastructure it owns (its own cloud account, Kubernetes cluster or data centre) and Blockops runs the rest. With a two-of-three threshold and one institution-held share, no transaction can be signed without your node taking part. Blockops provides the node runtime, the deployment automation, and the monitoring, upgrade and recovery workflows; your institution controls the substrate, the network policy, the secret store and access to the machine.
## Self-hosted
All signing nodes run in your infrastructure. Blockops provides the same runtime, automation and operational workflows, and continues to operate the control plane your applications integrate with, but never holds a key share. This is the model for institutions whose policy requires key material to stay inside their own perimeter.
In the hybrid and self-hosted models the institution can own: the cloud account or cluster, network policy and firewall rules, IAM and the secret store, storage and backup targets, the logging destination, upgrade approval, incident response, and the signing nodes themselves.
## Moving between models
Because signing keys are held as shares, the cluster can be **reshared** to a new set of nodes, or a new threshold, without changing the wallet's public key or any address. That is how a deployment moves from managed to hybrid, or adds an institution-operated node, without migrating funds. Resharing is a governed operation, recorded in the audit trail. See [Continuity and recovery](/security/continuity-and-recovery).
## Related
* [Who holds the keys](/security/who-holds-the-keys)
* [Threshold signing with citadel-core](/security/threshold-signing)
* [Platform architecture](/overview/platform-architecture)