Creating a Native Rocket Pool Node without Docker
This guide is designed for Smartnode v1.6.5 and higher.
If you are using a previous version, you must upgrade to v1.6.5 or higher before configuring Native mode.
In this section, we will walk through the process of installing the Rocket Pool Smartnode stack natively onto your system, without the use of Docker containers.
The general plan is as follows:
- Create a standard solo-staking setup with
systemdservices for the Execution Client, the Consensus Client / Beacon Node, and the Validator Client
- Create system services for the Rocket Pool components (the node and watchtower processes)
- Configure Rocket Pool to communicate with your client services
- Update your Validator Client service definition to use Rocket Pool's fee recipient and validator keys
This is a fairly involved setup so it will take some time to complete.
The diversity of Operating Systems and distros available make it impractical to make guides available for all of them. The instructions in this guide are tailored to a Debian-based system (including Ubuntu). For other distros or operating systems, you may follow the high-level steps described in the guide but will have to substitute certain commands for the ones that your system uses as appropriate.
This guide is intended for users that are experienced with Linux system administration and usage. This includes using the terminal, creating system accounts, managing permissions, and installing services. We assume you are familiar with these activities - as you will be managing the bulk of the infrastructure yourself, we only provide limited support for Native installations. If you are not familiar with these activities, we do not recommend that you use Native Mode.
Step 1: Set up the Execution and Consensus Clients
Native Mode effectively extends a standard solo-staking setup, and simply allows the Smartnode software to attach to the clients that it already runs (with a few small modifications).
To that end, we recommend you start by following some of the conventional solo staking guides provided by the community:
- Somer Esat's set of guides per-client: https://github.com/SomerEsat/ethereum-staking-guides
- CoinCashew guides: https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet
Note that you won't actually create a validator as defined in those guides - Rocket Pool will do that for you. You can ignore the portions involving the Staking Deposit CLI tool.
You simply need to follow the guides to the point where you have an Execution Client service, a Consensus Client / Beacon Node service, and a Validator Client service all installed and syncing the chain. Skip the steps that involve funding a validator and recording its mnemonic.
Also, there is a special case for the fee recipient - when you get to the portion of the guide where you specify the fee recipient in your Validator Client configuration, leave it blank for now. We will describe how to set it up for Rocket Pool validators below.
Once your clients are installed and you can see in their logs that they are syncing the chains properly, you can follow the next steps to set up the Rocket Pool Smartnode and connect it to your clients.
Step 2: Install Rocket Pool
Creating the Service Account
The first step is to create a new system account for the Rocket Pool services and disable login and shell access for it:
sudo useradd -r -s /sbin/nologin rp
Now, add yourself to the
rp group. You'll need to do this in order to use the Rocket Pool CLI, because it and the Rocket Pool daemon both need to access the Execution layer wallet file.
sudo usermod -aG rp $USER
Finally, add the user account for your Validator Client to the
rp group as well. The name of that user account depends on which guide you followed to set up your VC service.
For example, if your VC runs as user
lighthousevalidator, you would do the following:
sudo usermod -aG rp lighthousevalidator
After this, logout and back in for the changes to take effect.
Setting up the Binaries
Start by making a folder for Rocket Pool and a data subfolder. You can put this wherever you want; for this guide, I'll put it into
sudo mkdir -p /srv/rocketpool
sudo chown $USER:$USER /srv/rocketpool
Now, download the CLI and daemon binaries (or ignore this and build them from source if you prefer). Choose the platform that your system uses from the tabs below.
sudo wget https://github.com/rocket-pool/smartnode-install/releases/latest/download/rocketpool-cli-linux-amd64 -O /usr/local/bin/rocketpool
sudo wget https://github.com/rocket-pool/smartnode-install/releases/latest/download/rocketpool-daemon-linux-amd64 -O /usr/local/bin/rocketpoold
sudo chmod +x /usr/local/bin/rocketpool
Now, set the owner and group of the daemon to
sudo chown rp:rp /usr/local/bin/rocketpoold
Finally, set the
suid bit and other permissions bits on the daemon binary:
sudo chmod u+sx,g+sx,o-rwx /usr/local/bin/rocketpoold
This will ensure that the daemon always runs as the
rp user, so it always has the proper permissions set.
The Smartnode will most likely fail with permissions errors if you don't do this. Please be sure to run this command!
Setting up the Installation Folder
With the CLI and Daemon installed, you'll need to next set up the folder structure and accompanying files that the Smartnode expects to exist. Start by creating the following folders:
mkdir -p /srv/rocketpool/data/validators && sudo chmod 775 /srv/rocketpool/data/validators
sudo chown -R rp:rp /srv/rocketpool/data
Next, download the following scripts - Rocket Pool will use them when it needs to stop or restart your Validator Client to change its fee recipient (discussed later) or load new keys after you create a new minipool:
wget https://github.com/rocket-pool/smartnode-install/raw/release/install/scripts/restart-vc.sh -O /srv/rocketpool/restart-vc.sh
wget https://github.com/rocket-pool/smartnode-install/raw/release/install/scripts/stop-validator.sh -O /srv/rocketpool/stop-validator.sh
chmod +x /srv/rocketpool/restart-vc.sh
chmod +x /srv/rocketpool/stop-validator.sh
~/.profile with your editor of choice and add this line to the end:
alias rp="rocketpool -d /usr/local/bin/rocketpoold -c /srv/rocketpool"
Save it, then reload your profile:
This will let you interact with Rocket Pool's CLI with the
rp command, which is a nice shortcut.
Creating the Services
Next up, we'll create a
systemd service for the Rocket Pool node daemon. This is the service that will automatically check for and claim RPL rewards after each checkpoint, and stake minipools once you've created them via
We'll also create a
watchtower service as well. This will be used if you're an Oracle DAO member, or if you ever want to generate your own rewards interval trees (discussed in the Claiming Rewards section later on).
sudo nano /etc/systemd/system/rp-node.service
ExecStart=/usr/local/bin/rocketpoold --settings /srv/rocketpool/user-settings.yml node
Create a log file for the service, so you can watch its output - this will replace the behavior of
rocketpool service logs node:
journalctl -u rp-node -b -f
Save it, then make it executable:
chmod +x /srv/rocketpool/node-log.sh
Now you can watch the node's logs by simply running:
The services are now installed.
Setting up Passwordless Script Access
The next step is to give the
rp user the ability to restart the Validator Client when new validator keys are created, and stop the Validator Client if an emergency condition is detected.
Create a new
sudoers file using
sudo visudo -f /etc/sudoers.d/rocketpool
Add the following lines to it:
Cmnd_Alias RP_RESTART = /usr/bin/systemctl restart <validator service name>
Cmnd_Alias RP_STOP = /usr/bin/systemctl stop <validator service name>
rp ALL=(ALL) NOPASSWD: RP_RESTART, RP_STOP
<validator service name> is the name of your VC service (e.g.
- Uncomment the line at the end and change it to
sudo systemctl restart <validator service name>
- Uncomment the line at the end and change it to
sudo systemctl stop <validator service name>
All set! The
node process can now restart or stop your VC as required automatically.
Step 3: Configure the Smartnode
Now that your services are all created, it's time to configure the Smartnode stack.
Please visit the Configuring the Smartnode Stack (Native Mode) guide, and return here when you are finished.
Enabling and Running the Services
With all of the services installed, it's time to:
- Enable them so they'll automatically restart if they break, and automatically start on a reboot
- Start them all
sudo systemctl daemon-reload
sudo systemctl enable rp-node rp-watchtower
sudo systemctl start rp-node rp-watchtower
Setting Up a Wallet
Next, create a new node wallet or recover an existing wallet. Please carefully follow the instructions in the Setting up a Wallet portion of the guide, then return here when you're done.
Once that's done, use the service log file scripts to verify that they successfully loaded your new wallet. You should also verify this using the following command:
rp wallet status
If working properly it should produce the following output:
Your Smartnode is currently using the Holesky Test Network.
The node wallet is initialized.
Node account: <address>
Step 4: Update the VC Service Definition
Unlike a solo staking setup, Rocket Pool generates and manages its validator keys automatically. There are a few adjustments you'll need to make to the VC service definition file you just created in order for it to work with Rocket Pool correctly, including:
- The Fee Recipient
- The VC's data or wallet directory
- The VC's keys and secrets directories
We'll cover these step-by-step for each client.
Setting Up the Fee Recipient File
It is crucial that you follow these steps - failing to do so and using the wrong fee recipient will result in penalties being applied to your validators and deductions taken from your Beacon Chain balance!
The fee recipient is the argument you provide to your Validator Client that specifies the address on the Execution layer that you want your priority fees and MEV rewards to be sent to. Rocket Pool has two different addresses for the fee recipient:
- If you are opted into the Smoothing Pool, it must be the Smoothing Pool's address
- If you are opted out of the Smoothing Pool, it must be your node's Fee Distributor address
To learn more about the Smoothing Pool and your Fee Distributor, please see the Fee Distributors and the Smoothing Pool section of the guide.
node service will set this for you automatically by detecting which one it needs to be and setting it in a configuration file and restarting your Validator Client service to pick up the change. Your Validator Client service can use that configuration file automatically so you don't need to hard-code the fee recipient.
systemd service definition file that you just created for your Validator Client. Before the
ExecStart line, add this line:
Then modify your fee recipient argument as follows; select your client of choice from the tabs below:
--suggested-fee-recipient <address> to
If you start your Validator Client before Rocket Pool's services, it may error out because this file does not exist yet. Don't worry, this file will be created by Rocket Pool once you've initialized and started its services.
Setting the Data and Keys Directories
Next, you must tell the VC where to store its data and load the validator keys that Rocket Pool generates. Click on the client you use in the tabs below:
Create the following directories and set their owner to
sudo mkdir -p /srv/rocketpool/data/validators/lighthouse/validators
sudo mkdir -p /srv/rocketpool/data/validators/lighthouse/secrets
sudo chown -R rp:rp /srv/rocketpool/data/validators/lighthouse
sudo chmod -R 775 /srv/rocketpool/data/validators/lighthouse
Now, add or change the following parameters in the Lighthouse VC's service definition file to these new values:
By default, your system will typically come with a
umask configuration that will strip the
+w bit from the group permissions whenever the
node daemon creates a new folder. This is problematic for several consensus clients, because they will actually write things such as lock files or other metadata into the directories that the Smartnode creates when it generates new validator keys during a minipool deposit.
To combat this and ensure your VC works correctly, please relax your
umask settings. For example, instead of
0022, you should consider setting it to
0002 for the
Every system is different, so please consult a guide that covers your Operating System to learn how to do this.
This step is crucial to ensure the automatic staking and validating duties are handled properly. If you notice permissions problems in your VC's logs after your minipool passes the 12-hour scrub check and enters
staking status, you will likely need to run
sudo chmod 775 on the folder containing your validator keys so your VC service can write to that folder.
Reloading the VC Service
With these changes made, you can now reload and restart the VC service using the following:
sudo systemctl daemon-reload
sudo systemctl restart <vc-service>
If not using Prysm, please watch the VC's logs carefully to ensure that it successfully started properly and the following are defined correctly:
- The fee recipient
- The data path
- The wallet / keys / secrets path
You can verify this with, for example,
ps aux | grep fee to filter the running processes to look at the fee recipient that your VC has used. It should be the same one defined in
If they are all using the correct values, then congratulations! You've successfully set up your Rocket Pool node and can follow the next sections of the guide to learn how to use it.
Now that your clients are installed, we recommend you take a look at the security suggestions in the Securing your Node section next. As you're running a Native setup, you have likely done some of these things already; nevertheless, it doesn't hurt to at least explore it and see how well the recommended security posture fits with your system.