light node v0.22.2-mocha

docker-compose.yml

version: "3.8"

services:
  celestia-node:
    image: ghcr.io/celestiaorg/celestia-node:v0.22.2-mocha
    container_name: celestia-node
    entrypoint: ["/bin/sh", "-c"]
    command: >
      'if [ ! -d "/home/celestia/.celestia-light-mocha-4" ]; then
         echo "Running init...";
         celestia light init --p2p.network mocha;
       fi;
       echo "Starting light node...";
       celestia light start
         --core.ip rpc-mocha.pops.one
         --core.port 9090
         --p2p.network mocha
         --rpc.skip-auth
         --rpc.addr 0.0.0.0'
    volumes:
      - celestia-data:/home/celestia
    networks:
      - celestia-network
    ports:
      - "26658:26658"
    restart: unless-stopped

volumes:
  celestia-data:
    driver: local

networks:
  celestia-network:
    driver: bridge

🧠 AI Summary: Why the Original Docker Compose Setup Failed and How the Fixed Version Works

The original multi-container setup split celestia light init and celestia light start into separate services, relying on a shared volume and depends_on. This caused unreliable behavior because:

• docker-compose doesn’t guarantee that the init container fully completes and flushes data before the start container begins.
• If the start container runs without a valid light node store, the celestia CLI silently defaults to bridge init, writing bridge configs and keys to /home/celestia.
• This results in a polluted volume with both bridge and light state, causing confusion and potential crashes.

✅ The fixed version runs everything in a single container with a shell-script entrypoint, which:

• Checks for .celestia-light-mocha-4 and only runs init if needed
• Performs safety checks on config files
• Patches config.toml before starting the node
• Prevents bridge init fallback by explicitly controlling the CLI flow

It also uses the correct Mocha-specific image (v0.22.2-mocha) and production RPC (rpc-mocha.pops.one), which avoids connection and sync issues.