Running a TON Archive Node in 2026: Hardware, Sync Times, and the Build-vs-Buy Math
Should you run your own TON archive node in 2026, or rent access to one? If you're hitting toncenter's 1 request/second anonymous throttle, or your shared liteserver plan keeps returning error 228 when you cross 50 RPS on the sliding window, self-hosting starts to look tempting. A TON archive node gives you the full chain history, no rate limits, and no third party in your query path. This guide walks through the actual TON node hardware requirements, the ZFS dump restore, realistic sync times, and the honest monthly cost math of build vs buy.
What an archive node actually is
A liteserver is the query interface to a TON full node: clients speak ADNL (a binary protocol, not HTTP) and verify every response against Merkle proofs, so you don't have to trust the server. HTTP APIs like toncenter are just proxies sitting on top of liteservers. A standard full node keeps a rolling window of recent state; an archive node keeps everything back to genesis (May 2021) — all 3.27 billion-plus transactions. If you need historical account states, full transaction traces, or you're indexing DEX activity on STON.fi or DeDust from block one, archive is the tier you need.
TON's own documentation recommends a dedicated liteserver for production workloads. The question is whether that dedicated node should be yours.
The hardware bar
The official archive node requirements are not modest:
- 16-core CPU
- 128 GB RAM
- NVMe with 64,000+ provisioned IOPS — this is the line item that kills most cloud setups
- 16 TB usable on ZFS with lz4 compression (about 20 TB uncompressed, and growing)
- 1 Gbit/s network, with roughly 16 TB/month of traffic
The IOPS requirement is the real filter. TON produces a block roughly every 0.4 seconds with ~800 ms finality across 382 validators, and the node's cell database hammers random reads. General-purpose cloud block storage either can't sustain 64k IOPS or charges brutally for it, which is why almost everyone runs archive nodes on bare metal with local NVMe.
Restoring from the official dump
Syncing five years of history from the network alone is not practical. The supported path is the official archival dump at archival-dump.ton.org, streamed directly into a ZFS dataset:
zfs create -o compression=lz4 data/ton-db
curl -L https://archival-dump.ton.org/dumps/latest.zfs.zst \
| zstd -d \
| zfs recv data/ton-db
No intermediate file, no double disk usage — the compressed stream is decompressed and received in one pass. At 1 Gbit/s the download alone runs multiple days for a multi-terabyte snapshot, and that assumes the dump server and your uplink both sustain line rate the whole time.
Sync stages after restore
Once the dump is in place, bring-up goes through three phases:
- Import and verification. The node validates the restored database. Hours to days depending on disk speed.
- Catch-up sync. The dump is always days or weeks behind tip. At 0.4 s blocks, the node has millions of blocks to chew through. Budget several more days.
- Steady state. The node follows tip and serves liteserver queries.
Realistic end-to-end bring-up: one to two weeks or more. Plan for a restart or two along the way — the first attempt rarely goes clean.
Ongoing operations
The node is not fire-and-forget. Disk grows continuously, so you're capacity-planning ZFS pools quarterly. You track node releases and network config updates (your node reads the global config from ton.org/global.config.json). You monitor sync lag, because a liteserver that falls behind starts serving the same failures you were escaping — "failed to send query to server: not ready", ADNL timeout 652, or the classic stale-server "Cannot get server version and time". And if this node backs production, you need a second one, because a single liteserver restarting during a DB compaction is downtime.
The build-vs-buy math
Here's an honest monthly breakdown for one archive node on rented bare metal:
| Line item | Monthly cost |
|---|---|
| Bare-metal server (16 cores, 128 GB RAM) | $250–350 |
| Local NVMe, 16+ TB at 64k+ IOPS | $200–300 |
| Bandwidth (~16 TB/month) | $50–100 |
| Monitoring, alerting, off-site config backup | $30–50 |
| Ops time (4–6 h/month, blended eng rate) | $300–450 |
| Total | $830–1,250 |
Add the one-time bring-up: one to two engineer-weeks of setup and babysitting before the node serves its first query. Double most of it if you want redundancy.
Compare that to renting. Shared liteserver plans from wallet-infrastructure providers run about $50/month for 10 RPS and $200/month for 50 RPS — but shared means shared, with hard sliding-window caps. A dedicated private archive liteserver lands well under the DIY number: TONNode's top archive tier is $999/month for 400 RPS on a private instance, with lite plans from $20/month and pay-per-request at $0.02/req for archive queries if your load is spiky. Provisioning takes under a minute, versus two weeks of zfs recv and catch-up sync.
When self-hosting still makes sense
Run your own if you need custom node patches, if data-locality or compliance rules force it, or if you're operating at a scale where one node is a rounding error and you already have the ops team. For everyone else — indexers, trading systems, Telegram Mini Apps (there are 1000+ live on TON now), bots watching pending external messages before block inclusion — the math favors renting a private node and spending the two weeks shipping product instead.
If that's the conclusion you're arriving at, TONNode runs private lite and archive liteservers with plans from $20/month, weekly rentals, and pay-per-request pricing, plus mempool streaming, priority broadcast, and an MCP server for AI agents. Nodes provision in under 60 seconds, payable in GRAM or USDT — and the ZFS pool is our problem, not yours.