> ## Documentation Index
> Fetch the complete documentation index at: https://cosmos-docs-security-release.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Running in Production
**Synopsis**
This section describes how to securely run a node in a public setting and/or on a mainnet on one of the many Cosmos SDK public blockchains.
When operating a node, full node, or validator in production it is important to set your server up securely.
This walkthrough assumes the underlying operating system is Ubuntu.
There are many different ways to secure a server and your node. The steps described here are for informational purposes only.
## Server Setup
### User
When creating a server most times it is created as user `root`. This user has heightened privileges on the server. When operating a node, it is recommended to not run your node as the root user.
1. Create a new user
```bash theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sudo adduser change_me
```
2. We want to allow this user to perform sudo tasks
```bash theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sudo usermod -aG sudo change_me
```
Now when logging into the server, the non `root` user can be used.
### Go
1. Install the [Go](https://go.dev/doc/install) version recommended by the application.
In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/issues/13976) when using different versions of Go. It is recommended that the whole validator set uses the version of Go that is recommended by the application.
### Firewall
Nodes should not have all ports open to the public; this is a simple way to get DDoS'd. Secondly, it is recommended by [CometBFT](https://github.com/cometbft/cometbft) to never expose ports that are not required to operate a node.
When setting up a firewall, there are a few ports that can be open when operating a Cosmos SDK node. These include the CometBFT JSON-RPC, Prometheus, p2p, remote signer, and Cosmos SDK gRPC and REST. If the node is being operated as a node that does not offer endpoints to be used for submission or querying, then a maximum of three endpoints are needed.
Most, if not all servers come equipped with [ufw](https://help.ubuntu.com/community/UFW). Ufw will be used in this tutorial.
1. Reset UFW to disallow all incoming connections and allow outgoing
```bash theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sudo ufw default deny incoming
sudo ufw default allow outgoing
```
2. Let's make sure that port 22 (SSH) stays open.
```bash theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sudo ufw allow ssh
```
or
```bash theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sudo ufw allow 22
```
Both of the above commands are the same.
3. Allow Port 26656 (cometbft p2p port). If the node has a modified p2p port then that port must be used here.
```bash theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sudo ufw allow 26656/tcp
```
4. Allow port 26660 (CometBFT [Prometheus](https://prometheus.io)). This acts as the application's monitoring port as well.
```bash theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sudo ufw allow 26660/tcp
```
5. If the node which is being set up would like to expose CometBFT's JSON-RPC and Cosmos SDK gRPC and REST, then follow this step. (Optional)
##### CometBFT JSON-RPC
```bash theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sudo ufw allow 26657/tcp
```
##### Cosmos SDK gRPC
```bash theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sudo ufw allow 9090/tcp
```
##### Cosmos SDK REST
```bash theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sudo ufw allow 1317/tcp
```
6. Lastly, enable ufw
```bash theme={"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}}
sudo ufw enable
```
### Signing
If the node that is being started is a validator there are multiple ways a validator could sign blocks.
#### File
File-based signing is the simplest and default approach. This approach works by storing the consensus key generated on initialization to sign blocks. This approach is only as safe as your server setup, as if the server is compromised, so is your key. This key is located in the `config/priv_val_key.json` directory generated on initialization.
A second file exists that users must be aware of; the file is located in the data directory `data/priv_val_state.json`. This file protects your node from double signing. It keeps track of the consensus key's last sign height, round, and latest signature. If the node crashes and needs to be recovered, this file must be kept in order to ensure that the consensus key will not be used for signing a block that was previously signed.
#### Remote signer
A remote signer is a secondary server that is separate from the running node that signs blocks with the consensus key. This means that the consensus key does not live on the node itself. This increases security because your full node which is connected to the remote signer can be swapped without missing blocks.
The Cosmos stack's remote signer is Cosmos-KMS, which holds the consensus key in a file, a PKCS#11 HSM, or AWS KMS. For what remote signing is and how it works, see [Cosmos-KMS and remote signing](/sdk/next/kms/remote-signing). To set a signer up end to end, follow the [remote signing tutorial](/sdk/next/kms/tutorial-file-backend), then harden the setup with [remote signing best practices](/sdk/next/kms/best-practices). Validators that need high availability through key sharding use [Horcrux](https://github.com/strangelove-ventures/horcrux) instead.
TMKMS, the previous remote signer, is deprecated. Validators running it should move to Cosmos-KMS. See [Migrate from TMKMS](/sdk/next/kms/migrate-from-tmkms).