How to Run a Polkadot Validator Node: Step-by-Step

Running a Polkadot validator node is more than installing the node software and leaving it online. A validator has to stay synchronized with the network, maintain reliable connectivity, protect its session keys, and meet Polkadot’s staking requirements before it can participate in block production and finality.

That makes the Polkadot node setup a combination of server administration and on-chain configuration. The server needs to be prepared and secured, the Polkadot binaries installed and synchronized, and the validator’s keys and stake correctly registered before it can enter the active validator set.

This guide shows how to run a Polkadot node. We walk through the whole process step-by-step from preparing the server to checking that the validator is active and operating correctly.

#What is a Polkadot node?

A Polkadot node is a computer that validates transactions and blocks against the consensus rules implemented by the Polkadot protocol. A Polkadot node participates in the Polkadot network by storing a copy of the relay chain (and, depending on its role, connected parachains) and, in the case of validators, contributing to the shared security model that secures Polkadot's parachains.

#Polkadot validator vs. RPC node

A Polkadot validator and an RPC node serve very different purposes, even though both stay synced with the Polkadot network. A validator stakes DOT and actively participates in consensus, whereas an RPC node doesn't. A validator's job is to secure the network, and it gets penalized for underperforming, while an RPC node's job is to serve data to others, judged on responsiveness and uptime rather than consensus participation.

#How to become a Polkadot validator?

To become a Polkadot validator, you need to run reliable validator node infrastructure, hold enough DOT to meet the minimum stake threshold, and generate session keys to bind your node to your on-chain validator account. From there, if your total stake ranks high enough among candidates, you're selected into the active validator set for that era.

#Polkadot Node Requirements

Before installing the validator software, the server needs to meet Polkadot’s hardware, networking, software, and staking requirements. Validators perform time-sensitive consensus and parachain validation work, so consistent CPU performance, fast storage, and reliable connectivity matter more than simply meeting a minimum server size.

Polkadot node requirements depend on the type of node you're running. Polkadot validator nodes are the most demanding, since they handle consensus and parachain validation directly, followed by RPC nodes and archive nodes.

For an in-depth breakdown of CPU, memory, storage, networking, and hosting considerations, see our Polkadot Node Requirements guide.

#What Do You Need to Run a Polkadot Validator Node?

For a production Polkadot validator, the requirements article recommends:

Polkadot recommends Intel Ice Lake or AMD Zen 3 processors and newer, with strong single-core performance. Hyper-Threading or simultaneous multithreading (SMT) should be disabled, while HDDs, SATA SSDs, and shared network storage should be avoided because inconsistent disk latency can affect validator performance.

The official network baseline is 500 Mbps symmetric, but 1 Gbps symmetric is the safer choice for production because it provides more headroom for synchronization, peer communication, traffic spikes, and future network growth. The validator should also have a publicly routable peer-to-peer connection and should not expose public RPC services that could compete with validation traffic.

Blockchain hardware setup is only one part of the requirement. A validator must also maintain at least 10,000 DOT of self-stake from its own stash account. This stake is slashable and separate from any stake provided by nominators. If the validator falls below the threshold, it can become eligible to be permissionlessly chilled from the active set. Validator commission is currently fixed at 0%.

#How to Run a Polkadot Validator Node: Step-by-Step

Running a validator node means preparing the right server, syncing the node, and bonding DOT before you can join the active set. Here's a step-by-step walkthrough of how to run a Polkadot node, from hardware setup to going live.

#Step 1: Prepare the Validator Server

Before installing Polkadot, connect to the server and prepare the operating environment. For this setup, the validator runs on a Cherry Servers bare metal server, which provides dedicated CPU, memory, and local storage rather than sharing those resources with other tenants.

Connect to the Server With SSH

Once the bare metal server has been provisioned, use its public IP address and login credentials to connect through Secure Shell (SSH).

From Linux or macOS, open a terminal and run:

ssh root@SERVER_IP

Replace SERVER_IP with the public IP address assigned to the server. For example:

ssh root@192.0.2.10

The first connection may display a message asking whether the server's SSH fingerprint should be trusted. Confirm the connection after verifying the fingerprint, then enter the server password when prompted.

For ongoing administration, SSH key authentication is preferable to password-based login. An SSH key can be copied to the server with:

ssh-copy-id root@SERVER_IP

