Deploying a TON node: where synchronization breaks
When deploying a TON node, it is usually not the installation that breaks, but node synchronization under load. The node starts, catches up with the chain, and reaches the current block—and after a few hours of peak transaction flow, it again begins to lag behind the network.
The causes are mundane: the disk cannot handle the stream of random writes when shard state is actively rewritten, incoming connection limits remain at defaults, and memory goes into swap during block pull-in.
Node downtime at such a moment does not look like a crash, but like a quiet divergence from the network.
While the node lags behind the network, integrations show outdated balances, payout confirmations hang in the queue, and a full node stops being the source of truth for internal services.
For a validator, the price is higher: missed rounds mean falling out of the active set and losing signatures that can no longer be restored retroactively.
The network bottleneck is almost never just one thing. A weak disk, extra connections on the lite-server, and an overgrown cache add up to lag behind the network that grows instead of leveling off on its own.
Below we break down how this is closed—from selecting resources for the node type to synchronization control.
What a dedicated node provides: response, independence, availability
Public entry points to TON are shared by everyone: a provider serves thousands of clients, so it introduces request limits per address, queues calls, and cuts peak spikes.
While the network is calm, node response time looks acceptable, but during activity—mass contract deployment, name auctions, a surge in transfers—the response arrives with a delay, and some requests are rejected due to rate.
For a service that reads balance state, listens for incoming transactions, or collects history, these are missed events and reprocessing.
A dedicated full node keeps the current network state locally and answers requests itself, without an intermediary. The lite-server role gives external clients access points directly to your node: response time is determined by your hardware and channel, not someone else's queue.
Request limits disappear as a category—only your own throughput remains, and peak load passes without losses.
Independence from third-party services here is not an abstraction: their unavailability or changed terms no longer stops your product.
The validator role adds a second effect—participation in network consensus and influence over its parameters instead of observing from the sidelines.
Predictable availability rests on monitoring, not promises.
Our engineers capture synchronization lag, the number of active connections, the share of rejected requests, and response time for a typical sample—degradation is visible before the client feels it, and failover to a backup node is rehearsed in advance.
Node modes: archive, validator, service
Node mode is determined not by a startup flag, but by what the node stores, whom it serves, and how its resource requirements grow.
Archive mode saves state at every block height and answers the query "what was the balance at this block"; validator mode keeps only current state and votes in consensus; service mode serves light clients without storing history.
You cannot change the mode after the fact: an archive node cannot be "caught up" from a validator node; synchronization starts over. That is why the mode is chosen before deployment—for the task, not "just in case."
| Mode | When it fits | Limitations |
|---|---|---|
| Archive node | Audit, analytics, recalculation of historical states, contract debugging | Space for state grows linearly and does not shrink; full synchronization takes days |
| Validator mode | Own validator, delegation, participation in consensus | Stores only current state; downtime results in missed rounds |
| Service mode, lite-server | Wallets, exchanges, bots—frequent requests from light clients | Does not store history and does not vote; depends on an available full node |
How this adds up in practice
Resource requirements add up: an archive node needs the largest fast disk; validator mode is critical about a stable channel and key protection; service mode needs throughput and headroom for connections.
A validator and lite-server are not combined on one machine: peak client requests begin competing for the same resources as voting, and both tasks degrade.
Deployment stages: from audit to handover to support
A TON node is not installing a package and starting a service, but a set of engineering decisions: from choosing the operating mode to the on-call procedure.
If you skip infrastructure audit or load testing, synchronization lag and disk degradation will show up in production, when the node is already considered operational.
That is why we run deployment as a project with fixed stages and an acceptance criterion at each:
- Infrastructure audit. We assess disk headroom and the disk I/O profile, channel stability, and placement across failure zones. This is also where it becomes clear whether the site can handle constant writes.
- Node scheme design. We determine the mode: full node for reading the network, validator for consensus participation, lite-server as the request-serving endpoint. Plus the access, key storage, and monitoring scheme.
- Deployment and synchronization. We bring up the service, set up autostart and updates, bring the node to the current network state, and verify that lag does not grow over time.
- Load testing. We run a profile of real requests, observe behavior under peaks, restart the node, and measure time to return to synchronization.
- Node acceptance. We compare metrics against those agreed in advance: connection stability, synchronization depth, response to disk or network failure.
- Handover to support. We provide accesses, the scheme, on-call instructions, and configured alerts—the customer's team can operate the node without us.
The outcome of the stage is not a running service, but a predictable node with clear behavior under load and failure. Describe the task—we will come back with an estimate and a plan for these steps.
Delivery package: configurations, diagrams, procedures
We deliver the node not as a "black box," but together with a set of artifacts by which it can be raised again, handed over to another team, or audited.
Everything is stored in the customer's repository under version control, not in chats and engineers' personal directories.
- Node configuration — parameters for each profile separately: full node, validator, service node for requests. Every non-obvious value has a comment: what it changes and at what load to touch it.
- Service interaction diagram — how the node is connected to monitoring, proxy, key storage, and external services, with traffic directions and failure points.
- Access policies — who and via which channel gets onto the host, which keys and roles are needed for this, what to do when an engineer leaves or a key is lost.
- Update procedure — the order for removing the node from rotation, updating, checking synchronization, and returning it to operation, with a rollback window to the previous version.
- Recovery procedure — step-by-step bringing up the node from scratch on a new server: from deployment to reaching the current network state, with a time estimate.
- Monitoring and alerts — a set of tracked node health metrics and thresholds at which the on-call engineer receives a signal instead of learning about a failure from users.
- Node documentation — directory map, purpose of services, typical failures, and the procedure for each case.
The kit is designed for an engineer seeing the stand for the first time: it is enough to deploy a copy, make changes, and hand over maintenance further without us.
Case study: how node downtime was reduced and a class of failures was eliminated
At the customer's site, a node in the TON network operated as a single point: full node, validator, and lite-server were on one server without replicas.
Under peak load it lagged behind the chain, light requests did not respond on time, and after a restart synchronization took hours—and all that time the customer's services did not see the current network state.
Before: what the failure looked like
There was no redundancy: the node database and validator keys were on the system disk, and state snapshots were not taken. Diagnostics amounted to reading logs manually, so about forty minutes passed from the first alarm signal to the start of work. A crash led to multi-hour resynchronization and manual data integrity checks.
After: what was changed and what the result was
We separated the roles across dedicated servers, moved state to a dedicated disk, and validator keys to isolated storage with restricted access.
We added a hot standby with automatic failover, regular state snapshots, and a check that looks not only at the live process but also at lag by block height.
Uptime increased from 97% to 99.9%, and the share of successful light requests—from 92% to 99.6%. Recovery time dropped from several hours to minutes: the node comes up from the latest snapshot and catches up only the remainder of the chain.
The class of failures "crashed and fell out of the network for a long time" is closed—a single failure no longer turns into downtime for the customer's service.
How a TON read node differs from a validator
When deploying a TON node, the first thing chosen is the mode: both configurations keep a local copy of the network state, but their tasks are different. A data-read node serves requests—balances, history, message sending, operation of indexers and wallets.
It confirms nothing and does not influence consensus: the node can be restarted or rebuilt from a snapshot, and the network will not notice.
A validator is participation in block confirmation. The node enters the set for a round, must sign its slot and submit the signature on time; a miss is recorded, and systematic misses lead to exclusion from the set and loss of the stake.
Hence a different attitude to stability: downtime here is not "service unavailability" but an event with loss of stake and reputation.
The difference between modes shows in requirements. Reading needs a wide channel, disk capacity for state, and predictable latency—lag of a few seconds is tolerable, and the node catches up with the archive.
A validator needs clock synchronization, 24/7 availability, isolated key storage outside the node disk, and monitoring that catches a slot miss before the network does.
In practice, the modes are separated: the validator works only for signing, while a separate node serves data to applications—requests do not compete for resources, and updating one does not bring down the other.
Responsibility is also different: reading is restored from a snapshot and catches up with the chain, while a missed block-confirmation slot cannot be returned.
Technical doubts: resources, reliability, updates
A node's resources are determined not by hardware but by its operating mode: a full node stores state and serves data to lite-server, a validator holds keys and participates in consensus, and an archive node keeps the entire history.
That is why the question "how much is needed" starts with the roles you cover and only then moves to disk, memory, and channel.
Reliability and network updates are the second half of the topic: a validator failure, lagging synchronization, a planned protocol change. Below are answers to what is most often asked before starting.
How many resources does a node actually need?
Disk is the fastest-growing resource: database state increases constantly, and snapshots and pruning only slow the growth.
Memory is needed with headroom for synchronization peaks, when the node catches up with the network, and the channel—without interruptions: catch-up synchronization is sensitive to connection loss. We separate data and system logs onto different disks so that overflow does not stop the node.
How to get through network updates?
A protocol update is a planned event, but the node must get through it without losing consensus.
The order is: first update one node on a canary circuit, check synchronization and lite-server responses, then roll out the rest one by one without taking the validator quorum out of service. The configuration is fixed, and rollback to the previous build remains available.
What happens when a node fails?
A failure must not go unnoticed: monitoring tracks lag by block height, the number of active connections, and node response time, and alerts reach the on-call engineer before users notice.
Automatic process restart brings the node back, a backup node takes over the load, and state divergence is checked against checkpoints.
Let's discuss the task: we will select a node mode and come back with a plan
The conversation starts with the task, not with a template proposal.
It is enough for us to understand which node mode is needed and what already exists on the customer's side—that is enough to come back with a timeline estimate and deployment plan, not with clarifying questions over three emails.
- Node purpose. Full node for reading network state, validator for participating in block production, or lite-server for external requests—this determines the machine configuration and synchronization mode.
- Load and availability. Expected number of requests, whether a backup node is needed, and what maintenance window is acceptable without service loss.
- Infrastructure. Whether the customer has servers or cloud capacity, and what disk and channel headroom to provision for network growth.
- Access and keys. Who owns the validator keys, how backup is arranged, to whom we grant access, and how we revoke it.
- Work order. We agree on the stages: environment preparation, synchronization, joining the network, monitoring setup, handover.
- Node maintenance. Updates, monitoring of missed rounds, response to desynchronization and disk degradation.
After the discussion, we come back with a plan: placement scheme, timeline by stages, approval points, server requirements, and the metrics by which we will monitor the node.
If only launch is needed—we estimate launch; if the node is going into ongoing operation—we include maintenance right away. Describe the task—we will come back with an estimate and work order.