Stake on a VPS

1Why a VPS, and the catch

A wallet only stakes while it is running, online and unlocked. A laptop that sleeps at night stakes for part of the day. A VPS (a small virtual server rented by the month) runs all day, every day, on a fast connection, for a few dollars a month.

The catch is that the server is someone else's computer on the open internet. To stake, the wallet's keys must sit unlocked in its memory. Anyone who breaks into the server, or anyone at the hosting company, could in principle take them. Decide how much of that risk you want before you copy coins anywhere.

2Pick a route: vault or wallet

If you take the wallet route, encrypt the wallet (Encrypt your wallet) and prefer the Divi node: it can unlock for staking only, so the passphrase in memory cannot be used to send. IronDivi has no staking-only unlock; its unlock opens the wallet fully.

IronDivi encrypts from 0.2.6, the release installed below. The older 0.2.5 answers error code: -32601: Method not found: encryptwallet.

3How big a server

What we measured, and what it means for a mainnet server:

Mainnet passed block 4,269,900 on the day we checked, so a full mainnet folder is well over 4.7 GB today. A plan with 2 GB of memory and 25 GB of disk leaves room for either node and years of growth; that is our margin, not a measured need. Any 64-bit Linux works. We used Ubuntu 24.04, and the commands below assume Ubuntu or Debian.

4A user and a firewall

Log in to the server as a user with sudo. First give the node a user of its own, so a bug in the node cannot touch the rest of the system. Its home folder /var/lib/divi will hold the chain and the wallet:

sudo adduser --system --group --home /var/lib/divi divi
info: Adding system user `divi' (UID 101) ...
info: Creating home directory `/var/lib/divi' ...

Then the firewall. Allow SSH before you turn it on, or you will lock yourself out of your own server:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 51472/tcp      # Divi peers, mainnet (51474 on testnet)
sudo ufw enable
sudo ufw status

The node only needs to reach out to stake. Opening 51472 also lets other nodes connect to you, which helps the network but is optional. Keep the RPC port closed. Both nodes answer RPC only on the server itself (127.0.0.1) unless told otherwise, and that is where you will run commands.

5IronDivi as a service

Download and check the release as in Install IronDivi, then copy the two programs to /usr/local/bin:

cd /tmp
curl -LO https://github.com/DiviDomains/IronDivi/releases/download/v0.2.6/irondivi-x86_64-linux-musl.tar.gz
sha256sum irondivi-x86_64-linux-musl.tar.gz
35735a2f3d1f9ec1728d295d5a611a010ade4cdd27bda662032b458a63e0a1fc  irondivi-x86_64-linux-musl.tar.gz
tar xzf irondivi-x86_64-linux-musl.tar.gz
sudo install -m 755 irondivi-x86_64-linux-musl/irondivid irondivi-x86_64-linux-musl/irondivi-cli /usr/local/bin/

Create the file /etc/systemd/system/irondivid.service (for example with sudo nano) holding:

[Unit]
Description=IronDivi node
After=network-online.target
Wants=network-online.target

[Service]
User=divi
Group=divi
ExecStart=/usr/local/bin/irondivid --datadir /var/lib/divi/.irondivi --txindex
Restart=on-failure
RestartSec=30
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target

Start it now and on every boot, then ask it the block height. IronDivi needs no config file to run this way.

sudo systemctl daemon-reload
sudo systemctl enable --now irondivid
systemctl status irondivid
     Active: active (running) since Thu 2026-10-22 11:01:58 UTC; 30s ago
sudo -u divi irondivi-cli --datadir /var/lib/divi/.irondivi getblockcount

• No --daemon. systemd keeps the program in the foreground and watches it; a node that forks into the background confuses it.
• No ExecStop. systemd stops IronDivi with the normal stop signal, which took under a second in our test. In one test the RPC stop command left the old process running for more than three minutes, holding its database, so the new one could not start.
• Testnet first? Add --testnet to the ExecStart line and to each irondivi-cli command. That is how we ran it.

Then save the wallet's 24-word recovery phrase with dumphdinfo, as in the install tutorial, and keep it off the server.

6The Divi node as a service

The same pattern with the Divi node 3.0.0 from Install the Divi node:

cd /tmp
curl -LO https://github.com/DiviProject/Divi/releases/download/v3.0.0/divi-3.0.0-x86_64-linux-gnu-9e2f76c.tar.gz
sha256sum divi-3.0.0-x86_64-linux-gnu-9e2f76c.tar.gz
d09933ab413335b7472b29c4c255d7affea73630b73a0d5c52aec40a63fbd276  divi-3.0.0-x86_64-linux-gnu-9e2f76c.tar.gz
tar xzf divi-3.0.0-x86_64-linux-gnu-9e2f76c.tar.gz
sudo install -m 755 divi-3.0.0/bin/divid divi-3.0.0/bin/divi-cli /usr/local/bin/
sudo install -d -o divi -g divi -m 700 /var/lib/divi/.divi

