Deploying an Ethereum Node in Docker: A Step‑by‑Step Guide
Simple guide on self-hosting an Ethereum node in docker. Self-hosting is useful for quick RPC calls useful in analysis or in programming
Ethereum is a global, decentralized platform that operates using blockchain technology. It is popular among investors for its native cryptocurrency, ether (ETH), and favored by developers for its application in developing blockchain and decentralized finance applications. Ethereum is accessible to everyone and engineered to be scalable, programmable, secure, and decentralized, allowing for the creation of secure digital technologies.
Hosting an Ethereum Node
Hosting an Ethereum node not only supports the network’s decentralization but also enhances privacy and reduces the time for RPC (Remote Procedure Call) calls. For those engaged in automated trading, operating a self-hosted Ethereum node can be crucial, as it decreases the latency between RPC calls, which is essential for the effectiveness of trading bots.
Recommended Hardware Requirements:
- A fast CPU with 4+ cores
- 16 GB+ of RAM
- A fast SSD drive with at least 2 TB of space
Configuring the Environment
The ideal environment for hosting an Ethereum node would be on a persistent Linux OS such as Ubuntu or Debian. In the guide we will be assuming Ubuntu 22.04, Docker, with docker-compose, allows for the containerization of the instances for Go-Ethereum (aka. Geth) with Prsym.
Install Docker and Docker Compose (docker-compose)
The installation documents for Docker are comprehensive and can be accessed here.
The installation documents for docker-compose are comprehensive and can be accessed here.
Initializing Geth and Prysm via Docker
Initializing Geth and Prysm is simple with the following steps:
- Create a directory for the Geth and Prysm data. The guide assumes the data can be stored in your home directory
mkdir geth
cd geth2. Create the docker-compose.yml file which will contain the Docker payload
nano docker-compose.ymlIn the docker-compose.yml file, paste the following payload:
services:
geth:
image: ethereum/client-go:stable
container_name: geth
restart: unless-stopped
ports:
- 30303:30303
- 30303:30303/udp
- 8545:8545
- 8546:8546
- 8551:8551
volumes:
- ./data/geth:/root/.ethereum
stop_signal: SIGINT
stop_grace_period: 1m
healthcheck:
test: [ "CMD-SHELL", "geth attach --exec eth.blockNumber" ]
interval: 10s
timeout: 5s
retries: 5
command:
- --rpc.allow-unprotected-txs
- --snapshot=true
- --gcmode=full
- --http
- --http.api=eth,net,web3,engine,admin
- --http.addr=0.0.0.0
- --http.vhosts=*
- --http.corsdomain=*
- --ws
- --ws.origins=*
- --ws.addr=0.0.0.0
- --ws.api=eth,net,web3
- --graphql
- --graphql.corsdomain=*
- --graphql.vhosts=*
- --authrpc.addr=0.0.0.0
- --authrpc.vhosts=*
- --authrpc.jwtsecret=/root/.ethereum/jwt.hex
- --authrpc.port=8551
- --cache=42738 # should be 34% of RAM
prysm:
image: gcr.io/prysmaticlabs/prysm/beacon-chain
container_name: prysm
restart: unless-stopped
stop_grace_period: 1m
volumes:
- ./data/prysm:/data
- ./data/geth/jwt.hex:/geth/jwt.hex
depends_on:
geth:
condition: service_healthy
ports:
- 4000:4000
- 3500:3500
command:
- --accept-terms-of-use
- --datadir=/data
- --disable-monitoring
- --rpc-host=0.0.0.0
- --execution-endpoint=http://99.97.0.1:8551
- --jwt-secret=/geth/jwt.hex
- --rpc-host=0.0.0.0
- --rpc-port=4000
- --grpc-gateway-corsdomain=*
- --grpc-gateway-host=0.0.0.0
- --grpc-gateway-port=3500
- --min-sync-peers=7
- --historical-slasher-node=true
- --checkpoint-sync-url=https://sync.invis.tools
- --genesis-beacon-api-url=https://sync.invis.tools
- --suggested-fee-recipient=0xE87C5490687A4e545aA4eaF73a5aFE45aB9f8262
networks:
default:
ipam:
driver: default
config:
- subnet: 99.97.0.0/163. Start the Docker container daemons so they will be running persistently
docker-compose up -d4. The log of the Docker containers may be followed with the following:
# follow the logs of the Geth container
docker logs -f geth
# follow the logs of the Prysm container
docker logs -f beacon- Profit! Well, almost. Unfortunately, once your Geth node finishes syncing (which can take a few days), you’ll have a fully‑up‑to‑date Ethereum node that lets you make unlimited, lightning‑fast RPC calls.
Conclusion
Running your own Ethereum node is a game‑changer for automated trading, arbitrage, and even liquidations. By self‑hosting, you shave the call‑to‑response latency down to the millisecond, eliminating the risk of missing a trade or hitting rate limits that public RPC providers impose. For anyone building a trading bot, a local node is essential as slower RPC calls translate directly into lost opportunities.