Create Startup Service

Dingo

A Cardano blockchain node written in Go which actively participates in network communications on the Cardano blockchain using the Ouroboros Network Node-to-Node family of mini-protocols.

⚠️ Dingo is a work in progress and is currently under heavy development

---

In this guide, we will walk you through setting up a systemd service. Using a systemd service to run a Dingo Node maximizes the uptime by automatically restarting the Dingo node when the computer reboots. To get started follow the steps below.

✅ This guide assumes a typical Linux setup. Please adjust commands and paths as needed.

⚠️ For this guide we assume you have already completed the Quick Start guide.

---

Step 1 - Move the Dingo Binary and Configuration

We will move the Dingo binary to /usr/local/bin/ and the configuration to /etc/dingo/ so they are accessible system-wide.

Copy the binary:

sudo cp ~/dingo/dingo /usr/local/bin/

✅ You can verify the binary was copied by running which dingo

Create the config directory and copy the configuration:

sudo mkdir -p /etc/dingo
sudo cp ~/dingo/dingo.yaml /etc/dingo/

---

Step 2 - Update Paths in dingo.yaml

Since the service will run as your user but the config is now in /etc/dingo/, we need to make sure the database and socket paths use absolute paths. Run the following to regenerate the config with your $HOME expanded:

sudo bash -c "cat <<EOF > /etc/dingo/dingo.yaml
# Global data directory for both blob and metadata storage plugins.
# Can be overridden with CARDANO_DATABASE_PATH or --data-dir.
databasePath: \"$HOME/dingo/.dingo\"

# Plugins
plugins:
  storage:
    blob:
      provider: \"badger\"
      config:
        # Optional Badger data directory. When unset, databasePath applies.
        dataDir: \"$HOME/dingo/.dingo/badger\"
        blockCacheSize: 0
        compression: false
        gc: true
        indexCacheSize: 0
    metadata:
      provider: \"sqlite\"
      config:
        # Optional SQLite data directory. When unset, databasePath applies.
        dataDir: \"$HOME/dingo/.dingo/metadata.db\"
  mempool:
    provider: \"default\"
    config:
      # `capacity` is an optional override, not a required setting.
      # Default: 1 MiB for Praos mode and normal serve mode, and 25 MiB for Musashi mode.
      # Leave the key commented or omit it to use the mode default.
      # capacity: 1048576
  api:
    blockfrost:
      provider: \"builtin\"
      config:
        port: 3000
    mesh:
      provider: \"builtin\"
      config:
        port: 8080
    utxorpc:
      provider: \"builtin\"
      config:
        port: 9090

# Mithril
mithril:
  aggregatorUrl: \"\"
  cleanupAfterLoad: true
  enabled: true
  verifyCertificates: true

# Network
bindAddr: \"0.0.0.0\"
metricsPort: 12798
debugPort: 0
network: \"preview\"
privateBindAddr: \"127.0.0.1\"
privatePort: 3002
relayPort: 3001
socketPath: \"$HOME/dingo/dingo.socket\"

# Storage
barkBaseUrl: \"\"
barkPort: 0
storageMode: \"core\"
EOF"

📝 Leave debugPort set to 0 unless profiling is required. debugPort controls a separate optional pprof listener and should stay disabled unless profiling is needed.

storageMode: "api"
plugins:
  api:
    blockfrost:
      provider: "builtin"
      config:
        port: 3000
    mesh:
      provider: "builtin"
      config:
        port: 8080
    utxorpc:
      provider: "builtin"
      config:
        port: 9090
midnight:
  authTokenPolicyId: ""

📝 Dingo starts the Blockfrost, Mesh, and UTxO RPC listeners only in API storage mode. Set any listener port to 0 to disable that API.

📝 midnight.authTokenPolicyId only applies in API storage mode with Midnight indexing. Leaving it empty keeps the broader default auth token matching behavior.

💡 Tip: The network setting supports the following values:

# Musashi (Leios) testnet
network: musashi

# Preview testnet
network: preview

# Pre-production testnet
network: preprod

# Mainnet - NOT CURRENTLY RECOMMENDED
network: mainnet

---

You can view and verify our dingo.yaml file by running:

cd /etc/dingo/
sudo nano dingo.yaml

Step 3 - Bootstrap from Mithril (First Run Only)

Before starting the service for the first time, bootstrap the database from a Mithril snapshot:

dingo mithril sync --config /etc/dingo/dingo.yaml

📝 mithril.downloadMaxTransientRetries controls retries for transient bootstrap download failures such as TLS timeouts, HTTP 429 responses, and HTTP 5xx responses. The example uses the default value of 10.

This downloads and loads a snapshot, saving hours of sync time. See Step 4 of the Quick Start guide for details.

📝 You only need to do this once. After the initial bootstrap, the systemd service will keep the node synced.

---

Step 4 - Create dingo.service Unit File

Create the systemd service file. Replace YOUR_USER with your username (echo $USER):

cat <<ENDFILE | sudo tee /etc/systemd/system/dingo.service > /dev/null
[Unit]
Description=Dingo Node
After=network-online.target

[Service]
Type=simple
Restart=on-failure
RestartSec=10
User=YOUR_USER
ExecStart=/usr/local/bin/dingo serve --config /etc/dingo/dingo.yaml
SyslogIdentifier=dingo
TimeoutStopSec=5

[Install]
WantedBy=multi-user.target
ENDFILE

---

We can view and verify our dingo.service file by running:

sudo nano /etc/systemd/system/dingo.service

Step 5 - Enable and Start the Service

Enable the service to start on boot and start it now:

sudo systemctl enable dingo.service
sudo systemctl start dingo.service

---

Step 6 - Check Status

Verify the service is running:

sudo systemctl status dingo.service

To follow the logs in real time:

sudo journalctl -u dingo -f

To see recent logs if there is an error:

sudo journalctl -u dingo -n 50 --no-pager

---

Congratulations! You have successfully set up a systemd service for Dingo.