Deploying a full Ethereum node (Geth/Lighthouse) for RPC access

Deploying an Ethereum node: where startup breaks

A full Ethereum node is two processes that must stay in step: the execution layer and the consensus layer.

Most failures when starting a node are not about hardware but about layer desynchronization: the consensus client lags, the node is formally running, but serves state that is hours out of date.

Until network node synchronization is complete, the access point responds with incorrect data, while the logs look normal.

Ethereum node deployment breaks in three more places. Storage: the chain grows constantly, free space runs out overnight, the process crashes and no longer comes back up if auto-restart is not configured as a separate rule.

Network link: initial synchronization on a narrow channel takes not hours but weeks, and all that time the full Ethereum node is useless.

The process itself: a crashed container without restart and without notification lives silently — the service keeps sending requests into the void and receives no response.

The cost is the same in all cases. A wallet or indexing service serves users state from the past, operations are rejected based on stale data, and the on-call engineer learns about it from users themselves, not from monitoring.

Below we break down how this is addressed — from storage sizing and channel selection to automatic node recovery and layer divergence control.

What changes after moving to your own node

A public RPC provider keeps your load within shared quotas: at peak requests, a rate limit comes back instead of data, and terms change along with the intermediary's plan.

With Infura and similar services, this is noticeable in the separation of methods into access tiers — tracing and archive slices are not available on all plans. Your own network node removes the external circuit: your hardware and channel throughput determine the quota.

Request response time becomes predictable — the node sits next to the application and responds from its own database without joining someone else's queue.

The share of successful requests rises from 97–98% to 99.9%, and the long tail of slow responses that causes the application to time out calls goes away.

The class of failures changes most of all. An entire category disappears: intermediary unavailability, its outages, changing plan terms.

Failures of your own circuit remain — desynchronization, storage overflow, client updates — and they are addressed with your own tools: lag monitoring, a backup public provider as a fallback path, auto-restart.

Network access availability stops depending on a third party, but operational work appears: monitor synchronization of execution and consensus clients, keep current branches, leave storage headroom. How this is deployed and what the work includes — below.

Node operating modes and methods of network access

Node operating mode is a choice between data completeness, disk volume, and time to first RPC response. A full node performs full synchronization and stores the current network state: this is enough for reading balances, sending transactions, and parsing recent contract events.

An archive node stores state at every block height — without it, you cannot build historical queries and analytics for the entire lifetime of the network.

A light client and a public intermediary cover the remaining scenarios: the former verifies block headers and does not store state, while the latter removes operations entirely but adds dependence on someone else's availability and limits. Below are the characteristics by which the modes differ in practice.

The modes are compatible with each other.

It is convenient to keep a public intermediary as a fallback channel while your own node catches up with the network, and switching from full to archive is a matter of moving the state directory or re-syncing from saved data, not rewriting integrations.

How we deploy a node: engineering work stages

A full node is a service with strict requirements for disk and network channel, not a single launch command. Our work order is fixed: first we calculate load and resources, then design placement, and only then launch clients.

This way synchronization does not stretch over weeks, and RPC access does not degrade under the first spike of requests.

1. Infrastructure and requirements audit. We clarify whether an archive or pruned node is needed, how many concurrent requests are expected, and which calls are most frequent. We check this against disk type, memory capacity, and channel headroom.
2. Node placement scheme. We distribute clients, chain state, and cache across separate volumes and separate data from the system partition. We lock down the network scheme: what is exposed externally and what is available only internally.
3. Deployment and synchronization. We bring up the execution and consensus clients, choose the synchronization mode for the task, and monitor reaching the current block height.
4. Configuration and isolation. Processes run under a separate user and with limits; the public request interface is protected by a proxy with keys and rate limiting. A version update does not bring the service down.
5. Load testing. We run a request profile close to production and look at response time at peak. Separately, we test recovery from a state snapshot and re-entry into the network.
6. Handover to operations. We hand over access, monitoring dashboards for key metrics, an update procedure, and a recovery instruction. For the first period, we stay in touch on incidents.

Configurations, schemes, and procedures that remain with you

We deliver not only a working node but also a complete set of artifacts that your team can use to maintain, replicate, and restore it without our involvement. Everything lives in your repository with edit history, so a configuration change rolls back as predictably as code.

