# Best Practices to Run a Signer

{% hint style="info" %}
**Intended audience**: solo Stackers or Stacking pool operators.
{% endhint %}

The following best practices suggest how to create a resilient setup for running your Signer.

{% hint style="info" %}
tl;dr: avoid single point of failures, introduce redundancy, monitor things.
{% endhint %}

### Monitor your Signer and collect logs

* See [here](/operate/run-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.

### 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 points of failure 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.

### 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.

### Upgrade procedures

{% stepper %}
{% step %}
**Test one instance first**

Upgrade one Signer instance at a time. Test the update on a single instance and verify functionality before proceeding to others.
{% endstep %}

{% step %}
**Roll out gradually**

If the test is successful, proceed to upgrade the remaining instances one-by-one.
{% endstep %}

{% step %}
**Minimize downtime**

While a Signer is offline for upgrades, it won't sign any blocks. Ensure that the downtime is as short as possible.
{% endstep %}
{% endstepper %}

### 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.

### 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 fall-back instances should be hosted on separate physical hosts (see diversified hosting) from the instances usually active in operations (serving each Signer).

To switch to the fall-back configuration quickly if an active instance fails, follow these steps:

{% stepper %}
{% step %}
**Run the backup Signer**

Start the prepared backup Signer instance.
{% endstep %}

{% step %}
**Enable event observer**

Enable the `event_observer` section of the Stacks node configuration.
{% endstep %}

{% step %}
**Restart the node**

Restart the Stacks node so it runs with the enabled `event_observer`.
{% endstep %}
{% endstepper %}

### Redundancy in operations

* Ensure that multiple, trusted users can manage and maintain signer instances.
* Where feasible, users should span different timezones.

### Auto-restart configuration

Configure your signer and Stacks node to automatically restart on failure to minimize downtime.

#### Docker

Use the `--restart` flag when running containers to enable automatic restarts:

```bash
docker run -d \
    --restart unless-stopped \
    -v $STX_SIGNER_CONFIG:/config.toml \
    -v $STX_SIGNER_DATA:/var/stacks \
    -p 30000:30000 \
    -e RUST_BACKTRACE=full \
    -e BLOCKSTACK_DEBUG=0 \
    --name stacks-signer \
    $IMG:$VER \
    stacks-signer run \
    --config /config.toml
```

The `unless-stopped` policy restarts the container automatically if it crashes or the host reboots, but not if you explicitly stop it. Apply the same policy to your Stacks node container.

#### systemd

If running as a binary, create a systemd service unit to handle automatic restarts. Example for the signer:

{% code title="/etc/systemd/system/stacks-signer.service" %}

```ini
[Unit]
Description=Stacks Signer
After=network.target
StartLimitBurst=3
StartLimitIntervalSec=300
ConditionFileIsExecutable=/usr/local/bin/stacks-signer
ConditionPathExists=/etc/stacks/signer
ConditionFileNotEmpty=/etc/stacks/signer/signer-config.toml

[Service]
ExecStart=/usr/local/bin/stacks-signer run --config /etc/stacks/signer/signer-config.toml
User=stacks-signer
Group=stacks-signer
Type=simple
Restart=on-failure
RestartSec=10
TimeoutStopSec=600
KillSignal=SIGTERM

[Install]
WantedBy=multi-user.target
```

{% endcode %}

Example for the Stacks node:

{% code title="/etc/systemd/system/stacks-node.service" %}

```ini
[Unit]
Description=Stacks Node
After=network.target
StartLimitBurst=3
StartLimitIntervalSec=300
ConditionFileIsExecutable=/usr/local/bin/stacks-node
ConditionFileNotEmpty=/etc/stacks/node/node-config.toml

[Service]
ExecStart=/usr/local/bin/stacks-node start --config /etc/stacks/node/node-config.toml
User=stacks-node
Group=stacks-node
Type=simple
Restart=on-failure
RestartSec=10
TimeoutStopSec=600
KillSignal=SIGTERM

[Install]
WantedBy=multi-user.target
```

{% endcode %}

Enable and start the services:

```bash
sudo systemctl daemon-reload
sudo systemctl enable stacks-signer.service stacks-node.service
sudo systemctl start stacks-signer.service
sudo systemctl start stacks-node.service
```

Check their status at any time:

```bash
sudo systemctl status stacks-signer.service
sudo systemctl status stacks-node.service
```

View logs with:

```bash
journalctl -xefu stacks-signer
journalctl -xefu stacks-node
```

### 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).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stacks.co/operate/run-a-signer/best-practices-to-run-a-signer.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.