# Security Considerations When Running a Base Node: A Complete Guide > Discover essential security considerations for running a Base node. Learn to isolate services, verify software versions, restrict network exposure, and protect RPC credentials for optimal security. - Repository: [Base/node](https://github.com/base/node) - Tags: how-to-guide - Published: 2026-03-03 --- **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`](https://github.com/base/node/blob/main/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`](https://github.com/base/node/blob/main/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`](https://github.com/base/node/blob/main/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`](https://github.com/base/node/blob/main/SECURITY.md), enabling continuous external security review. ## Summary - **Container isolation**: Services run in Docker containers defined in [`docker-compose.yml`](https://github.com/base/node/blob/main/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`](https://github.com/base/node/blob/main/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`](https://github.com/base/node/blob/main/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.