Once connected, the terminal prompt will be running commands directly on the validator server.

Update the Server

Start by updating the package index and installed packages:

sudo apt update && sudo apt upgrade -y

For production deployments, the validator process should run under a dedicated non-root user rather than directly as root. This limits the permissions available to the process and keeps the node files separate from general system administration.

Create a dedicated Polkadot user:

sudo adduser polkadot

root@above-tahr:~# sudo adduser polkadot
info: Adding user `polkadot' ...
info: Selecting UID/GID from range 1000 to 59999 ...
info: Adding new group `polkadot' (1001) ...
info: Adding new user `polkadot' (1001) with group `polkadot (1001)' ...
info: Creating home directory `/home/polkadot' ...
info: Copying files from `/etc/skel' ...
New password: 
Retype new password: 
passwd: password updated successfully
Changing the user information for polkadot
Enter the new value, or press ENTER for the default
	Full Name []: 
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
Is the information correct? [Y/n] Y
info: Adding new user `polkadot' to supplemental / extra groups `users' ...
info: Adding user `polkadot' to group `users' ...
root@above-tahr:~# 

The validator's data directory and service permissions can later be assigned to this account.

Configure Time Synchronization

A validator's local clock needs to remain synchronized with the network. Significant clock drift can interfere with time-sensitive consensus activity and cause the validator to miss participation opportunities.

Check the current synchronization status with:

timedatectl

You should see something similar to the output below:

root@above-tahr:~# timedatectl
               Local time: Thu 2026-08-27 18:18:03 UTC
           Universal time: Thu 2026-08-27 18:18:03 UTC
                 RTC time: Thu 2026-08-27 18:18:03
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

If time synchronization is not active, enable the system's Network Time Protocol (NTP) service before continuing.

For systems using systemd-timesyncd, run:

sudo timedatectl set-ntp true

Then check the status again:

timedatectl

Check Landlock Support

Polkadot also recommends checking for Landlock, a Linux security feature that restricts the files and resources a process can access. It provides an additional layer of isolation if the validator process is compromised.

Check whether Landlock is available with:

sudo dmesg | grep landlock

or:

sudo journalctl -kg landlock

The output should look like this:

root@above-tahr:~# sudo dmesg | grep landlock
[    0.217581] LSM: initializing lsm=lockdown,capability,landlock,yama,apparmor,ima,evm
[    0.217596] landlock: Up and running.
root@above-tahr:~# 

Landlock is available in modern Linux kernels, including versions newer than the Linux 5.16 baseline used for Polkadot validators.

Once the server is accessible through SSH, updated, time-synchronized, and ready for the validator process, the next step is installing the Polkadot binaries.

#Step 2: Install the Polkadot Validator Software

With the server prepared, the next step is to install the software required to run the validator. A Polkadot validator uses three binaries:

• polkadot, which runs the main node;

• polkadot-prepare-worker, which prepares parachain validation workloads;

• polkadot-execute-worker, which executes those workloads.

All three binaries are required for validator operation and should use matching versions. For this guide, we will install Polkadot through the APT package manager on Ubuntu.

Add the Polkadot APT Repository

Remain logged in with administrative privileges for this step.

First, import Parity's release signing key:

gpg --keyserver hkps://keyserver.ubuntu.com \
  --receive-keys 90BD75EBBB8E95CB3DA6078F94A4029AB4B35DAE

If the Ubuntu keyserver returns an error such as:

gpg: keyserver receive failed: Server indicated a failure

retry the request over port 80:

gpg --keyserver hkp://keyserver.ubuntu.com:80 \
  --receive-keys 90BD75EBBB8E95CB3DA6078F94A4029AB4B35DAE

A successful import should return output similar to:

gpg: key 94A4029AB4B35DAE: public key "ParityReleases <release-team@parity.io>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Export the key to the system keyring:

gpg --export 90BD75EBBB8E95CB3DA6078F94A4029AB4B35DAE \
  > /usr/share/keyrings/parity.gpg

Add the Parity repository:

echo 'deb [signed-by=/usr/share/keyrings/parity.gpg] https://releases.parity.io/deb release main' \
  > /etc/apt/sources.list.d/parity.list

Update the package index:

apt update

Install the Parity keyring package:

apt install parity-keyring -y

Then install Polkadot:

apt install polkadot -y

Verify the Installation

Start by checking the installed binaries:

polkadot --version
polkadot-prepare-worker --version
polkadot-execute-worker --version

The polkadot command should return the installed version. However, depending on the APT package layout, the two worker binaries may initially return command not found even though they were installed successfully.

If this happens, check where the package installed them:

dpkg -L polkadot | grep worker

The output may look similar to:

/usr/lib/polkadot/polkadot-execute-worker
/usr/lib/polkadot/polkadot-prepare-worker

In this case, the binaries exist but /usr/lib/polkadot/ is not included in the shell's $PATH. Create symbolic links so they can be called directly:

ln -s /usr/lib/polkadot/polkadot-prepare-worker /usr/local/bin/polkadot-prepare-worker
ln -s /usr/lib/polkadot/polkadot-execute-worker /usr/local/bin/polkadot-execute-worker

Now check the versions again:

polkadot --version
polkadot-prepare-worker --version
polkadot-execute-worker --version

All three commands should now return their respective version information. You can also confirm their accessible locations with:

which polkadot
which polkadot-prepare-worker
which polkadot-execute-worker

Prepare the Validator Data Directory

Before running the node under the dedicated polkadot account, create a directory for its blockchain data:

mkdir -p /var/lib/polkadot

Assign ownership of the directory to the polkadot user created earlier:

chown -R polkadot:polkadot /var/lib/polkadot

Now switch to that account:

sudo su - polkadot

From this point, validator-specific files and processes can be managed under the dedicated polkadot user rather than root. The next step is configuring and starting the validator node.

#Step 3: Generate a Static Node Key

Before synchronizing the node, configure a permanent node identity. Polkadot uses a node key for peer-to-peer communication, allowing other nodes to identify the validator consistently when it reconnects to the network.

Since we switched to the polkadot user at the end of the previous step, the following commands should now be run from that account.

Generate the Node Key

Generate a static node key and save it inside the validator data directory:

polkadot key generate-node-key \
  --file /var/lib/polkadot/node.key

Polkadot recommends generating the key separately rather than allowing a new identity to be created whenever the node starts. The same key should then be supplied whenever the validator launches.

Restrict access to the key file:

chmod 600 /var/lib/polkadot/node.key

You can confirm that the file exists with:

ls -l /var/lib/polkadot/node.key

Do not share this file or copy it between independently running validators.

Start the Node for the First Time

With the node key in place, start Polkadot on MainNet using the data directory created earlier:

polkadot \
  --chain polkadot \
  --base-path /var/lib/polkadot \
  --node-key-file /var/lib/polkadot/node.key \
  --name "YOUR_VALIDATOR_NAME" \
  --telemetry-url "wss://telemetry.polkadot.io/submit/ 0"

Replace YOUR_VALIDATOR_NAME with a unique name that makes the node easy to identify later in Polkadot Telemetry.

The --telemetry-url option sends the node's status information to the public Polkadot Telemetry dashboard. This makes it possible to monitor synchronization progress, block height, peer connections, and node version from a browser.

At this stage, the node is deliberately started without validator duties. Polkadot recommends synchronizing the blockchain first before moving on to staking and validator activation. By default, the node performs a full synchronization from genesis.

If you prefer to reach the current chain state faster, use warp sync instead:

polkadot \
  --chain polkadot \
  --base-path /var/lib/polkadot \
  --node-key-file /var/lib/polkadot/node.key \
  --name "YOUR_VALIDATOR_NAME" \
  --sync warp \
  --telemetry-url "wss://telemetry.polkadot.io/submit/ 0"

Warp sync downloads GRANDPA finality proofs and the latest finalized state first, allowing the node to reach the current network state faster while historical blocks continue downloading afterward.

Once the command starts, the terminal will continue displaying synchronization logs, peer connections, block numbers, and other node activity. The process remains running in the foreground until it is stopped with Ctrl + C.

The next step is to use those logs and Polkadot Telemetry to confirm that the node has synchronized successfully.

#Step 4: Confirm That the Node Is Synchronized

Once the node is running, confirm that it has caught up with the Polkadot network before moving on to validator activation. A validator should be following the current chain state consistently before session keys are generated and registered.

Check the Synchronization Logs

The node continuously prints synchronization information to the terminal. Look for lines similar to:

best: #32741967, finalized #32741963

The best value represents the highest block the node has processed, while finalized shows the latest block it recognizes as finalized.

During synchronization, the gap between the node and the current network block height will gradually reduce. Once synchronized, the best block should stay close to the network head and continue increasing as new blocks are produced.

If warp sync was used, you may still see messages such as:

Block history, #8388758

This is expected. Warp sync first brings the node to the latest finalized state, then continues downloading older block history in the background. The presence of historical synchronization does not necessarily mean the node is behind the live network.

Check the Node Through Local RPC

For a direct check, open another SSH session while the node is still running and query its local JSON-RPC endpoint:

curl -s -H "Content-Type: application/json" \
  -d '{"id":1,"jsonrpc":"2.0","method":"system_health","params":[]}' \
  http://127.0.0.1:9944

A healthy synchronized node should return output containing values similar to:

{
  "jsonrpc": "2.0",
  "result": {
    "peers": 7,
    "isSyncing": false,
    "shouldHavePeers": true
  },
  "id": 1
}

The main values to check are:

• peers: confirms that the node is connected to other Polkadot nodes;

• isSyncing: should become false once the node considers itself synchronized;

• shouldHavePeers: should normally remain true.

You can also inspect the node's synchronization state directly:

curl -s -H "Content-Type: application/json" \
  -d '{"id":1,"jsonrpc":"2.0","method":"system_syncState","params":[]}' \
  http://127.0.0.1:9944

When the current block is at or very close to the highest known block and continues advancing with the network, the node is ready for the next stage.

Check Polkadot Telemetry

If the node was started with:

--telemetry-url "wss://telemetry.polkadot.io/submit/ 0"

you can also search for the node name on the Polkadot Telemetry dashboard.

Telemetry provides a graphical view of information such as:

• node name;

• block height;

• peer count;

• client version;

• synchronization status.

Telemetry is useful as a visual confirmation, but it should not be the only health check. A node can still be operating correctly even if it does not remain visible on the public dashboard.

Once the node is following the live chain reliably, the next step is generating the session keys that will connect the running node to its validator identity.

#Step 5: Generate and Register Validator Session Keys

Once the node is synchronized, the next step is to generate its session keys. These keys connect the validator software running on the server to the validator’s on-chain identity and are used for consensus activities such as block production and finality.

Generate the Session Keys

Keep the Polkadot node running and open a second SSH session to the server.

You will need the account you intend to use as the validator’s stash account. This is the Polkadot account that holds the DOT you intend to bond to the validator and financially backs its participation in staking.

Your wallet will normally display this account as an SS58 address, similar to:

16K48tMW9FNSBEVv1ZNwqDt18WR9yguo5gGMDYKorNyiKcHF

However, author_rotateKeysWithOwner expects the stash account’s 32-byte Account ID in hexadecimal format, beginning with 0x, rather than the SS58 address.

Run:

curl -H "Content-Type: application/json" \
  -d '{"id":1,"jsonrpc":"2.0","method":"author_rotateKeysWithOwner","params":["INSERT_STASH_ACCOUNT_ID"]}' \
  http://localhost:9944

Replace INSERT_STASH_ACCOUNT_ID with the hexadecimal Account ID associated with the stash account.

For example:

curl -H "Content-Type: application/json" \
  -d '{"id":1,"jsonrpc":"2.0","method":"author_rotateKeysWithOwner","params":["0x1234567890abcdef..."]}' \
  http://localhost:9944

Do not paste the normal SS58 wallet address directly into the command. If the RPC receives an SS58 address instead of the hexadecimal Account ID, it may return an error similar to:

Invalid params
invalid hex character

A successful request returns the session keys together with an ownership proof:

{
  "jsonrpc": "2.0",
  "result": {
    "keys": "0xda3861a45e0197f3ca145c2c209f9126e5053f...",
    "proof": "0x1a2b3c4d5e6f..."
  },
  "id": 1
}

Save both values. The keys value contains the validator’s public session keys, while proof confirms that the keys were generated for the specified stash account.

Running author_rotateKeysWithOwner again generates a new set of session keys rather than returning the previous set, so keep the original output somewhere secure.

Generating the keys happens locally on the node and does not require DOT.

Register the Session Keys on Polkadot Hub