• Node configuration files — execution client and consensus client parameters with comments: cache and connection limits, log size and rotation, default values separate from overrides for your site.
• Network and storage scheme — placement of nodes across sites, which ports are open and why, where data physically resides, how disk redundancy is arranged, and what happens if one site fails.
• Access policies and keys — who accesses the RPC endpoint and from which addresses, rate and request volume limits, and the procedure for storing, issuing, and rotating keys.
• Monitoring settings — a set of metrics and alerts: lag behind the network, number of connections to other nodes, disk utilization, response latency; trigger thresholds and on-call notification channels.
• Recovery procedure — step-by-step order for bringing up a node from scratch and from backup, post-start checks, and target time to return to service.
• Update and rollback procedure — when and how clients are updated, what checks are performed before switching traffic, and how to return to the previous set on failure.

We write the artifacts for your engineers: without references to our infrastructure and with explicit points where your decisions are needed.

Case study: moving from an intermediary to your own node

An analytics service for the Ethereum network worked through an external access provider.

At peak loads, up to 8% of requests ended in error, reading contract state took several seconds, and provider limits cut off background tasks — index recalculation queued up and did not finish by the start of the workday.

We moved the service to its own full node: execution client Geth and consensus client Lighthouse behind a common load balancer, with a buffer of frequently requested data.

The switch was staged — first shadow traffic, then reads, and only then writes and subscriptions to new blocks, so rollback to the previous scheme took minutes, not hours.

Metrics before and after

A separate workstream was storage capacity: the state registry grows linearly, so we enabled pruning of outdated states, moved data to a separate fast disk, and configured free space alerts.

A second node in another availability zone takes traffic during client updates, and the block lag metric shows divergence from the network before a user notices it.

The node is running but responds with errors: what we check

If the container is up but the RPC endpoint responds with errors, the cause is almost never the launch itself. We look at four independent layers: synchronization with the Ethereum network, host resources, logs, and the channel to the client — from most common to least common.

Lag behind network state is visible from the difference in the latest block height compared with public explorers. If the node catches up and then falls back again, it lacks peers or the disk cannot keep up with writes.

A separate case is snapshot synchronization: formally it is running but does not complete, and the node serves stale data.

Resource shortage does not manifest immediately: memory hits the ceiling, file descriptors run out with a large number of connections, and an overflowing log eats disk faster than rotation triggers.

This is the most frequently missed cause — logs grow, space runs out, and the node goes down at night without an explicit error in monitoring.

Channel-side restrictions give a different picture: the node itself is healthy, but the client receives rejections and timeouts. We check with a direct request from the host, then through the proxy and from outside — the boundary of the problem is found in a single pass.

Node health check is not "the process is alive" but a set of measurements: block height, number of peers, response time for a typical request, free space, and log rotation status. Error diagnostics relies on these metrics, not on cycling through hypotheses.

Technical doubts: answering common questions

Before starting, the customer's engineers check roughly the same things: whether storage is sufficient in speed and volume, what happens when lagging behind the network, whether archive mode is needed, and how applications will gain access without exposing the node externally. We record these answers in the design documentation before deployment.

How does the service behave during a failure?

The node runs as a system service with auto-restart and recovery from the last consistent state point — data is not lost, and the network catches up on its own.

We monitor lag by the processed block number: when it crosses the threshold, application traffic goes to the backup node.

Is archive mode mandatory?

It stores state from the beginning of the chain and answers historical queries: balances for past dates, transaction traces. The trade-off is many times greater disk volume and long initial synchronization, so we enable it for a specific product scenario.

How is access from the internal network and migration arranged?

The access point listens on a private interface: applications connect over a secure channel and an allowlist, and key operations are handled on a separate node.

Migration is the data directory, configurations, and launch description; the same set is deployed in another environment and catches up with the network.

Let's discuss the task: what we need from you and what we do

To come back with an estimate and work plan rather than general wording, we need inputs on load and node usage mode. Below is what we clarify on a call: this list takes 20–30 minutes, after which we lock down the deployment scheme and responsibility boundaries.

• Access purpose — an internal endpoint for your services or a public one for external consumers: this determines the load profile and security requirements.
• Load — peak requests per second, share of heavy queries to history and state, number of permanent consumers.
• Data and synchronization — the network, whether an archive node is needed or current state is sufficient; whether we plan snapshot synchronization to shorten initial commissioning.
• Operating conditions — placement (your infrastructure, dedicated servers, or cloud), redundancy, update windows, access, and log storage.
• Post-launch support — monitoring, node updates, response to desynchronization and degradation, backups of configuration and keys.
• Responsibility scope — what we cover and what remains on your side: network, hardware, domain records, perimeter security.

Describe the task in free form — we will come back with an estimate and work plan: deployment scheme, stages, timelines, and the result of each. If data for some points is missing, we will advise how to collect it.