# Configuring a Native Rocket Pool Node without Docker
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 system services for the Rocket Pool components (the node process, and optionally the watchtower process if you are an Oracle Node)
- Create a system service for the ETH1 client
- Create a system service for the ETH2 beacon client
- Create a system service for the ETH2 validator client
- Configure Rocket Pool to use communicate with those services
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. If you are not familiar with these activites, we do not recommend that you use the native mode.
# Creating Service Accounts
The first step is to create new system accounts for the services and disable logins and shell access for them. The reason for having separate user accounts is practical: if your ETH1 or ETH2 clients have a major vulnerability like an Arbitrary Code Execution (opens new window) exploit, doing this will limit the amount of damage an attacker can actually do since they're running on an account with limited permissions.
We're going to create one account for your ETH1 client, one for your ETH2 client, and one for both Rocket Pool and the validator client. The sharing is necessary because Rocket Pool will create the validator's key files once you create a new minipool, and it will set the permissions so that only its own user has access to them. If you're using Nimbus for your ETH2 client, then it will share an account with Rocket Pool instead since it doesn't have a separate validator client.
Start by creating an account for your ETH1 client, which we'll call
sudo useradd -r -s /sbin/nologin eth1
Do the same for your ETH2 client, which we'll call
sudo useradd -r -s /sbin/nologin eth2
Finally, make one for the validator and Rocket Pool, which we'll call
sudo useradd -r -s /sbin/nologin rp
If you're using Nimbus, ignore the
Any time you see it used in this guide, just substitute it with
Now, add yourself to the
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 ETH1 wallet file.
sudo usermod -aG rp $USER
After this, logout and back in for the changes to take effect.
# Installing Rocket Pool
# 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/data sudo chown -R $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.
Next, grab the installation package - we're going to throw almost everything in here away since it's meant to support docker installs, but we need to copy two files:
- The config file that Rocket Pool uses to understand the directories and routes for everything
- The script that lets Rocket Pool restart the validator service once a new minipool is created (so it can load the new keys)
We also need to create the
settings.yml file that holds all of your node's specific configuration details.
The configuration for the Ethereum mainnet is different from the configuration for the Prater testnet! Choose which one you want to use, and follow the appropriate tab below.
Follow these steps for your system's architecture:
nano or your editor of choice, and make the following changes:
~/.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.
Finally, run the Rocket Pool configuration:
rp service config
Select your ETH1 and ETH2 clients of choice. The actual settings you choose don't matter (you'll be specifying them manually in the command line strings for each service when you create services for them), so just pick the defaults.
# 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
Optionally, if you're an Oracle DAO member, create the corresponding
watchtower service as well.
If you are not an Oracle DAO member, you can ignore that service.
# Installing ETH1
For the sake of simplicity, we're going to use Geth as our example during this guide. If you have another client in mind, adapt these instructions to that client accordingly.
Start by making a folder for the Geth binary and the log script:
sudo mkdir /srv/geth sudo chown $USER:$USER /srv/geth
Next, make a folder for the chain data on the SSD. Pick the set up that you have below:
Now, grab the latest Geth binary (opens new window) for your architecture, or build it from source (opens new window) if you want.
If you download it, it will be an archive.
Extract it and copy the contents of the
geth folder to
For example, if you have an x64 system:
cd /tmp wget https://gethstore.blob.core.windows.net/builds/geth-linux-amd64-1.10.3-991384a7.tar.gz tar xzf geth-linux-amd64-1.10.3-991384a7.tar.gz cp geth-linux-amd64-1.10.3-991384a7/geth /srv/geth
Next, create a systemd service for Geth. You can use this as a template, and modify the command line arguments as you see fit:
sudo nano /etc/systemd/system/geth.service
The above configuration is for the Ethereum mainnet.
If you want to run on the Prater testnet instead, replace the
--mainnet flag in the
ExecStart string with
- You can optionally use the
--cacheflag to lower the amount of RAM that Geth uses.
- If you have 4 GB of RAM, set this to 256.
- If you have 8 GB of RAM, you can leave it at 512 so it syncs faster and doesn't require pruning as frequently.
- For larger amounts of RAM, you can ignore this flag.
- You can optionally use the
--maxpeersflag to lower the peer count. The peer count isn't very important for the ETH1 node, and lowering it can free up some extra resources if you need them.
Lastly, add a log watcher script so you can check on Geth to see how it's doing:
sudo nano /srv/geth/log.sh
#!/bin/bash journalctl -u geth -b -f
Make it executable:
sudo chmod +x /srv/geth/log.sh
Now you can see the Geth logs by doing
This replaces the behavior that
rocketpool service logs eth1 used to provide, since it can't do that without Docker.
All set on the ETH1 client; now for ETH2.
# Installing ETH2
Start by making a folder for your ETH2 binary and log script. Choose the instructions for the client you want to run:
Next, create a systemd service for your ETH2 client. The following are examples that show typical command line arguments to use in each one:
- The user is set to
- For arm64 systems,
ionice -c 2 -n 0tells your system to give ETH2 the highest possible priority for disk I/O (behind critical system processes), so it can process and attest as quickly as possible
Next, add a log watcher script in the folder you put your ETH2 client into:
With that, ETH2 is all set. On to the validator client!
# Installing the Validator Client
Nimbus does not have a seperate validator client at this time, so it is not included in these instructions. If you plan to use Nimbus, you've already taken care of this during the ETH2 client setup and can skip this section.
First, create a systemd service for your validator client. The following are examples that show typical command line arguments to use in each one:
Next, add a log watcher script in the folder you put your validator client into:
Now, we have to give the
rp user the ability to restart the validator client when new validator keys are created.
sudo nano /etc/sudoers
Add this line under
# Cmnd alias specification, replacing
<validator service name> with the name of your validator service (e.g.
Cmnd_Alias RP_CMDS = /usr/bin/systemctl restart <validator service name>
Add this line under
# User privilege specification:
rp ALL=(ALL) NOPASSWD: RP_CMDS
That whole section should now look like this:
# Cmnd alias specification Cmnd_Alias RP_CMDS = /usr/bin/systemctl restart <validator service name> # User privilege specification root ALL=(ALL:ALL) ALL rp ALL=(ALL) NOPASSWD: RP_CMDS
- Uncomment the line at the end and change it to
sudo systemctl restart <validator service name>
The services are now installed, so it's time to enable and start them.
# 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!
The last step is to create a wallet with
rp wallet init or
rp wallet restore.
Once that's done, change the permissions on the password and wallet files so the Rocket Pool CLI, node, and watchtower can all use them:
sudo chown rp:rp -R /srv/rocketpool/data sudo chmod 660 /srv/rocketpool/data/password sudo chmod 660 /srv/rocketpool/data/wallet
And with that, you're ready to secure your operating system to protect your node.
Move on to the Securing your Node section next.