Run a Celestia light node on the Mocha testnet

This guide gets you a Celestia light node on Mocha: the binary installed and checksum-verified, a node store initialised against the right chain, a systemd service that survives a reboot, and three independent checks that tell you whether the node is actually sampling data rather than merely running.

It is the smallest node on this site. Celestia's published figure for a light node is 500 MB of memory, one core and 20 GB of disk — a five-dollar server, and about twenty minutes of typing. If you have wanted to run something and been put off by the price of a validator box, this is the one to start with.

Read the next paragraph before you install anything, because it is the single thing most likely to waste your afternoon.

Hardware requirements

Celestia publishes sizing for a light node, so almost nothing here is our estimate. The one number we chose is the price.

Source: hardware requirements, read 2026-09-02.

One number on that page will alarm you if you meet it out of context: the same table lists an archival light node at 7 TiB. That is a different node — one that keeps every header ever produced, sized against a one-year maximum-throughput window. The default light node prunes, and 20 GB is its figure. This guide runs the default.

Step 1: Choose your hardware

Two honest options, and for once both of them are cheap.

Path A: rent a VPS

A rented server gives you a static IP, real bandwidth, and a machine that stays online when your laptop closes. At this size it costs about the same as a sandwich.

We priced the spec above at the four providers this site has referral relationships with, on 2026-09-02, reading each provider's own live pricing page. The working is in our sourcing note in the repository, docs/research/celestia-node-commands-2026-09.md.

The honest pick is Vultr at $5.00 a month. We earn a commission if you use that link, so here is exactly what the commission did and did not decide: Vultr is both the cheapest plan that clears the spec and the one with no commitment attached, and it would win this comparison if we earned nothing from it. We earn from the other three as well; they are linked above anyway so you can check the rejection yourself.

Three things worth knowing before you click, none of them in our interest:

• The cheapest tier at two providers does not clear the disk line. Vultr sells 1 vCPU with 10 GB for $2.50/mo (IPv6-only) or $3.50/mo, and DigitalOcean sells 512 MiB with 10 GiB for $4.00/mo. Celestia's figure is 20 GB, so those plans are out. We would rather tell you that than quote a price you cannot use.
• Contabo gives you four times the machine for about a dollar more, but the headline is a 24-month price. Their page states it plainly: the figure is "for the first 24 months". If you want a box that also does other things, that is a genuinely good trade. For a testnet that may close, prepaying two years is not. Check the contract-term selector at checkout before you pay.
• Vultr and DigitalOcean have no annual term at all, and here that is the point rather than an oversight. A testnet ends when it ends, and being able to stop paying the same day is worth more than a discount.

Path B: use hardware you already own

This is the first guide on this site where "use what you have" is not a consolation prize. Celestia officially supports linux/arm64 and ships an ARM64 build, and 500 MB of memory with one core is inside a small single-board computer, an old laptop, or a spare corner of a machine that already does something else.

The tradeoffs are the usual ones. A home connection drops, and a node that keeps falling out of sync is worse than no node — though a light node recovers from a gap far more gracefully than a validator does, because it is not signing anything and nobody slashes it. The machine has to stay powered.

You do not need to forward any ports to get a light node syncing: it dials out to the network's bootstrap peers. If you run a firewall, allow 2121 in and out, which is the port Celestia's own documentation lists as required for peer-to-peer traffic on every node type. The node's RPC listens on 26658 and binds to localhost; leave it there.

Step 2: Check the machine, and check the network

Run these on the machine that will host the node, before downloading anything.

First, which architecture you are on. The answer decides which file you download in Step 3:

$uname -m

x86_64

x86_64 means you want the Linux_x86_64 build. aarch64 or arm64 means you want the Linux_arm64 one. Unlike most guides on this site, neither answer is a dead end here.

Now confirm the machine is big enough. You need about 500 MB of memory free and at least 20 GB on the filesystem that will hold the node store:

$nproc$free -m$df -h $HOME

Install the handful of tools the rest of this guide uses. Celestia's environment setup page lists a longer set, but most of it is toolchain for building from source, which we are not doing:

$sudo apt update$sudo apt install -y curl tar jq

Finally, check the network is actually alive before you spend anything. This asks a public Mocha consensus node which chain it is on. The answer is the whole reason this guide exists:

$curl -s https://rpc-mocha.pops.one/status | jq -r '.result.node_info.network'

mocha-5

