diff --git a/guides-and-tutorials/nodes-and-miners/run-a-node-with-docker.md b/guides-and-tutorials/nodes-and-miners/run-a-node-with-docker.md index 06e82ce2a4..98293a1e92 100644 --- a/guides-and-tutorials/nodes-and-miners/run-a-node-with-docker.md +++ b/guides-and-tutorials/nodes-and-miners/run-a-node-with-docker.md @@ -25,9 +25,9 @@ While you _can_ run a node using these specs, it's _recommended_ to assign more * **1TB disk space for Bitcoin node** {% hint style="warning" %} -MacOS with an ARM processor is NOT recommended +MacOS with an ARM (M-series chip) processor is NOT recommended -The way Docker for Mac on an Arm CPU is designed makes the I/O incredibly slow, and blockchains are _**very**_ heavy on I/O. This only seems to affect MacOS, other Arm based systems like Raspberry Pi work as expected. +The way Docker for Mac on an Arm CPU is designed makes the I/O incredibly slow, and blockchains are _**very**_ heavy on I/O. This only seems to affect MacOS with the M-series chip, other Arm based systems like Raspberry Pi work as expected. {% endhint %} ### **Quickstart** diff --git a/guides-and-tutorials/running-a-signer/best-practices-to-run-a-signer.md b/guides-and-tutorials/running-a-signer/best-practices-to-run-a-signer.md index 3edf70965e..dc2493cd45 100644 --- a/guides-and-tutorials/running-a-signer/best-practices-to-run-a-signer.md +++ b/guides-and-tutorials/running-a-signer/best-practices-to-run-a-signer.md @@ -12,79 +12,56 @@ tl;dr: avoid single point of failures, introduce redundancy, monitor things. ### Monitor your Signer and collect logs -- See - [here](https://www.notion.so/guides-and-tutorials/running-a-signer/how-to-monitor-signer.md) - on how to set up monitoring. -- Retain at least 1 week of logs for both the Signer and the Stacks node. +* See [here](how-to-monitor-signer.md) on how to set up monitoring. +* Retain at least 1 week of logs for both the Signer and the Stacks node. ### Downstream components -- Run a *dedicated* Bitcoin node and Stacks node per Signer. - - Ensure the nodes are provisioned with the minimum hardware requirements - described - [here](https://docs.stacks.co/guides-and-tutorials/running-a-signer#minimum-system-requirements). - - Nodes should be *exclusively dedicated* to serve the Signer. Avoid - re-using them to serve other clients as that may negatively affect - performance (no *mock-signing*, no *Stacks API nodes*). -- If running dedicated nodes is not possible, then ensure that the Bitcoin / - Stacks nodes do not become single point of failures for *multiple* signers - depending on them. - - Introduce redundancy, load balancing, rely on a robust Bitcoin RPC - provider, etc. +* Run a _dedicated_ Bitcoin node and Stacks node per Signer. + * Ensure the nodes are provisioned with the minimum hardware requirements described [here](https://docs.stacks.co/guides-and-tutorials/running-a-signer#minimum-system-requirements). + * Nodes should be _exclusively dedicated_ to serve the Signer. Avoid re-using them to serve other clients as that may negatively affect performance (no _mock-signing_, no _Stacks API nodes_). +* If running dedicated nodes is not possible, then ensure that the Bitcoin / Stacks nodes do not become single point of failures for _multiple_ signers depending on them. + * Introduce redundancy, load balancing, rely on a robust Bitcoin RPC provider, etc. ### Split voting power across multiple Signers -- Distribute your voting power across multiple, distinct Signer public keys to - mitigate the risk of loss or downtime from a single compromised key. -- Each Signer should also limit voting power to a maximum amount and invite - Stackers to use a different Signer when the limit is reached. +* Distribute your voting power across multiple, distinct Signer public keys to mitigate the risk of loss or downtime from a single compromised key. +* Each Signer should also limit voting power to a maximum amount and invite Stackers to use a different Signer when the limit is reached. ### Monitor new software releases -- Stay up-to-date with new releases, patches, and security advisories (e.g., - GitHub, mailing lists, Discord). -- Apply updates as quickly as possible, especially those addressing a security - vulnerability. +* Stay up-to-date with new releases, patches, and security advisories (e.g., GitHub, mailing lists, Discord). +* Apply updates as quickly as possible, especially those addressing a security vulnerability. ### Upgrade procedures -- Upgrading one Signer instance at the time. -- Test the update on one instance and, if successful, proceed to the others. -- While your Signer is offline for upgrades, it won't sign any blocks. Ensure - that the downtime is as short as possible. +* Upgrading one Signer instance at the time. +* Test the update on one instance and, if successful, proceed to the others. +* While your Signer is offline for upgrades, it won't sign any blocks. Ensure that the downtime is as short as possible. ### Diversified hosting -- Use different provider / configuration where feasible (e.g., a self-hosted - instance and one in the cloud, or in two different data center regions, etc.). -- Ensure each host has redundant power supply and network connectivity. +* Use different provider / configuration where feasible (e.g., a self-hosted instance and one in the cloud, or in two different data center regions, etc.). +* Ensure each host has redundant power supply and network connectivity. ### Fall-back deployments -- Deploy additional Stacks nodes and Bitcoin nodes to be used as fall-back. - - Use the same configuration as your _active_ instances. - - For the Stacks node, comment out the `event_observer` section. -- Prepare a backup Signer (same configuration) to be quickly activated, but _do - not run it_. - - At all times, there should be _exactly_ one Signer instance running for each - Signer private key. -- These instances should be hosted on separate physical hosts (see *diversified - hosting*) from the instances usually active in operations (serving each - Signer). -- If an active instance (e.g., the Signer, the Stacks node or the Bitcoin node) - fails, you can quickly switch to the fall-back configuration to continue - operations. To do that: - - Run the backup Signer. - - Enable the `event_observer` section of the Node configuration. - - Restart the node. +* Deploy additional Stacks nodes and Bitcoin nodes to be used as fall-back. + * Use the same configuration as your _active_ instances. + * For the Stacks node, comment out the `event_observer` section. +* Prepare a backup Signer (same configuration) to be quickly activated, but _do not run it_. + * At all times, there should be _exactly_ one Signer instance running for each Signer private key. +* These instances should be hosted on separate physical hosts (see _diversified hosting_) from the instances usually active in operations (serving each Signer). +* If an active instance (e.g., the Signer, the Stacks node or the Bitcoin node) fails, you can quickly switch to the fall-back configuration to continue operations. To do that: + * Run the backup Signer. + * Enable the `event_observer` section of the Node configuration. + * Restart the node. ### Redundancy in operations -- Ensure that multiple, trusted users can manage and maintain signer instances. -- Where feasible, users should span different timezones. +* Ensure that multiple, trusted users can manage and maintain signer instances. +* Where feasible, users should span different timezones. ### Backup signer keys in cold-storage -- Keep an offline, secure backup of all Signer private keys (e.g., hardware - security modules or encrypted storage devices). - +* Keep an offline, secure backup of all Signer private keys (e.g., hardware security modules or encrypted storage devices).