Run a Node

1 Server Preparation

Requirements

• OS: Debian 13 (Trixie) or Ubuntu 24.04+ recommended
• CPU: 2+ cores
• RAM: 2+ GB (4 GB recommended if building from source)
• Disk: 20+ GB (SSD preferred)
• Network: Public IP address and a domain name

Ports to Open

• 41720 UDP+TCP — P2P communication between nodes (required)
• 80 — HTTP (for Let's Encrypt and redirect to HTTPS)
• 443 — HTTPS (web frontend, API, push gateway)

Install Dependencies

Update your system and install the build tools needed to compile the L2 node from source. If you plan to use Docker only, you can skip the Rust toolchain.

# Update system packages
sudo apt update && sudo apt upgrade -y

# Install build dependencies
sudo apt install -y build-essential pkg-config libssl-dev \
  curl git unzip

# Install Rust (if building from source)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"

# Install Node.js (if deploying web frontend)
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

Create System User and Directories

Run Ogmara under a dedicated system user for security. Never run the node as root.

# Create a system user for Ogmara
sudo useradd -r -m -d /var/lib/ogmara -s /usr/sbin/nologin ogmara

# Create required directories
sudo mkdir -p /var/lib/ogmara/data
sudo mkdir -p /etc/ogmara
sudo mkdir -p /var/log/ogmara

# Set ownership
sudo chown -R ogmara:ogmara /var/lib/ogmara
sudo chown -R ogmara:ogmara /var/log/ogmara

Add Swap Space (for Compilation)

If your server has only 2 GB of RAM, add swap space before compiling Rust projects. The Rust compiler can use significant memory during builds.

# Create a 2 GB swap file
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Make it permanent
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Firewall Setup

Configure UFW to allow only the ports your node needs.

# Install and enable UFW
sudo apt install -y ufw

# Allow SSH (so you don't lock yourself out)
sudo ufw allow OpenSSH

# Allow Ogmara P2P
sudo ufw allow 41720/tcp
sudo ufw allow 41720/udp

# Allow HTTP and HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable the firewall
sudo ufw enable
sudo ufw status

2 Install the L2 Node

The L2 node is the core of your Ogmara deployment. It stores messages, relays them to peers, verifies wallet signatures, and serves the API that clients connect to.

Option A: Docker (Recommended)

Docker is the fastest way to get running. The image is published to Docker Hub under the ogmara/ogmara repository with per-component, per-version tags.

# Pull the v0.46.1 L2 node image (always pin to a specific version
# for reproducible deployments — check
# https://hub.docker.com/r/ogmara/ogmara/tags for the current latest)
docker pull ogmara/ogmara:l2-node-0.46.1

# Create named volumes for persistent data and config
docker volume create ogmara-data
docker volume create ogmara-config

# Run the node. On first start the entrypoint auto-generates a default
# config at /etc/ogmara/ogmara.toml inside the container (since v0.46.1).
# You'll edit it in the next subsection.
docker run -d \
  --name ogmara-l2 \
  --restart unless-stopped \
  -p 41720:41720/tcp \
  -p 41720:41720/udp \
  -p 41721:41721/tcp \
  -v ogmara-data:/data \
  -v ogmara-config:/etc/ogmara \
  ogmara/ogmara:l2-node-0.46.1

Option B: Build from Source

If you prefer to compile the binary yourself, clone the repository and build with Cargo.

# Clone the L2 node repository
git clone https://github.com/Ogmara/l2-node.git
cd l2-node

# Build in release mode
cargo build --release

# Copy binary to system path
sudo cp target/release/ogmara-node /usr/local/bin/
sudo chmod +x /usr/local/bin/ogmara-node

Create a systemd service file so the node starts automatically on boot.

# /etc/systemd/system/ogmara-l2.service
[Unit]
Description=Ogmara L2 Node
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=ogmara
Group=ogmara
ExecStart=/usr/local/bin/ogmara-node --config /etc/ogmara/ogmara.toml
Restart=on-failure
RestartSec=5
LimitNOFILE=65535
WorkingDirectory=/var/lib/ogmara

# Security hardening
ProtectSystem=strict
ReadWritePaths=/var/lib/ogmara/data /var/log/ogmara
ProtectHome=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

# Enable and start the service
sudo systemctl daemon-reload
sudo systemctl enable ogmara-l2
sudo systemctl start ogmara-l2

Configuration

The configuration file lives at /etc/ogmara/ogmara.toml. As of v0.46.1, the Docker container auto-generates a default annotated config on first start (and source builds can use ogmara-node init to do the same). Either way you only need to fill in the four blocks below to get connected.

For Docker — copy the auto-generated config out, edit it, and copy it back:

# Pull the auto-generated default out of the running container
docker cp ogmara-l2:/etc/ogmara/ogmara.toml ./ogmara.toml

# Edit the four blocks shown below (use your favourite editor)
nano ./ogmara.toml

# Push the edited config back and restart
docker cp ./ogmara.toml ogmara-l2:/etc/ogmara/ogmara.toml
docker restart ogmara-l2

For source builds — generate, edit, install:

# Generate a default config (the same default the docker container uses)
ogmara-node init --output /etc/ogmara/ogmara.toml

# Edit it
sudo nano /etc/ogmara/ogmara.toml

Minimum changes needed in the auto-generated config to connect to the network:

# /etc/ogmara/ogmara.toml — minimum changes from the auto-generated default

[api]
# REQUIRED for [anchoring.metadata] auto-derive and for being reachable
# from clients. Set to the public URL where this node's API is served
# (typically via the reverse proxy you configure in Step 6). v0.46.0
# Phase D supports bracketed IPv6: "http://[2001:db8::1]:41721".
public_url = "https://node.yourdomain.com"

[klever]
# Klever mainnet endpoints
node_url = "https://node.mainnet.klever.org"
api_url = "https://api.mainnet.klever.org"

# Ogmara smart contract address on Klever mainnet
contract_address = "klv1qqqqqqqqqqqqqpgq8c9yag9vuc2pe64fwvqsq9e8ul8w5zuglf5qfgh7z3"

# --- Source / systemd install ---

# 1. Stop the node
sudo systemctl stop ogmara-l2

# 2. BACK UP YOUR NODE KEY (critical!)
ogmara-node export-key -o my-node-key.bak

# 3. Edit ogmara.toml — switch Klever URLs and contract address

# 4. Wipe the data directory (path depends on your `[node] data_dir`)
sudo rm -rf /var/lib/ogmara/data

# 5. Start the node
sudo systemctl start ogmara-l2

# 6. Restore your key (keeps the same wallet address)
ogmara-node import-key -i my-node-key.bak
# Then restart to apply the restored key
sudo systemctl restart ogmara-l2

# 1. Back up the key first (out of the data volume)
docker exec ogmara-l2 ogmara-node export-key -o /data/node-key.bak
docker cp ogmara-l2:/data/node-key.bak ./my-node-key.bak

# 2. Stop + remove the container (keeps the volumes intact)
docker stop ogmara-l2
docker rm ogmara-l2

# 3. Wipe ONLY the chain/messages data volume (keeps the config volume
# so you don't have to re-edit it from scratch)
docker volume rm ogmara-data
docker volume create ogmara-data

# 4. Edit your config volume to point at the new network
docker run --rm -v ogmara-config:/etc/ogmara busybox \
  sed -i 's|node.testnet.klever.org|node.mainnet.klever.org|g; \
          s|api.testnet.klever.org|api.mainnet.klever.org|g; \
          s|klv1qqqqqqqqqqqqqpgq0ja2j7xwz843ryfsk9vlz6xzsaak590h6pgq7nwr02|klv1qqqqqqqqqqqqqpgq8c9yag9vuc2pe64fwvqsq9e8ul8w5zuglf5qfgh7z3|g' \
  /etc/ogmara/ogmara.toml
# (Or `docker cp` the file out, edit, copy back — same as the
# Configuration subsection above. The contract address swap shown
# is testnet -> mainnet; reverse for mainnet -> testnet.)

# 5. Recreate the container (same volumes)
docker run -d --name ogmara-l2 --restart unless-stopped \
  -p 41720:41720/tcp -p 41720:41720/udp -p 41721:41721/tcp \
  -v ogmara-data:/data -v ogmara-config:/etc/ogmara \
  ogmara/ogmara:l2-node-0.46.1

# 6. Restore the key
docker cp ./my-node-key.bak ogmara-l2:/data/node-key.bak
docker exec ogmara-l2 ogmara-node import-key -i /data/node-key.bak
docker restart ogmara-l2

Start and Verify

After starting the node, check the logs to confirm it is running correctly.

# Check the service status
sudo systemctl status ogmara-l2

# View logs (for systemd)
sudo journalctl -u ogmara-l2 -f

# View logs (for Docker)
docker logs -f ogmara-l2

You should see log entries indicating:

• The API server is listening on port 41721
• The P2P listener is bound to port 41720
• Peer discovery is running and connecting to bootstrap nodes
• The chain scanner has started monitoring Klever for contract events

# Quick health check
curl http://127.0.0.1:41721/api/v1/health

If you get a valid JSON response, your L2 node is up and running. You now have a working Ogmara node on the network.

# Export your node's private key to a backup file
ogmara-node export-key -o my-node-key.bak

# Store this file securely (USB drive, password manager, etc.)
# NEVER share it or commit it to git

ogmara-node import-key -i my-node-key.bak

Optional Production Features

A bare node connects to the network and serves your users. To participate more fully — help anchor chain state, appear in the network's peer-discovery registry, get paged when something goes wrong — opt into these features in your ogmara.toml. All are off by default; flip them on once you understand the trade-offs.

3 Set Up IPFS

IPFS handles media storage for Ogmara — images, videos, avatars, and file attachments. Without IPFS, your node can still relay text messages, but users connected to it will not be able to upload or view media content.

Install Kubo (IPFS)

Kubo is the reference implementation of IPFS. Download and install the latest version.

# Download Kubo
wget https://dist.ipfs.tech/kubo/v0.33.2/kubo_v0.33.2_linux-amd64.tar.gz
tar -xzf kubo_v0.33.2_linux-amd64.tar.gz
cd kubo
sudo bash install.sh

# Initialize IPFS as the ogmara user
sudo -u ogmara IPFS_PATH=/var/lib/ogmara/.ipfs ipfs init --profile server

# Verify installation
sudo -u ogmara IPFS_PATH=/var/lib/ogmara/.ipfs ipfs version

Configure IPFS

Adjust the IPFS configuration for a server environment. Set a storage limit and configure the gateway.

# Set storage limit (adjust based on your available disk space)
sudo -u ogmara IPFS_PATH=/var/lib/ogmara/.ipfs \
  ipfs config Datastore.StorageMax "10GB"

# Listen on localhost only for the API (security)
sudo -u ogmara IPFS_PATH=/var/lib/ogmara/.ipfs \
  ipfs config Addresses.API "/ip4/127.0.0.1/tcp/5001"

# Configure the gateway to listen on localhost
sudo -u ogmara IPFS_PATH=/var/lib/ogmara/.ipfs \
  ipfs config Addresses.Gateway "/ip4/127.0.0.1/tcp/8080"

Systemd Service for IPFS

# /etc/systemd/system/ipfs.service
[Unit]
Description=IPFS Daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=ogmara
Group=ogmara
Environment=IPFS_PATH=/var/lib/ogmara/.ipfs
ExecStart=/usr/local/bin/ipfs daemon
Restart=on-failure
RestartSec=5
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

# Enable and start IPFS
sudo systemctl daemon-reload
sudo systemctl enable ipfs
sudo systemctl start ipfs

# Verify it is running
sudo systemctl status ipfs
curl -s http://127.0.0.1:5001/api/v0/id | head -c 200

Configure the L2 Node to Use IPFS

Add the IPFS section to your ogmara.toml configuration file.

# In /etc/ogmara/ogmara.toml (auto-generated default already has the
# [ipfs] block; just confirm api_url and gateway_url point at your
# running IPFS daemon, and adjust the limits if needed)

[ipfs]
api_url = "http://127.0.0.1:5001"
gateway_url = "http://127.0.0.1:8080"

# Maximum upload size in MB (default: 50)
max_upload_size_mb = 50

# Optional media handler tuning — defaults are safe for a ~4 GiB-RAM
# VPS. Lower for resource-constrained nodes; raise for high-readership
# deployments. See the annotated example on github for the full list:
# https://github.com/Ogmara/l2-node/blob/main/ogmara.example.toml
# media_cache_total_mb = 256        # Total LRU weight cap
# media_handler_permits = 32        # Concurrent /api/v1/media/:cid handlers
# media_per_ip_permits = 4          # Per-client-IP sub-cap

# Restart the L2 node to pick up the new config
sudo systemctl restart ogmara-l2
# (or for docker) docker restart ogmara-l2

Remote IPFS (Optional)

If you want to run IPFS on a separate server (for example, a machine with more storage), you can connect the L2 node to it securely using a WireGuard VPN tunnel or an SSH tunnel.

# SSH tunnel example: forward local port 5001 to remote IPFS
ssh -N -L 5001:127.0.0.1:5001 user@ipfs-server.example.com

# Then configure ogmara.toml to use 127.0.0.1:5001 as usual

4 Set Up Push Gateway

The push gateway enables mobile push notifications for Android and iOS users connected to your node. Without it, mobile users will only receive messages when the app is open.

Option A: Docker (Recommended)

# Pull the push gateway image
docker pull ogmara/ogmara:push-gateway-latest

# Run the push gateway
docker run -d \
  --name ogmara-push \
  --restart unless-stopped \
  -p 127.0.0.1:41722:41722/tcp \
  -v /etc/ogmara/push-gateway.toml:/etc/ogmara/push-gateway.toml:ro \
  ogmara/ogmara:push-gateway-latest

Option B: Build from Source

# Clone and build
git clone https://github.com/Ogmara/push-gateway.git
cd push-gateway
cargo build --release

# Install the binary
sudo cp target/release/ogmara-push /usr/local/bin/
sudo chmod +x /usr/local/bin/ogmara-push

Generate VAPID Keys

VAPID (Voluntary Application Server Identification) keys are required for web push notifications. Generate a key pair that will identify your server to push services.

# Generate VAPID keys (using the push gateway binary)
ogmara-push generate-vapid-keys

# This outputs a public key and a private key.
# Save both — you will need the public key in client apps
# and the private key in the push gateway config.

Configuration

# /etc/ogmara/push-gateway.toml

[server]
listen_addr = "127.0.0.1:41722"

[vapid]
private_key = "YOUR_VAPID_PRIVATE_KEY"
public_key = "YOUR_VAPID_PUBLIC_KEY"
subject = "mailto:admin@yourdomain.com"

[auth]
# Shared secret between L2 node and push gateway
# Generate with: openssl rand -hex 32
shared_secret = "YOUR_SHARED_SECRET"

Connect L2 Node to Push Gateway

Edit the [push_gateway] block in your L2 node configuration (the auto-generated default ships with enabled = false and empty values).

# In /etc/ogmara/ogmara.toml

[push_gateway]
enabled = true
url = "http://127.0.0.1:41722"
# Loaded from $OGMARA_PUSH_AUTH_TOKEN env var in production
# (preferred over putting the secret in the config file)
auth_token = "YOUR_SHARED_SECRET"

Systemd Service (for Source Build)

# /etc/systemd/system/ogmara-push.service
[Unit]
Description=Ogmara Push Gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=ogmara
Group=ogmara
ExecStart=/usr/local/bin/ogmara-push --config /etc/ogmara/push-gateway.toml
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

# Enable and start
sudo systemctl daemon-reload
sudo systemctl enable ogmara-push
sudo systemctl start ogmara-push

# Restart the L2 node to connect to the push gateway
sudo systemctl restart ogmara-l2

5 Deploy Web Frontend

Deploying the web frontend lets users access Ogmara through a browser on your domain. The web app is a static single-page application (SPA) that connects to your L2 node's API.

Build the Web App

# Clone and build the SDK (shared library used by the web app)
git clone https://github.com/Ogmara/sdk-js.git
cd sdk-js
npm install
npm run build
cd ..

# Clone and build the web frontend
git clone https://github.com/Ogmara/web.git
cd web
npm install

# Link the local SDK
npm link ../sdk-js

# Build for production
npm run build

Deploy to Web Root

Copy the built files to a directory that your web server can serve. The standard location is under /var/www/ogmara/app/.

# Create the web root directory
sudo mkdir -p /var/www/ogmara/app

# Copy the built files
sudo cp -r web/dist/* /var/www/ogmara/app/

# Set correct ownership and permissions
sudo chown -R www-data:www-data /var/www/ogmara
sudo chmod -R 755 /var/www/ogmara

6 Reverse Proxy and SSL

A reverse proxy handles SSL termination, routes requests to the correct backend service, and serves the web frontend. This step shows configuration for both Apache and Nginx — choose whichever you prefer.

SSL Certificate with Let's Encrypt

Install Certbot with the plugin for your web server. Using the web server plugin (instead of --standalone) is important — it lets Certbot obtain and renew certificates while your web server keeps running.

# For Apache:
sudo apt install -y certbot python3-certbot-apache

# For Nginx:
sudo apt install -y certbot python3-certbot-nginx

Obtain a certificate using your web server plugin. This handles the domain verification challenge through your running web server, so there is no need to stop it.

# For Apache (replace with your domain):
sudo certbot --apache -d node.yourdomain.com

# For Nginx (replace with your domain):
sudo certbot --nginx -d node.yourdomain.com

Automatic Certificate Renewal

Let's Encrypt certificates expire every 90 days. Certbot sets up automatic renewal when installed, but the mechanism depends on how it was installed. Verify that renewal is configured and working.

# On Debian/Ubuntu with apt-installed certbot, renewal runs via cron:
cat /etc/cron.d/certbot

# On systems with snap-installed certbot, renewal runs via systemd timer:
sudo systemctl status certbot.timer

# Test that renewal works (dry run — does not actually renew)
sudo certbot renew --dry-run

If neither the cron job nor the systemd timer exists, create a cron job manually.

# Create a cron job that checks for renewal twice daily
echo '0 0,12 * * * root certbot renew --quiet' | sudo tee /etc/cron.d/certbot

After renewal, your web server needs to reload to pick up the new certificate. Add a deploy hook so this happens automatically.

# For Nginx:
sudo sh -c 'printf "#!/bin/sh\nsystemctl reload nginx\n" > /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh'
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

# For Apache:
sudo sh -c 'printf "#!/bin/sh\nsystemctl reload apache2\n" > /etc/letsencrypt/renewal-hooks/deploy/reload-apache.sh'
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-apache.sh

Fixing Certificates Obtained with Standalone

If you already obtained a certificate using --standalone and renewals are failing because port 80 is in use, you can switch the authenticator without re-issuing the certificate.

# Edit the renewal config for the affected domain
sudo nano /etc/letsencrypt/renewal/node.yourdomain.com.conf

# Change this line:
#   authenticator = standalone
# To:
#   authenticator = apache    (or nginx)

# Then test:
sudo certbot renew --dry-run

Nginx Configuration

# /etc/nginx/sites-available/ogmara

upstream ogmara_api {
    server 127.0.0.1:41721;
}

upstream ogmara_push {
    server 127.0.0.1:41722;
}

# Redirect HTTP to HTTPS
server {
    listen 80;
    server_name node.yourdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name node.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/node.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/node.yourdomain.com/privkey.pem;

    # Security headers
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options DENY;
    add_header Referrer-Policy strict-origin-when-cross-origin;

    # L2 Node API
    location /api/ {
        proxy_pass http://ogmara_api;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # WebSocket endpoint
    location /api/v1/ws {
        proxy_pass http://ogmara_api;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_read_timeout 86400;
    }

    # Push Gateway
    location /push/ {
        proxy_pass http://ogmara_push;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Block admin endpoints from public access
    location /admin/ {
        deny all;
        return 403;
    }

    # Web frontend (SPA)
    location /app/ {
        alias /var/www/ogmara/app/;
        try_files $uri $uri/ /app/index.html;
    }

    # Root redirect
    location = / {
        return 302 /app/;
    }
}

# Enable the site and reload
sudo ln -s /etc/nginx/sites-available/ogmara /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Apache Configuration

# /etc/apache2/sites-available/ogmara.conf

<VirtualHost *:80>
    ServerName node.yourdomain.com
    Redirect permanent / https://node.yourdomain.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName node.yourdomain.com

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/node.yourdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/node.yourdomain.com/privkey.pem

    # Security headers
    Header always set X-Content-Type-Options nosniff
    Header always set X-Frame-Options DENY
    Header always set Referrer-Policy strict-origin-when-cross-origin

    # L2 Node API
    ProxyPass /api/ http://127.0.0.1:41721/api/
    ProxyPassReverse /api/ http://127.0.0.1:41721/api/

    # WebSocket
    RewriteEngine On
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteCond %{HTTP:Connection} upgrade [NC]
    RewriteRule ^/api/v1/ws$ ws://127.0.0.1:41721/api/v1/ws [P,L]

    # Push Gateway
    ProxyPass /push/ http://127.0.0.1:41722/push/
    ProxyPassReverse /push/ http://127.0.0.1:41722/push/

    # Block admin endpoints
    <Location /admin/>
        Require all denied
    </Location>

    # Web frontend (SPA)
    Alias /app/ /var/www/ogmara/app/
    <Directory /var/www/ogmara/app/>
        Require all granted
        FallbackResource /app/index.html
    </Directory>

    # Root redirect
    RedirectMatch ^/$ /app/
</VirtualHost>

# Enable required modules and site
sudo a2enmod ssl proxy proxy_http proxy_wstunnel rewrite headers
sudo a2ensite ogmara
sudo apache2ctl configtest
sudo systemctl reload apache2

7 Verify Everything

Run through these checks to confirm each component is working correctly.

Health Checks

# 1. L2 Node — should return JSON with node status
curl -s http://127.0.0.1:41721/api/v1/health

# 2. IPFS — should return peer ID and addresses
curl -s http://127.0.0.1:5001/api/v0/id | python3 -m json.tool

# 3. Push Gateway — should return status
curl -s http://127.0.0.1:41722/health

# 4. Web Frontend — should return the HTML page
curl -s -o /dev/null -w "%{http_code}" https://node.yourdomain.com/app/

# 5. API via reverse proxy — should match direct L2 node response
curl -s https://node.yourdomain.com/api/v1/health

# 6. WebSocket — should upgrade successfully
curl -s -o /dev/null -w "%{http_code}" \
  -H "Upgrade: websocket" \
  -H "Connection: Upgrade" \
  https://node.yourdomain.com/api/v1/ws

Service Status

# Check all services at once
sudo systemctl status ogmara-l2 ipfs ogmara-push nginx

# Or for Docker deployments
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

Expected Resource Usage

Under normal operation with all components running, expect approximately:

• CPU: 5–15% idle, spikes during message bursts or IPFS operations
• RAM: 200–500 MB total across all services
• Disk: Grows with messages and pinned IPFS content; monitor with df -h
• Network: Depends on peer count and message volume; P2P traffic on port 41720

Monitoring Logs

Keep an eye on logs during the first few hours of operation to catch any issues early.

# Follow all Ogmara logs
sudo journalctl -u ogmara-l2 -u ogmara-push -u ipfs -f

# Check for errors only
sudo journalctl -u ogmara-l2 -p err --since "1 hour ago"