This is not for the faint of heart. We assume you have Docker experience, especially since we are making somewhat major modifications to eth-docker.

High-level Overview of Architecture

Before diving into the setup, let’s go over the game plan. Note the “nesting”

1. Proxmox as the hypervisor running on bare-metal
   • LXC running within Proxmox
     • Docker containers managed by eth-docker running inside the LXC

leading to…

Hardware Prerequisites

• Quad Core CPU
• 4TB “mainstream” SSD – TLC and DRAM, formatted in ext4
• 32 GiB of RAM – 16 GiB works but can be challenging depending on client mix

As noted on the eth-docker documentation, you might be able to get away with smaller SSD and less RAM. However, you’re about to stake 32 Eth which at today’s market value is almost $90K USD. You’re not hurting for the $300 to get an enterprise grade 4TB SSD (at least that’s what I told myself to justify the purchase).

Configuring the LXC Container

When setting up an LXC from Proxmox, my go-to is the Proxmox VE Helper-Scripts (I may be slightly biased as I am part of the Proxmox Helper Scripts org). From your host shell, grab the Docker LXC

bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/docker.sh)"

When setting up, make sure to give the LXC 4 cores and 32GB RAM!

Let’s make sure the SSD is mounted to the LXC. Navigate to /etc/pve/lxc on the host machine and vi <lxc>.conf

...
hostname: eth-docker
memory: 32768
mp0: /mnt/ethchain,mp=/mnt/ethchain
...

Now we’ve set up the LXC, let’s go to the LXC shell and start setting things up from there

Setting up eth-docker

From here, you can follow the eth-docker quickstart:

cd ~ && git clone https://github.com/eth-educators/eth-docker.git && cd eth-docker

# Install pre-requisites such as Docker

./ethd install

# Configure Eth Docker - have an Ethereum address handy where you want Execution Layer rewards to go

./ethd config

For config, you can start with the testnet, and select Ethereum node. I chose to use Prysm consensus client and Geth execution client. For testing, MEV boost does not matter, but when reconfiguring for mainnet, you should opt for it.

After configuring, don’t run./ethd up just yet. This next step is the secret sauce for utilizing our SSD.

Volume Override to SSD

We want to create an override .yaml file that maps the volume from our host machine to the SSD.

my-volumes.override.yml:

services:
  ######################################################
  # Geth (execution)
######################################################

  execution:
    volumes:
      # Geth chain data (instead of named volumes geth-el-data / geth-eth1-data):
      - "${GETH_ETH1DATA_PATH}:/var/lib/goethereum"
      - "${GETH_DATA_PATH}:/var/lib/geth"

      # The JWT secret is usually shared with the consensus client for Engine API authentication.
      # Keep referencing a Docker volume if you like, or use a direct host path:
      - "jwtsecret:/var/lib/geth/ee-secret"

      # Localtime (optional)
      - "/etc/localtime:/etc/localtime:ro"

  ######################################################
  # Prysm: beacon (consensus) client ######################################################

  consensus:
    volumes:
      # By default, prysm.yml uses prysmbeacon-data -> /var/lib/prysm-og
      # and prysmconsensus-data -> /var/lib/prysm
      - "${PRYSM_BEACON_PATH}:/var/lib/prysm-og"
      - "${PRYSM_CONSENSUS_PATH}:/var/lib/prysm"

      # The beacon client needs the JWT secret to talk to Geth:
      - "jwtsecret:/var/lib/prysm/ee-secret"

      - "/etc/localtime:/etc/localtime:ro"

  ######################################################
  # Prysm: validator client
######################################################

  validator:
    volumes:
      # The validator’s data: typically prysmvalidator-data -> /var/lib/prysm
      - "${PRYSM_VALIDATOR_PATH}:/var/lib/prysm"

      # Usually the validator does NOT need the JWT secret. 
      # If you have a specialized setup (e.g., external builder), you might do it differently.
      # - "jwtsecret:/var/lib/prysm/ee-secret"

      - "/etc/localtime:/etc/localtime:ro"

Save this file, and now go to your .env and modify the COMPOSE_FILE line in your .env

# The settings for eth-docker are in .env, use "nano .env". Don't edit default.env itself.
# Client choice: See https://eth-docker.net/Usage/Advanced for available options
COMPOSE_FILE=prysm.yml:geth.yml:grafana.yml:grafana-shared.yml:mev-boost.yml:my-volumes.override.yml:deposit-cli.yml:prysm-web-shared.yml
...

We also want to add the override paths to our .env. I suggest you add them to the end of the .env file

# Prysm volumes
PRYSM_BEACON_PATH=/mnt/ethchain/prysm/beacon
PRYSM_CONSENSUS_PATH=/mnt/ethchain/prysm/consensus
PRYSM_VALIDATOR_PATH=/mnt/ethchain/prysm/validator

