> ## 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. # Self-hosted signing > What you run when your institution operates its own citadel-core signing nodes, and what Blockops provides. In the **hybrid** and **self-hosted** [deployment models](/overview/deployment-models), your institution operates some or all of the signing nodes. Each node runs **citadel-core**, the MPC node software, and holds one share of every wallet key. This section is the operator's guide: what to provision, how to install, how to configure, and how to run the cluster day to day. ## What a signing cluster is A cluster is `n` citadel-core nodes with a signing threshold `t`, where `t ≥ ⌊n/2⌋ + 1`. Key generation, signing and resharing are protocols run between the nodes; a private key is never assembled in one place. The nodes talk to each other over a **NATS** message broker and find each other through **Consul**. Every message between nodes is signed with the sending node's Ed25519 identity and encrypted to the receiving node. Each node needs: | Component | Purpose | | :---------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Identity** | An Ed25519 key pair unique to the node. The public half is shared with every peer; the private half stays on the node, optionally encrypted at rest with `age`. | | **Share store** | An embedded BadgerDB database, encrypted with AES-256 under a password you set, holding the node's key shares. | | **Configuration** | A `config.yaml` with the cluster threshold, the initiator's public key, the shared chain code and the NATS and Consul connection details. | | **Peer registry** | A `peers.json` listing every node's name and ID, mirrored into Consul. | ## Who initiates operations Nodes do not act on their own. Key generation, signing and resharing requests arrive on NATS from the **event initiator** (in practice citadel-api, the wallet API) and every request is signed with the initiator's key. Nodes verify that signature against the `event_initiator_pubkey` in their configuration and drop anything that does not match. Optionally, a set of named **authorizers** can be required to co-sign each request. This is the boundary between the control plane and the signing plane: the API decides *whether* a transaction may be signed (policy, approvals, limits); the nodes decide only *that the request is authentic* before contributing their share. ## What Blockops provides * The citadel-core binaries and container image for self-hosted customers. * The `citadel-core-cli` tool for generating peers, identities and initiator keys, and for recovering a share store from backup. * Deployment guides for [systemd on Linux hosts](/self-hosted/install-systemd), [Kubernetes](/self-hosted/install-kubernetes) and [AWS ECS Fargate](/self-hosted/install-ecs). * Upgrade notes with each release, and support through [hello@blockops.network](mailto:hello@blockops.network). ## What your operators own * The hosts, cluster or cloud account the nodes run in, and the NATS and Consul services they depend on. * The identity passwords, the share-store password and the chain code: if these are lost, the node's shares cannot be recovered. * Backups of the share store and identity files, and their restore. * Network controls between nodes and to NATS and Consul, and the TLS material for NATS. The [security checklist](/self-hosted/security-checklist) lists these controls in a form you can hand to a reviewer. ## Start here Three nodes as hardened systemd services. A StatefulSet with secrets, network policy and probes. Fargate tasks with Secrets Manager, S3 and EFS. Every `config.yaml` key, environment override and command-line flag.