An execution client, not the whole node
Geth runs Ethereum's execution layer. It validates transactions and execution payloads, maintains chain state, joins the peer network, and exposes APIs that wallets, indexers, services, and developer tools can call. Since Ethereum moved to proof of stake, Geth must work beside a consensus client. The consensus client tracks the chain head and passes execution work through an authenticated Engine API connection.
That two-client arrangement is the first fact an operator needs. Installing a Geth binary does not produce a functioning mainnet node by itself. The official guide lists Lighthouse, Nimbus, Prysm, Teku, and Lodestar as consensus choices. Both processes must share a JWT secret and agree on the authenticated RPC address and port. Geth cannot sync until its consensus partner has a target head.
For developers, the repository is more than the node daemon. The abigen tool generates typed Go bindings from contract ABIs. The evm command runs and traces bytecode in an isolated environment. devp2p exposes peer-network utilities, while rlpdump decodes Ethereum's RLP format. These are useful even when a hosted provider supplies the production RPC.
Running it is infrastructure work
The README's minimum mainnet guidance calls for at least four CPU cores, 8 GB of RAM, 1 TB of free storage, and an 8 Mbit connection. Its recommended machine raises that to a fast eight-core CPU, at least 16 GB of RAM, a high-performance SSD with 1 TB free, and 25 Mbit download service. Capacity changes as the chain grows, so those figures are a starting point rather than a purchase guarantee.
Snap sync is the default. It begins from a recent point, downloads headers and bodies, builds state, then heals state that changed while the chain kept advancing. The storage device and connection must let healing catch up with new blocks. A full sync executes from genesis. Archive mode keeps historical state instead of pruning it, which is useful for historical queries but materially increases storage.
A Docker command makes the first process easy to launch, and official images are available. The volume, ports, sync progress, upgrades, database health, and consensus connection still belong to the operator. A configuration file can replace a long list of flags, and dumpconfig provides a base. Keep that configuration under review when releases change defaults. Version 1.17.5, for example, changed the default Go garbage-collection target and selected Pebble v2 for fresh databases.
RPC and keys need a hard boundary
IPC is enabled by default and exposes all supported APIs locally. HTTP and WebSocket endpoints are disabled until requested and expose a narrower default set. That conservative start is appropriate. The project's security guide says its APIs are not built to resist hostile clients or large public traffic. Resource exhaustion can make the node fall behind, and unsafe namespaces can create signing risk.
Do not solve remote access by binding RPC to every interface and stopping there. The guide recommends network restrictions plus a proxy, filtering, rate limits, logging, TLS, and monitoring when an endpoint must serve outside clients. Browser tabs can also reach local services, so a localhost bind is not a complete defense against every misuse. Expose only the namespaces an application needs.
Key custody deserves a separate design. Geth has an encrypted keystore, but the documentation recommends Clef as an external signer so transaction approval and private keys can be separated from the node. Backups must include the right keystore and password material. A lost password cannot be recovered, and a stolen unencrypted key hands control to the attacker. Node uptime and fund custody should not share one casual runbook.
What happened when we ran it
We cloned commit 02b73d4 into a fresh unprivileged golang:1.24-bookworm container with three CPUs, 8 GB of RAM, and no secrets. The repository held 40,964 files, about 508,366 lines of source, and occupied 3,048.2 MB. It included a Dockerfile, a tests directory, and three CI workflow files.
Installation succeeded in 64 seconds and installed 310 packages. The build completed successfully in 160 seconds. The tests ran for 726 seconds but exited with status 1: 11 passed and 2 failed out of 13. The tail ended in github.com/ethereum/go-ethereum/triedb/pathdb after 360.179 seconds. It showed a chainFreezer.freeze goroutine sitting in a select, created while the raw database opened.
The log establishes where the run stopped, not why. We will not turn a goroutine dump into a diagnosis. The failure matters because this was a clean Debian container and the measured test command did not pass at that exact commit. It does not tell us whether a production node will sync correctly, and this run did not attempt a chain sync or an RPC load test.
Health and release posture
The last repository push was August 25, 2026. The latest release, version 1.17.5, arrived July 27 and carried protocol work for the Amsterdam fork alongside database, networking, RPC, tracing, and Engine API fixes. GitHub reported 420 open issues and pull requests combined; a separate issue-only search returned 198. Current reports include test-consensus differences and several mismatches between documented and observed RPC behavior.
That activity points to an actively maintained client with a large surface, not a finished appliance. Ethereum forks force continuous protocol work, and storage or RPC changes can affect operator procedures. Pin releases, read notes before upgrading, keep a rollback path for binaries and configuration, and test database changes on a copy where practical.
Geth remains an easy client to shortlist because documentation, tooling, binaries, images, and protocol work are all present. The harder question is whether your team wants to own an Ethereum node at all. If reliable RPC is the only goal and infrastructure ownership has little value, a managed provider may be cheaper. If sovereignty, verification, private access, or client diversity matters, Geth is worth the operational cost.