An application that writes to a distributed ledger through someone else's node has outsourced its most important dependency to a stranger. Public nodes rate-limit, go offline and change their terms, and a supply-chain record that must be anchored now cannot wait for one to come back. Running your own node is the fix, and the marketplace makes it a package. This post follows a developer deploying an IOTA node on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.
The application belongs to a cold-chain logistics company we will call Frostline Freight, which anchors temperature-log hashes for pharmaceutical shipments to the IOTA Tangle so that customers can verify them independently. The IOTA Node package deploys the IOTA node software on a dedicated Linux node with persistent ledger storage, a public IP with the gossip and API ports, and the node's dashboard and REST API over HTTPS once synchronised.
Why a node of your own
IOTA transactions are feeless, which is why Frostline chose the Tangle for anchoring: tens of thousands of hashes a month cost nothing to record. The catch was access. The application used public nodes, and public nodes protect themselves with rate limits and go away without notice. Twice in a quarter a batch of anchors failed during a shipment window, and the customer-facing verification page showed records as unverified. A full node the company runs is a private, trusted entry point: no rate limit but its own, no third-party terms, and a copy of the ledger to verify against locally.
What the package installs and what the first day looks like
The node is a dedicated Linux container running the IOTA node software with its configuration templates in place, persistent storage for the Tangle database and snapshots, and a public IP with the gossip port open so the node peers with the network and the API port so the application reaches it. The first day is synchronisation: the node downloads a snapshot and catches up to the network, which takes from an hour to several depending on network state and the snapshot used. The package's guidance is to allocate generous cloudlets during sync and let vertical scaling settle afterwards, which the developer does by setting a 32-cloudlet limit (a cloudlet is 128 MiB of RAM plus 400 MHz of CPU) and watching the dashboard's sync status. Once synchronised, the dashboard and REST API are reachable over HTTPS.
Storage, the thing that grows
A ledger database grows, and the package says to plan for tens of gigabytes and monitor it. The developer starts the persistent disk at 100 GB with a disk load alert at 80%, knowing that the platform's storage can be extended from the dashboard without moving anything. The node software's own pruning and snapshot settings control how much history is kept locally; for anchoring, where the application needs recent confirmation and the network holds the history, aggressive pruning is appropriate and the developer configures it. The platform's snapshots of the node are the recovery mechanism if the ledger database is corrupted: restore the snapshot and let the node resync from there.
| Resource | During sync | Steady state | Setting |
|---|---|---|---|
| CPU and RAM (cloudlets) | 20 to 30 | 6 to 10 | Limit 32, vertical scaling |
| Disk | Growing quickly | Growing slowly with pruning | 100 GB, alert at 80%, extend from dashboard |
| Network | High inbound | Steady gossip in and out | Public IP, gossip and API ports |
| Uptime | Not critical | Critical for anchoring windows | Separate host, live migration, load alerts |
Wiring the application, and closing the door
The anchoring service, a Node.js application in the same environment group, talks to the node's REST API over the internal network, never over the public IP. The developer uses the container firewall to allow the API port from the application's addresses only, leaving the gossip port open to the world as the protocol requires and closing everything else. The dashboard is behind the office VPN. The application's retry logic, written for flaky public nodes, is kept, now as a safety net rather than a daily necessity.
Availability for a node that must be there at 06:00
Shipment windows are when anchors must land. The node is a container on its own physical host with the platform's live migration and restoration behind it, and the developer adds two layers of her own: a load alert on CPU and disk forwarded to the team's chat, and an external check that queries the node's health endpoint every minute. For the day a resync is needed, the retry queue in the anchoring service holds records until the node is back, which is the same design that survived the public nodes. A second node in another region is the obvious next step, and the developer's note is that the platform makes it a clone plus a resync.
Cost
Upgrades of the node software follow the platform's usual pattern: snapshot the node, update the software from the package's configuration templates, restart and confirm the dashboard reports the node synchronised. The developer schedules them outside shipment windows and keeps the snapshot until the next successful anchor.
After sync, the node averages about 8 cloudlets an hour, roughly $20 a month before discounts at MassiveGRID's published $0.003372 per cloudlet-hour, plus the 100 GB disk, the public IP and gossip traffic. Frostline's previous "cost" was a free public node and two failed anchoring windows a quarter. MassiveGRID also hosts other distributed-ledger infrastructure; the company's Hedera page covers that side, and the developer notes that the node-hosting pattern here, dedicated container, public IP, persistent ledger disk, alerts, is the same for any of them.
Frequently Asked Questions
How long does initial synchronisation take?
From about an hour to several hours, depending on the network's state and the snapshot the node starts from. Give the node a generous cloudlet limit during sync; vertical scaling reduces the allocation once it settles.
Does the node need to stay online continuously?
For the application to anchor at any moment, yes, and the platform's separate-host placement and restoration cover the node itself. A node that is offline for a while resyncs when it returns; keep a retry queue in the application for anchoring during that window.
Can I run nodes for other ledgers the same way?
The pattern is general: a dedicated Linux container with a public IP, persistent storage for the ledger, the protocol's ports open in the firewall, and alerts on disk and CPU. MassiveGRID's blockchain hosting page covers Hedera and other distributed-ledger options.
Your own door to the Tangle
The IOTA Node package deploys a full IOTA node with persistent ledger storage and a public IP on MassiveGRID PaaS, scaling by the hour through sync and steady state. Per cloudlet-hour, free 14-day trial, no credit card.
IOTA Node on MassiveGRID PaaS