The session keys now need to be registered on-chain through Polkadot Hub.

Unlike generating the keys locally, this step requires DOT because setKeys submits an on-chain transaction. The signing account needs enough DOT to cover the transaction fee and the session-key deposit, which is currently approximately 60 DOT. The deposit can later be released when the keys are removed using purgeKeys.

Open Polkadot.js Apps and make sure the connected network is Polkadot Hub, also known as Asset Hub, rather than the Polkadot relay chain.

This distinction matters because the available staking pallets differ between the two networks.

If you see:

stakingAhClient

you are connected to the Polkadot relay chain.

Switch to Polkadot Hub (Asset Hub). Once connected to the correct network, the pallet required for this step should appear as:

stakingRcClient

Then:

1. Go to Developer > Extrinsics.

2. Select the stash account associated with the validator.

3. Select stakingRcClient.

4. Choose the setKeys extrinsic.

5. Paste the value returned earlier as keys.

6. Paste the value returned as proof.

7. Leave maxDeliveryAndRemoteExecutionFee as None unless a specific fee limit is required.

8. Review the transaction, then submit and sign it.

The stakingRcClient pallet on Polkadot Hub forwards the session-key registration to the relay chain. Once the transaction succeeds, the validator’s session keys are registered on-chain and associated with the stash account.

Protect the Session Keys

The private portions of the session keys remain in the validator’s local keystore. They should stay on the validator server and should not be copied to another validator that is running at the same time.

Using the same active session keys on multiple validator instances can result in conflicting signatures and expose the validator to slashing.

Once the session keys have been registered successfully, the next step is bonding DOT and declaring the account’s intent to validate.

#Step 6: Activate the Validator Using Polkadot.js Apps

With the node synchronized and its session keys generated and registered, the next step is to bond DOT and declare the account’s intent to validate. This part of the setup is completed through Polkadot.js Apps.

A Polkadot validator currently needs at least 10,000 DOT of self-stake. This stake comes from the validator’s own account, remains slashable, and is separate from stake provided by nominators. Validator commission is currently fixed at 0%, with validator rewards instead tied to self-stake.

1. Open the Staking Interface

Open Polkadot.js Apps and connect the wallet containing the stash account used throughout the setup.

From the Network menu, select Staking async.

2. Start the Validator Setup

Open the Accounts tab and select + Validator.

This opens the validator configuration wizard, where the stash account, bonded stake, session keys, and validator preferences can be configured. The official activation workflow uses this interface to declare the account’s intention to validate.

3. Select the Stash Account and Bond DOT

Choose the same stash account associated with the validator’s session keys.

In the Value bonded field, enter the amount of DOT that will provide the validator’s self-stake.

A validator must currently maintain at least:

10,000 DOT

The self-stake remains slashable and must stay above the minimum threshold. If it falls below 10,000 DOT, the validator can become eligible to be permissionlessly chilled from the active set.

Avoid bonding the account’s entire balance. Leave enough DOT available for transaction fees and future staking operations.

Once the account and bonded amount are correct, select Next.

4. Enter the Session Keys and Validator Preferences

The next screen asks for the validator’s session keys and ownership proof.

Paste the same keys and proof values generated with author_rotateKeysWithOwner in Step 5. If the keys were already submitted through stakingRcClient.setKeys, use the same values when the validator setup interface requests them.

Next, configure the validator preferences.

For Commission, enter the percentage of staking rewards the validator will retain. Since the March 2026 runtime upgrade, Polkadot requires validators to set a minimum commission of 10%. Validators configured below 10% can be permissionlessly chilled through staking.chillOther.

The Blocked nominations setting determines whether new nominators can back the validator. It is false by default, meaning the validator accepts new nominations. Enable it only if new nominations should be prevented.

5. Select Bond & Validate

Review the validator configuration, then select Bond & Validate and sign the transaction with the connected account.

This bonds the specified DOT and declares the account’s intent to participate as a validator. The session keys associate that on-chain validator account with the node running on the server.

Submitting the transaction does not guarantee that the validator becomes active immediately. The node may first enter the waiting queue until a validator slot becomes available and the validator set refreshes at the start of a new era.

6. Confirm the Validator Setup

After selecting Bond & Validate and signing the transaction, return to:

Network > Staking async

The validator account should now appear among the accounts that have declared their intent to validate.