If that says mocha-5, you are looking at the current testnet. If it ever says mocha-4, you are looking at a node that has not migrated — the old chain was scheduled for shutdown on 2026-09-01 and every endpoint the project lists had moved by the time we checked. And if you want to see how far along the chain is:

$curl -s https://rpc-mocha.pops.one/status | jq -r '.result.sync_info.latest_block_height'

Mocha-5 started again from height 1, so this number is small compared with what you may have seen for Celestia before. That is expected, and Step 4 explains why it matters to you.

Step 3: Install celestia-node

Pin the version. Do not install "latest".

The version this guide was written against is v0.32.1-mocha, published 2026-09-01. Celestia's own Mocha page and install page both still name v0.31.6-mocha, which was superseded the same day those pages were last updated. Either of those two works on mocha-5; the mainnet build does not.

Download the release archive and the checksums file that ships beside it. If you are on ARM, replace Linux_x86_64 with Linux_arm64 in the first line:

$cd $HOME$curl -sSLO https://github.com/celestiaorg/celestia-node/releases/download/v0.32.1-mocha/celestia-node_Linux_x86_64.tar.gz$curl -sSLO https://github.com/celestiaorg/celestia-node/releases/download/v0.32.1-mocha/checksums.txt

Verify the download before you unpack it. This is not ceremony: you are about to put a binary on your PATH and run it as a service.

$sha256sum --ignore-missing --check checksums.txt

celestia-node_Linux_x86_64.tar.gz: OK

Anything other than OK means stop. Delete the file and download it again; do not unpack it to "have a look".

Unpack it and put the binary where the system can find it. The archive contains a single executable called celestia:

$tar -xzf celestia-node_Linux_x86_64.tar.gz$sudo install -m 0755 celestia /usr/local/bin/celestia

Confirm the binary runs and reports the version you meant to install:

$celestia version

The output carries the semantic version, the commit hash, the build date and the Go version. The line to read is the semantic version: it must say v0.32.1-mocha. If it says v0.31.4 or anything without -mocha on the end, you have the mainnet build and the rest of this guide will not work — go back to the download step.

Celestia does publish a script installer, and it takes a version flag (-- -v v0.32.1-mocha) that pins correctly. We use the download above instead for two reasons: piping a remote script into a shell is a habit worth not building, and the version flag is exactly the part a beginner is most likely to leave off.

Step 4: Initialise the node store

This creates the node's data directory, its configuration and its key, all in one command. The --p2p.network mocha flag is what makes it a Mocha node:

$celestia light init --p2p.network mocha

That directory name is worth looking at, because it is the clearest evidence you will get that you are on the right chain. The mocha-5 on the end is the chain ID the binary resolved mocha to. A build that resolved it to mocha-4 would have made a directory ending -mocha-4, and that is your signal to go back to Step 3.

$ls -d $HOME/.celestia-light-mocha-5

If that prints a path, the store is where it should be. If it says no such file or directory, list what you actually have with ls -d $HOME/.celestia-light* and read the suffix: no suffix at all means a mainnet store, and -mocha-4 means the retired chain.

Back up the keys directory inside that store now, before it holds anything you care about. It contains your node's identity and its account key. Copying it somewhere off the machine takes a few seconds today and is impossible to do retroactively.

That account key is this node's identity on a testnet, not a place to hold funds — Mocha's tokens carry no real value, so there is nothing at stake in it yet. A hardware wallet becomes worth the cost once you are holding something that does:

Step 5: Run the node as a service

Celestia's quickstart starts the node in the foreground. This guide goes straight to a service instead, because a foreground node dies with your SSH session and you will want it running when you are not watching. The command is the same either way — it is the ExecStart line below — and the FAQ shows the foreground form if you would rather watch it start once.

The node connects to a consensus endpoint for state, and does its data availability sampling peer-to-peer against the network's bootstrap nodes. The endpoint below is the free shared one Celestia's own Mocha quickstart uses; it has no service guarantee, which is fine for a testnet light node. The Mocha page also lists rpc-mocha.pops.one as a community consensus endpoint on the same gRPC port if you would rather not depend on a single provider.

Save the service definition. The command below is Celestia's own systemd recipe with two flags added that their published version omits — --p2p.network mocha and --core.tls. Without the first, the service starts a mainnet node against a different store than the one you just initialised:

$sudo tee <<EOF >/dev/null /etc/systemd/system/celestia-lightd.service$[Unit]$Description=celestia-lightd light node$After=network-online.target$$[Service]$User=$(id -un)$ExecStart=$(which celestia) light start --core.ip public-endpoint.celestia-mocha.quiknode.pro --core.port 9090 --core.tls --p2p.network mocha$Restart=on-failure$RestartSec=3$$[Install]$WantedBy=multi-user.target$EOF

Read the file back before you enable it. The two lines to check are User, which must be the account whose home directory holds the store from Step 4, and ExecStart, which must end with --p2p.network mocha. User is filled in by id -un rather than by $USER, because $USER is set by login shells and is empty in a non-login one — which writes User= with nothing after it, and silently gives you a service running as root against a store in someone else's home directory:

$cat /etc/systemd/system/celestia-lightd.service

Enable and start it:

$sudo systemctl daemon-reload$sudo systemctl enable celestia-lightd$sudo systemctl start celestia-lightd

Verify your node

"The service started" and "the node works" are different claims. These three checks answer different questions, and each one has a bad answer worth recognising.

1. The service is up, and stays up. Run this, wait a minute, run it again:

$systemctl is-active celestia-lightd

active

Anything other than active means it never started. If it alternates between active and activating, it is restart-looping — Restart=on-failure will hide that from you unless you look at the logs.

2. It is following the chain. This asks your own node, through its local RPC, how its header sync is going:

$celestia header sync-state

You are looking for a height that climbs between runs and reaches the network head. A height that stays flat means the node is not making progress — check that it has peers, below, before assuming the chain is at fault. Compare it against the public endpoint's height from Step 2; the two should converge.

3. It is actually sampling, which is the whole job. A light node that syncs headers but never samples is not doing data availability sampling at all:

$celestia das sampling-stats

The interesting fields are the sampled height and the count of failed or in-progress workers. A sampled height that tracks the synced height means the node is doing what it exists to do. A sampled height stuck far behind a climbing sync height means it is fetching headers but cannot get shares from peers, which usually means a connectivity problem rather than a Celestia problem.

If any of those look wrong, check the node has peers at all:

$celestia p2p peers

An empty list means the node reached none of the network's bootstrap nodes. That is a firewall or an outbound-connectivity problem nine times out of ten.

Common errors

The failures a beginner actually hits, with the literal text each one produces.

node: store is not initialized — you ran a command against a store that does not exist. Either Step 4 has not been done, or it was done for a different network and you are asking about this one. Check which directories exist under your home: a .celestia-light with no suffix is a mainnet store and is not the one you want.

node: store is in use — something is already running against that store. This is almost always the systemd service, and it means you are trying to start a second node by hand. Stop the service first, or use the CLI commands from the Verify section, which talk to the running node instead of starting a new one.

cant access the auth token: token/node-store flag was not specified: no opened Node Store found (no node is running) — you ran celestia header sync-state or a similar command while no node was running. The CLI finds the node by looking for a running one, and it found none. Start the service and try again. If the node is running, you are running the command as a different user than the service does, and the CLI cannot see into that user's store.

Error: nodebuilder/share: interval must be positive — the configuration file predates the binary you just installed. Celestia documents the fix as a config merge rather than a delete: run celestia light config-update --p2p.network mocha, check that any values you customised survived, then start the node again.

PLEASE FILE A BUG REPORT: headers given to the heightSub are in the wrong order — despite the wording, this usually is not a bug in the software. It means the data directory holds headers from a different instance of the network than the one you are now running against, which is exactly what happens if you first started this node while it was still resolving to mocha-4. Celestia's documented recovery is to remove the store for that network and initialise it again; because that is a delete, it is described in Maintenance rather than printed here as something to paste.

header: syncing in progress — not an error. You asked the node for something it has not reached yet. Wait, and check the sampling stats from the Verify section to confirm it is moving.

Maintenance

Weekly, and it is a short list — this is a small node with little to go wrong.

Check the service is up and the sampling height is still climbing. The three commands in the Verify section are the whole routine.

Read the logs in the bounded form. The following form is useful when you are watching a problem happen, but it runs until you stop it:

$sudo journalctl -u celestia-lightd.service -n 50 --no-pager

Watch the disk. 20 GB is the published figure for a pruning light node, and the sampling window is 7 days with headers pruned at 14, so usage should settle rather than grow forever. If it does not settle, that is worth investigating before it fills the volume:

$df -h $HOME

