> ## Documentation Index
> Fetch the complete documentation index at: https://docs.novacula.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Tron

> java-tron — networks, ports, resource defaults, and config.conf overrides

A Tron node runs a single `java-tron` process. On the first deploy, the node seeds from a recent community snapshot to cut sync time.

To deploy one, open **Deploy Node**, pick an executor that supports Tron, then choose the network, client (`java-tron`), and version. The wizard offers exactly what your executor declares.

## Networks and resources

| Network   | CPU      | RAM    | Disk     |
| --------- | -------- | ------ | -------- |
| `mainnet` | 16 cores | 32 GiB | 4500 GiB |
| `nile`    | 8 cores  | 16 GiB | 300 GiB  |

`nile` is Tron's public testnet. Defaults are pre-filled in the deploy wizard; lower them with caution.

## Ports

| Name    | Port    | Notes                      |
| ------- | ------- | -------------------------- |
| gRPC    | `50051` | Wallet / fullnode gRPC API |
| HTTP    | `8090`  | Wallet / fullnode HTTP API |
| P2P     | `18888` | Peer-to-peer               |
| Metrics | `9527`  | Prometheus exporter        |

Ports are managed for you and aren't user-overridable.

## Node type

Tron offers a single **Full** node type. It keeps complete block and transaction history and, on first deploy, seeds from a compressed snapshot rather than syncing from genesis (see [Snapshot bootstrap](#snapshot-bootstrap)).

## Config overrides

Tron config keys are edited the same way as any node — see [Edit configuration](/docs/nodes/edit-configuration). Settings that control networking, ports, and the data directory are managed and rejected if you try to set them. The keys you can override are:

| Key                                         | Type    | Purpose                             |
| ------------------------------------------- | ------- | ----------------------------------- |
| `node.maxConnections`                       | number  | Maximum peer connections            |
| `node.minConnections`                       | number  | Minimum peer connections            |
| `node.minActiveConnections`                 | number  | Minimum active outbound connections |
| `node.maxConnectionsWithSameIp`             | number  | Per-IP connection cap               |
| `node.maxTransactionPendingSize`            | number  | Pending-transaction queue size      |
| `node.pendingTransactionTimeout`            | number  | Pending-transaction timeout (ms)    |
| `node.dbCache.maxOpenFiles`                 | number  | Max open LevelDB files              |
| `node.dbCache.writeBufferSize`              | number  | LevelDB write buffer size           |
| `node.fullNodeAllowShieldedTransactionArgs` | boolean | Allow shielded-transaction APIs     |
| `block.maintenanceTimeInterval`             | number  | Maintenance interval (ms)           |
| `block.proposalExpireTime`                  | number  | Proposal expiry (ms)                |

The rest of the node config stays intact; your overrides are merged on top.

## Snapshot bootstrap

On the first deploy, the node seeds from a recent compressed snapshot on a pinned mirror instead of syncing block-by-block from genesis, which cuts sync time sharply. If the data directory already holds a synced database, the snapshot step is skipped.

## Metrics

Block height, peer count, and last-block age are surfaced in the node view — see [Node monitoring](/docs/nodes/monitoring).

java-tron exposes no sync-progress ratio, so Novacula judges sync from **head freshness** instead: while the node's latest block is older than the freshness threshold, it reports **Syncing**, and it flips to **Running** only once the head catches up to the network tip.

## Where to next

* [Deploy a node](/docs/nodes/deploy-a-node)
* [Edit configuration](/docs/nodes/edit-configuration)
* [Provision on bare metal](/recipes/provision-on-bare-metal) · [Provision on Kubernetes](/recipes/provision-on-kubernetes)