# How to run a Celestia light node on a VPS

> Run a Celestia light node on Mainnet Beta with celestia-node on Ubuntu. Install the binary, start the node, get its node ID and add a systemd unit.

Celestia is a data availability network. A **light node** does not store the chain. It downloads block headers and performs **data availability sampling**: it fetches small random pieces of each block to check that the full data was published. Light nodes can also submit and read blobs, which makes them useful for rollup developers. This guide sets up a light node on Celestia Mainnet Beta following the official documentation.

## What you need

- **A small VPS.** The official requirements for a light node are 500 MB RAM, a single core and 20 GB of SSD. On DataPasa the **VPS-2** plan (1 vCPU, 2 GB RAM, 32 GB NVMe) covers this with headroom. More node recommendations are on the [crypto node VPS page](https://datapasa.com/en/crypto-node-vps).
- **Ubuntu 24.04** with root SSH access, see [how to connect via SSH](https://datapasa.com/wiki/server-management/connect-via-ssh).
- **A consensus node gRPC endpoint.** The docs use a public QuickNode endpoint in their examples, and that is what this guide uses.

The server can be paid with USDT, BTC and other coins through [crypto VPS hosting](https://datapasa.com/en/crypto-vps).

> **Mainnet Beta is still experimental.** Celestia calls its mainnet "Mainnet Beta". It is live and stable, but the docs warn about occasional instability, and node upgrades are coordinated with operators. Follow the network announcements if you run a node long term.

## Step 1. Install dependencies

```bash
apt update && apt upgrade -y
apt install -y curl tar wget jq
```

## Step 2. Install celestia-node

Celestia provides an installer script that downloads the pre-built binary from GitHub and checks its SHA-256 checksum. Open the [Mainnet Beta network page](https://docs.celestia.org/operate/networks/mainnet-beta/) and note the recommended **celestia-node** version, then pass it to the script:

```bash
VERSION=v0.33.2
bash -c "$(curl -sL https://docs.celestia.org/celestia-node.sh)" -- -v $VERSION
```

Pinning the version matters: without `-v` the script takes the latest GitHub release, which is not always the version meant for Mainnet Beta.

The script asks where to put the binary. Choose **System bin directory (/usr/local/bin)**. Check the result:

```bash
celestia version
```

## Step 3. Create a user and initialize the node

Run the node under its own user rather than root:

```bash
useradd --create-home --shell /bin/bash celestia
sudo -iu celestia
```

As the `celestia` user, initialize a light node store. Mainnet Beta is the default network, so no network flag is needed:

```bash
celestia light init
```

This creates the node store in `~/.celestia-light` with `config.toml`, a `data` directory and a `keys` directory, and generates a key for the node. The output shows the key name and address along with a mnemonic phrase. **Write the mnemonic down and keep it offline.** Anyone with it controls the TIA on that address.

## Step 4. Start the node for a first test

Still as the `celestia` user, start the light node against the public consensus endpoint:

```bash
celestia light start \
  --core.ip public-endpoint.celestia-mainnet.quiknode.pro \
  --core.port 9090 --core.tls --p2p.network celestia
```

You will see logs as the node syncs headers and starts sampling. When it runs without errors, stop it with Ctrl+C and type `exit` to return to root.

If you use UFW, open the P2P port. The Celestia docs list port 2121 over TCP and UDP for peer connections:

```bash
ufw allow 2121/tcp
ufw allow 2121/udp
```

The node RPC on port `26658` listens on localhost only. Keep it that way.

## Step 5. Run the node with systemd

Create `/etc/systemd/system/celestia-lightd.service`. It follows the unit from the official docs with the user and endpoint filled in:

```ini
[Unit]
Description=celestia-lightd light node
After=network-online.target

[Service]
User=celestia
ExecStart=/usr/local/bin/celestia light start --core.ip public-endpoint.celestia-mainnet.quiknode.pro --core.port 9090 --core.tls --p2p.network celestia
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target
```

Enable and start it, then follow the logs:

```bash
systemctl daemon-reload
systemctl enable --now celestia-lightd
systemctl status celestia-lightd
journalctl -u celestia-lightd.service -f
```

## Step 6. Get your node ID and address

Your node ID is its libp2p peer ID. With the node running, switch to the `celestia` user and ask the node:

```bash
sudo -iu celestia
celestia p2p info
```

The `id` field in the output is your node ID. Other useful commands:

```bash
celestia state account-address
celestia state balance
```

`account-address` shows the `celestia1...` address of the node key. You only need TIA on it if you want to submit blobs. Sampling and verifying data availability work with an empty balance.

## Back up the node identity

The `keys` directory in `~/.celestia-light` holds both the node identity and the account key. Copy it somewhere safe. If you move to another server, restore the directory there **before** the first start and the node keeps the same ID. To export the account key in encrypted form, the docs describe the separate `cel-key` utility.

## Using your own consensus endpoint

Free public endpoints come without guarantees. For blob submission in production, the Celestia docs recommend a paid RPC provider. If your provider requires an access token, pass it with `--core.xtoken.path`, pointing to a directory that contains an `xtoken.json` file:

```json
{
  "x-token": "YOUR_SECRET_TOKEN"
}
```

Keep this file readable only by the `celestia` user with `chmod 600`.

## Keep the node up to date

When a new Mainnet Beta version is announced, stop the service, run the installer again with the new version, and start the service. The docs note that some upgrades need a config migration, for example with `celestia light config-update --p2p.network celestia`, so read the release notes each time.

A light node only keeps recent data: the sampling window is 7 days and headers are pruned after 14 days, so disk usage stays small over time. Keep your DataPasa balance positive, since a suspended server stops sampling and is deleted after 24 hours without a top up.

## Summary

You installed a pinned `celestia-node` version, initialized a Mainnet Beta light node under its own user, ran it with systemd and found its node ID. The node now samples every new block and gives you a trust minimized way to read and post data on Celestia.