A newly configured validator may not become active immediately. It can remain in a waiting state until it receives sufficient backing and is selected into the active validator set.

At this point, the validator setup is complete. Keep the node online, synchronized, and connected to peers while it waits for selection.

The next step is to move the Polkadot process from the foreground terminal into a systemd service so it can run continuously without depending on an open SSH session.

#Optional: Run the Validator as a systemd Service

The validator can run directly from the terminal, but that is not ideal for long-term operation. Closing the SSH session or rebooting the server would stop the process.

Running Polkadot as a systemd service keeps the validator running in the background, starts it automatically after a reboot, and allows it to restart after an unexpected failure.

Create the systemd Service

First, stop the foreground Polkadot process with:

Ctrl + C

Then create a service file:

sudo nano /etc/systemd/system/polkadot-validator.service

Add the following configuration:

[Unit]
Description=Polkadot Validator
After=network.target
Documentation=https://github.com/paritytech/polkadot-sdk

[Service]
ExecStart=/usr/bin/polkadot \
  --chain polkadot \
  --base-path /var/lib/polkadot \
  --node-key-file /var/lib/polkadot/node.key \
  --name "YOUR_VALIDATOR_NAME" \
  --telemetry-url "wss://telemetry.polkadot.io/submit/ 0" \
  --validator

User=polkadot
Group=polkadot
Restart=always
RestartSec=120

[Install]
WantedBy=multi-user.target

Replace YOUR_VALIDATOR_NAME with the same node name used earlier in the guide.

The --validator flag starts the node with validator duties enabled. Restart=always tells systemd to restart the process if it exits, while RestartSec=120 adds a two-minute delay before restarting.

Enable and Start the Service

Reload systemd so it recognizes the new service:

sudo systemctl daemon-reload

Enable the service so it starts automatically when the server boots:

sudo systemctl enable polkadot-validator.service

Enabling the service does not necessarily start it immediately, so start it separately:

sudo systemctl start polkadot-validator.service

Then verify its status:

sudo systemctl status polkadot-validator.service

A successfully running validator should show:

  root@above-tahr:~# sudo systemctl status polkadot-validator.service
● polkadot-validator.service - Polkadot Validator
     Loaded: loaded (/etc/systemd/system/polkadot-validator.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-08-28 01:01:39 UTC; 45s ago
       Docs: https://github.com/paritytech/polkadot-sdk
   Main PID: 49834 (polkadot)
      Tasks: 153 (limit: 114440)
     Memory: 2.6G (peak: 2.6G)
        CPU: 37.240s
     CGroup: /system.slice/polkadot-validator.service
             └─49834 /usr/bin/polkadot --chain polkadot --base-path /var/lib/polkadot --node-key-file /var/lib/polkadot/node.key --name "DEMIGOD TOMZY" --telemetry-url "wss://telemetry.polkadot.io/submit/ 0" --validator

If the service instead shows:

Active: inactive (dead)

start it manually with:

sudo systemctl start polkadot-validator.service

and check the status again.

View the Validator Logs

Once the validator is running as a background service, follow its logs with:

sudo journalctl -f -u polkadot-validator

The output should continue showing peer connections, imported blocks, finalized blocks, and other validator activity.

If the service fails to start, inspect the recent logs with:

sudo journalctl -u polkadot-validator.service -n 50 --no-pager

With the validator running under systemd, the node no longer depends on an open SSH session and can continue operating in the background.

#Keep the Validator Running Reliably

Once the validator is active, the main responsibility is keeping it online, synchronized, and secure. Regularly check the node logs, peer connections, disk usage, and system resources to catch problems before they affect validator participation.

Keep the Polkadot binaries updated, protect the node and session keys, and avoid running the same active session keys on multiple validator instances because this can create slashing risk. The validator should also continue meeting the required self-stake and infrastructure requirements over time.

For ongoing monitoring, the validator logs can be followed with:

sudo journalctl -f -u polkadot-validator

#Next Steps

With the Polkadot validator node installed, synchronized, configured, and running under systemd, the initial setup is complete. From here, the priority is keeping the node online, updated, and properly monitored while maintaining the required self-stake and protecting the validator keys.

For more detail on infrastructure sizing, see our Polkadot Node Requirements guide, and for budgeting, see our guide on the cost of running a Polkadot node.