Upgrades are download, verify, replace, restart — the same four commands from Step 3, then sudo systemctl restart celestia-lightd. Two cautions. First, check the release you are moving to is a -mocha tag; the trap from Step 3 applies to every upgrade, not just the first install. Second, Celestia documents that upgrading across v0.31.3 requires running celestia light config-update --p2p.network mocha after replacing the binary and before starting the node.

Back up the keys directory in the node store before any upgrade. It holds the node identity and the account key, and neither is recoverable.

There is a documented way to wipe the node's data and start sampling again from scratch — celestia light unsafe-reset-store --p2p.network mocha. It is the right answer to the wrong-network header error above. It is deliberately not printed as a step in this guide, because it destroys the store it is aimed at and there is no version of that command that is safe to paste without knowing why you are running it.

FAQ

Do I get rewarded for running this? No, and unusually for this kind of question, the project says so itself rather than leaving it ambiguous. Celestia's Mocha testnet page states, beside the faucet: "Using this faucet does not entitle you to any airdrop or other distribution of mainnet Celestia tokens." That is their wording, on their own page, read 2026-09-02. There is no points programme, no reward claim and no incentive statement anywhere in the operator documentation that we could find, so there is nothing for us to report. If that ever changes, it goes in this guide with Celestia's own URL beside it, and not before.

What is the difference between mocha-4 and mocha-5? They are different chains, not two versions of one. Mocha-5 is a hardspoon: account balances were copied at a fixed mocha-4 height and everything else — the validator set, governance history, IBC channels, the transaction history — was left behind, and the new chain restarted from height 1. Blobs posted to mocha-4 are not retrievable on mocha-5. For someone running a light node today the practical consequence is simply that mocha-5 is the one that exists, and the binary you install has to know that.

How do I know my binary is on the right chain? Look at the node store directory name. The binary derives it from the chain ID it resolved, so a correct install produces ~/.celestia-light-mocha-5. We checked this from the other direction too: the genesis hash compiled into celestia-node v0.32.1-mocha is byte-for-byte the hash of live mocha-5 block 1. The working is in our research note.

Can I post data with this node? Yes — a light node can submit and retrieve blobs, which is the main reason to run one beyond verifying the chain. You need testnet tokens first. Ask the running node for its address:

$celestia state account-address

Then use one of the faucets Celestia lists on its Mocha page: a web faucet, or a Discord command in their #mocha-faucet channel, limited to 10 tokens per week per address. We have not used either, so the guide takes you to the door and no further.

Will a Raspberry Pi or another ARM board work? The architecture will. Celestia officially supports linux/arm64 and ships an ARM64 build, so unlike most guides on this site the answer is not an automatic no. Check with uname -m and download the matching archive. What we cannot tell you is whether a specific board's storage is fast enough, because we have not run it.

Can I run it in the foreground instead of as a service? Yes, and it is worth doing once to watch it start. This is Celestia's own Mocha quickstart command, verbatim. Stop it with Ctrl-C when you have seen enough:

$celestia light start --core.ip public-endpoint.celestia-mocha.quiknode.pro --core.port 9090 --core.tls --p2p.network mocha

It is not in the numbered steps because it never exits on its own, and a step that never finishes is a bad instruction for someone following along.

Can I make the first sync faster? Yes, by telling the node to trust a recent block instead of sampling from genesis. That adds a trust assumption — you are trusting whoever gave you the height and hash — so it is a choice rather than a default. Get a matched pair from a public endpoint:

$curl -s https://rpc-mocha.pops.one/block | jq -r '.result.block.header.height, .result.block_id.hash'

Put the first value in SyncFromHeight and the second in SyncFromHash in ~/.celestia-light-mocha-5/config.toml, with no 0x prefix on the hash, then restart the service. Use the command above rather than the one on Celestia's advanced page: theirs reads last_block_id.hash, which is the hash of the block before the height it prints beside it. We checked that against the live chain; the working is in our research note.

Why does the sidebar say 500 MB when the docs also say 7 TiB? Because those are two different node types on one page. The 7 TiB figure is an archival light node, which keeps every header ever produced. The default light node prunes — a 7-day sampling window and 14-day header retention — and 20 GB is its published figure. This guide runs the default.

Why is this guide marked pending? Because nobody has run these commands end to end and captured the output. That badge is cleared by a verification harness, never by an author who thinks the commands look right. Every command here is traced to a first-party source in our research note, and three of them are corrections to commands Celestia's own documentation publishes in a form that does not work: the pinned install, the systemd unit, and the trusted-hash pair above. Traced is not the same as tested.