This guide provides practical approaches to maintaining a secure and reliable Celestia validator infrastructure. While some of these practices can be applied to other validator chains, we'll focus on Celestia-specific considerations. This article aims to help operators strengthen their setups and contribute to network stability.
Through this guide, we'll cover essential security measures, monitoring practices, and operational procedures that every Celestia validator should implement. Whether you're setting up a new validator or improving an existing one, these practices will help minimize risks and maximize performance.
Infrastructure Requirements, Location & Security
Setting up a Celestia validator means picking the right hardware, choosing a good location, and implementing security that actually works.
Let's start with the server itself. The Celestia Docs recommends the following server specifications for running a validator node:
- CPU: 8 cores
- RAM: 16 GB
- Storage: 2 TB SSD
- Network: 1 Gbps for download/upload
While it's technically possible to run a node on lower specifications, doing so introduces significant risks that could impact both your validator's performance and potential rewards. Underpowered nodes often struggle with block processing and validation, especially during periods of network congestion. These performance issues can lead to missed blocks and, in worst cases, slashing penalties – consequences that far outweigh any initial cost savings from choosing cheaper hardware.
Node location, as well as server provider, plays an important role in network decentralization. According to C-DAF: Celestia Decentralization Analytics Framework as of this writing, there's significant concentration in specific regions and providers.
Currently overrepresented areas:
- Countries: Germany (21.11%), United States (16.6%), Finland (15.98%)
- Providers: Hetzner (27.66%), AWS (13.52%), OVH (8.4%)
To strengthen network decentralization, consider deploying your node in underrepresented regions using alternative providers. To see the latest decentralization data and overrepresented areas visit C-DAF.
Once you've chosen your location and provider, securing your server becomes the next critical step. Let's start with SSH security - it's your server's front door. Disable root login and password authentication right away. Instead, set up SSH keys for access. Think of SSH keys like a digital fingerprint - they're uniquely yours and much harder to fake than passwords. If you want to go extra secure, grab a YubiKey. It's a physical device that adds another security layer - even if someone somehow gets your SSH key, they'd still need your actual YubiKey to get in.
If your setup allows it, consider whitelisting specific IP addresses for SSH access. This means only computers from addresses you trust can even attempt to connect. Pair this with fail2ban, which automatically blocks suspicious IPs trying to force their way in. Set up a firewall too, but keep it simple - only open the ports node actually needs, like P2P, here is an example with ufw on Ubuntu:
# Deny all incoming connections by default
sudo ufw default deny incoming
# Allow all outgoing connections by default
sudo ufw default allow outgoing
# Allow SSH (customize the port if you changed it)
ufw allow ssh
# Allow Celestia P2P and RPC ports if needed
ufw allow 26656/tcp # P2P port
ufw allow 26657/tcp # RPC port, if using
# Enable the firewall
ufw enableYou need to know what's happening on your server. Keep tabs on your system resources, bandwidth usage, and disk space. Pick a monitoring stack you're comfortable with - whether that's something fancy like Grafana and Prometheus, or just good old htop. What matters is that you can spot problems before they become disasters.
Here's a solid rule: create separate users for different services. Your Celestia node should run under its own user account, and the same goes for any other software on your server. Don't run everything as root. If one service gets compromised, this separation helps contain the damage. This isn't complicated stuff, but it's crucial. Most successful attacks happen because someone skipped these basics, thinking "it won't happen to me." Don't be that person.
Validator Key Management
Your validator keys are literally your digital identity on the network - treat them like you would treat the keys to a bank vault. Hardware Security Modules (HSMs) are your best bet for key storage. They're not just fancy USB sticks; they're purpose-built security devices that keep your keys isolated from potentially compromised systems. If an HSM isn't in your budget, a Ledger hardware wallet is a solid alternative that many validators successfully use.
Here's a critical rule: never, ever store your validator keys on public-facing servers. It's like leaving your house keys in the front door lock. Instead, maintain backup keys in cold storage - physically secured and offline. When you do need to store keys on your system, use encrypted filesystems. Tools like LUKS (Linux Unified Key Setup) make this straightforward on Linux systems.
Remote signers are worth their weight in gold. They let you keep your signing keys on a completely separate machine from your validator node. Think of it as keeping your valuables in a separate location from your house's address listing. Popular options like tmkms (Tendermint Key Management System) make this setup more manageable than you might think.
Monitoring and Alerts
For monitoring and alerting we recommend using 21state/cosmos-watcher-stack monitoring stack.
Updates and Maintenance
Staying current with updates is like maintaining a shield - skip it, and you're vulnerable. For Ubuntu users, regularly check Ubuntu Security Notices for critical updates. Keep tabs on the Celestia Discord announcements channel and GitHub releases. Network upgrades aren't just feature additions - they often include critical security patches. Version compatibility is crucial; running outdated software isn't just about missing features, it could mean getting forked off the network entirely.