Unlike IronDivi, the Divi node will not start without an RPC password in its config file. It stopped at once with You must set rpcpassword=<password> in the configuration file until we added one. These lines write the config with a random password you never need to see:

printf 'server=1\nlisten=1\nstaking=1\nrpcuser=divirpc\nrpcpassword=%s\n' "$(openssl rand -hex 32)" \
  | sudo -u divi tee /var/lib/divi/.divi/divi.conf >/dev/null
sudo chmod 600 /var/lib/divi/.divi/divi.conf

Leave daemon=1 out of this file. The service file /etc/systemd/system/divid.service:

[Unit]
Description=Divi node
After=network-online.target
Wants=network-online.target

[Service]
User=divi
Group=divi
ExecStart=/usr/local/bin/divid -datadir=/var/lib/divi/.divi -daemon=0
ExecStop=/usr/local/bin/divi-cli -datadir=/var/lib/divi/.divi stop
Restart=on-failure
RestartSec=30
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now divid
sudo -u divi divi-cli -datadir=/var/lib/divi/.divi getblockcount

For testnet, add testnet=1 to divi.conf and open port 51474 instead. Run only one of the two nodes unless the server has room for both.

7Unlock after every restart

Skip this step on the vault route with an unencrypted manager wallet. We ran the IronDivi lines below on IronDivi 0.2.6. On the wallet route, every restart (a crash, an update, the host rebooting your server) brings the wallet back locked, and a locked wallet does not stake. We saw it on the Divi node right after a restart:

sudo -u divi divi-cli -datadir=/var/lib/divi/.divi getstakingstatus
    "walletunlocked" : false,
    "staking status" : false,

Unlock it again, typing the passphrase without echo so it stays out of your shell history (see Stake from the command line):

read -rs PASS
# Divi node: true = for staking only
sudo -u divi divi-cli -datadir=/var/lib/divi/.divi walletpassphrase "$PASS" 0 true
# IronDivi: full unlock, it has no staking-only mode
sudo -u divi irondivi-cli --datadir /var/lib/divi/.irondivi walletpassphrase "$PASS" 0
unset PASS

Twenty seconds later the Divi node showed "walletunlocked" : true and "staking status" : true, and getwalletinfo said "encryption_status" : "unlocked-for-staking". With a timeout of 0, IronDivi's wallet stayed "unlocked" for as long as we watched (over 15 minutes).

There is no safe way to unlock without you. A passphrase saved in a file on the server is a passphrase the next thief reads too. That is the strongest reason for the vault route.

8What a crash looks like

We killed each node outright (kill -9, the same as a power cut for the program) to see Restart=on-failure at work:

• IronDivi came back by itself 30 seconds later, every time.
• The Divi node failed its first restart both times we tried, with Error loading block database : Block database corruption detected! Failed to find best block in block index. The next restart, 30 seconds later, started cleanly and carried on syncing. The service file above rides through this on its own.

If the Divi node keeps failing with that message, the program has two repair options, -recoverblockdb and -reindex (which rebuilds the index from the block files). We did not need either and have not tested them. Read the latest errors with:

journalctl -u divid -n 30 --no-pager

9Keep an eye on it

• Height: compare getblockcount with the newest block in the explorer. A node more than a few blocks behind is still syncing or has lost its peers.
• Stakes: the Stake Watch bot sends a Telegram message for every stake to your address and warns when one is overdue. On the vault route, watch the vault's address.
• Expectations: Estimate your stakes tells you how long a gap is normal for your balance, and Why isn't my wallet staking? is the checklist when it isn't.
• Updates: install new releases the same way, then sudo systemctl restart irondivid (or divid) and unlock again.

10What we could not test

• No paid VPS. We did not rent one. The stand-in was a fresh Ubuntu 24.04 system running systemd inside a container on one of our Linux servers. The commands above ran there exactly as shown, plus --testnet.
• No reboot. enable created the start-on-boot link, but we never rebooted the stand-in, so starting on boot is unproven.
• No mainnet. Everything ran on testnet; the mainnet disk figure comes from an older mainnet folder.
• The unlock and crash tests ran on the same server with our lane's testnet wallets, which are encrypted and hold coins; the fresh stand-in had empty wallets. The IronDivi wallet there is a 0.2.6 build from source, made before the 0.2.6 release.
• Hosting companies differ, for example in whether they add a firewall of their own in a web panel. We name none and tested none.

Next

• Harden a staking server: SSH keys, updates, and less to attack.
• Stake on a Raspberry Pi: the same idea on a small computer at home.
• Vault staking service: let someone else run the server for your vault.
• Glossary for the words on this page.