# Geth volumes
GETH_DATA_PATH=/mnt/ethchain/geth/data
GETH_ETH1DATA_PATH=/mnt/ethchain/geth/eth1data

Now, we can finally start the stack

./ethd up

Importing Validator Keys

At this point, our node is up and the consensus and execution layer should be syncing. With a good internet connection, expect this to take several hours to an entire day, so don’t fret if it seems to be syncing forever.

From here, follow the Eth Docker Docs for key creation.

I did personally run into an issue with using the keymanager API. As noted by the docs:

If you use the Prysm Web, you can use it or this command-line process to import keys.

As seen in the .env, we have enabled Prysm Web so we can bypass the keymanager API. This is where you want to import the keystore-xxxxxxxx.json that was generated when you create the keys.

Deposit at launchpad

I think this part deserves its own section. It’s honestly pretty nerve-wracking to send 32 Eth and the Mainnet launchpad honestly sucks, but following the steps does get you there. I refreshed the page after depositing and it put me back to the start of the launchpad, which was not ideal. At any rate, after depositing, you can check the status of your deposit on the Prysm Web UI

Once it makes it past the Consensus Layer, pop the champagne as you just set up a validator node!

After-party and Security Notes

Remember to:

• Keep your system updated regularly
• Use strong passwords for all services
• Consider implementing additional firewall rules, as you should have completed in the Validator Checklist
• Regularly backup your validator keys and wallet information

Conclusion

Running eth-docker in a Proxmox LXC container provides a flexible and maintainable environment for your Ethereum node. This setup offers good isolation while maintaining performance and allowing for easy backups and migrations.

As recommended by the Mainnet Launchpad checklists, join the Discord communities for your consensus and execution clients, and check the eth-docker GitHub repository for updates and best practices.

Thanks for reading!

For a while, my other blog (https://gunkata.blog) was hosted on EasyWP. There’s nothing inherently wrong with EasyWP, it is in fact the quickest way to get something hosted on WordPress and not worry about servers, databases, or anything at all. However, EasyWP monthly does cost $6.88, and if you don’t switch to a yearly plan, that is over $80 a year. Since then, I’ve switched it over to host it myself on my server. In this quick writeup, I’ll show how you can get WordPress up and running on your local machine and be well on your way to self-host WordPress and save yourself $80 a year.

Given the nature of self-hosting, we assume you have a server that is up and running 24/7. WordPress is lightweight so any computer that could run Linux would do. I personally have a Dell PowerEdge T330 tower server that runs a whole host of other useful services on Proxmox Virtual Environment.

Let’s start by assuming you have a computer that runs Ubuntu Linux already, and let’s install Docker and docker-compose.

# Update package index
sudo apt update

# Install prerequisites
sudo apt install -y apt-transport-https ca-certificates curl software-properties-common

# Add Docker's GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Add Docker's official repository
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install Docker and Docker Compose
sudo apt update && sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

# Start Docker and enable it to run on boot
sudo systemctl start docker
sudo systemctl enable docker

# Add current user to Docker group (optional but recommended)
if ! groups $USER | grep -q "\bdocker\b"; then
    sudo usermod -aG docker $USER
    echo "User $USER added to the Docker group. Please log out and log back in to use Docker without sudo."
fi

That was a flurry of commands but hopefully you’re still with me. Now, we want to set up a docker-compose.yml that creates our WordPress container and a MySQL container. We’re going to go with the LAMP stack, which is Linux, Apache, MySQL, and PHP. The docker-compose.yml file can be created and placed anywhere you’d like.

example docker-compose.yml:

version: '3.7'

services:
  wordpress:
    image: wordpress
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpresspass
      WORDPRESS_DB_NAME: wordpress
    depends_on:
      - db

  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: strongpassword
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpresspass

Now we’ve made the docker-compose.yml, we can fire up the containers!

docker-compose up -d

Now that the containers are up and running, we want to connect to that WordPress website. As we had configured on our docker-compose.yml, WordPress runs on port 8080. Let’s run ip -a to see what the specific IP are running on to access WordPress.

root@hostname:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eth0@if32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.1.12/24 brd 192.168.x.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 xxxx:xxxx:xxxx:xxxx::xxxx/64 scope global dynamic mngtmpaddr 
       valid_lft 1780sec preferred_lft 1780sec
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

As noted in bold, that is our local IP. So if we go to the browser, we want to access 192.168.1.12:8080 and we would be able to finish setting up WordPress.

And that pretty much wraps up part 1! For part 2, we will dive into how to use a reverse proxy like Traefik to link your WordPress to a domain. Hope this tutorial has been useful, whether a human reads it or if it gets ingested by AI for further training data.