Security Considerations When Running a Base Node: A Complete Guide

Running a Base node securely requires isolating containerized services, pinning verified software versions, restricting network exposure to localhost, and protecting L1 RPC credentials through environment-specific configuration files.

The base/node repository provides the infrastructure to run a Base Layer 2 node, but operators must understand the security architecture embedded in the codebase to protect both their infrastructure and the broader network. This guide examines the security controls built into the Docker deployment, version management, secret handling, and runtime hardening implemented in the official repository.

Docker-Based Deployment Isolation

The foundation of Base node security rests on container isolation defined in docker-compose.yml. The repository enforces service-level isolation by running the execution client and consensus client in separate containers with explicit restart policies.

All services launch via Docker Compose, which limits the attack surface by preventing direct host OS access. The compose file maps necessary ports—8545 for RPC, 8546 for WebSocket, and 7301 for metrics—but does not inherently restrict these to localhost, requiring operator intervention to secure network boundaries.

Version Pinning and Reproducible Builds

Supply-chain attacks are mitigated through deterministic build verification. The versions.env file pins exact Git commit hashes for every component including OP-Node, OP-Geth, reth, and Nethermind.

Each Dockerfile imports versions.env and validates the checkout hash before building. For example, in reth/Dockerfile, the build process verifies the commit hash against the pinned version before compilation, ensuring that only audited upstream code executes in production. This prevents malicious code injection during the build process.

Protecting Configuration Secrets

Sensitive configuration data requires strict separation from version control. The repository uses environment-specific files—.env.mainnet and .env.sepolia—to store L1 RPC URLs and API keys, while the base .env file contains only non-sensitive defaults like CLIENT and HOST_DATA_DIR.

Operators must supply their own L1 RPC endpoints via OP_NODE_L1_ETH_RPC in the per-network environment files. These files should never be committed to version control and must be added to .gitignore to prevent accidental exposure of credentials.

Network Exposure and Port Security

Default port mappings in docker-compose.yml expose critical services to the host network. Ports 8545 and 8546 provide RPC and WebSocket access, while 7301 exposes metrics endpoints.

Operators should create a docker-compose.override.yml file to bind these ports exclusively to localhost, preventing external network access. For production deployments, place the node behind a firewall or VPN, and restrict access to trusted interfaces only. If remote RPC access is necessary, deploy an authenticated reverse proxy rather than exposing the ports directly.

Trusted L1 Provider Configuration

The integrity of L1 data depends on trusted upstream providers. The node supports a whitelist of RPC kinds including alchemy, infura, and quicknode, configurable via OP_NODE_L1_RPC_KIND.

Selecting reputable providers and verifying TLS certificates prevents man-in-the-middle attacks on L1 data feeds. Avoid self-signed endpoints unless you control the entire trust chain, as tampered L1 data could compromise the L2 state.

Runtime and CI Hardening

The repository implements defense-in-depth through runtime and pipeline security. The final container image runs under the default unprivileged ubuntu:24.04 user, with supervisord managing processes without granting root capabilities.

In the CI pipeline, GitHub workflows utilize step-security/harden-runner to lock down the runner environment, preventing supply-chain compromises during the build process. Additionally, the project maintains a public bug-bounty program through HackerOne, as documented in SECURITY.md, enabling continuous external security review.

Summary

• Container isolation: Services run in Docker containers defined in docker-compose.yml with explicit restart policies and resource limits.
• Reproducible builds: versions.env pins exact commit hashes, and Dockerfiles verify these hashes before building components like reth or OP-Geth.
• Secret management: Store L1 RPC URLs and API keys in .env.mainnet or .env.sepolia, never in version control, while keeping non-sensitive defaults in .env.
• Network security: Bind RPC ports (8545, 8546) and metrics (7301) to localhost via docker-compose.override.yml or restrict via firewall/VPN.
• Trusted L1 providers: Use whitelisted RPC kinds (alchemy, infura, etc.) and verify TLS certificates to prevent data tampering.
• Runtime hardening: Containers run as unprivileged users, CI uses step-security/harden-runner, and security issues are reported via the HackerOne bug bounty program.

Frequently Asked Questions

How do I prevent unauthorized RPC access to my Base node?

Bind the RPC and WebSocket ports to localhost only by creating a docker-compose.override.yml file that maps 127.0.0.1:8545:8545 and 127.0.0.1:8546:8546. For remote access requirements, deploy an authenticated reverse proxy rather than exposing ports directly to the internet, and ensure firewall rules block external access to port 8545.

What is the purpose of the versions.env file in Base node security?

The versions.env file mitigates supply-chain attacks by pinning every component—OP-Node, OP-Geth, reth, Nethermind—to specific Git commit hashes. During the Docker build process, each Dockerfile imports this file and validates that the checked-out source code matches the pinned hash before compilation, ensuring deterministic and auditable builds.

Where should I store my L1 Ethereum RPC credentials when running a Base node?

Store sensitive L1 RPC URLs and API keys exclusively in the network-specific environment files—.env.mainnet for production or .env.sepolia for testnet—never in the base .env file or version control. These files should be added to .gitignore immediately, and you should verify that OP_NODE_L1_ETH_RPC and related variables are populated only through these secure environment files.

How does the Base node repository protect against CI/CD supply chain attacks?

The repository uses step-security/harden-runner in GitHub Actions workflows to lock down the CI runner environment, preventing unauthorized network connections and tampering during the build process. Additionally, Dockerfiles verify commit hashes from versions.env before building, ensuring that even if the CI environment were compromised, the resulting binaries would only originate from audited upstream commits.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}