Deploy librenms-template

LibreNMS — the standard open-source network monitoring system (SNMP auto-discovery, continuous polling, alerting, RRD graphs) — deployed on Railway as a 3-service stack (LibreNMS + MariaDB + Redis) with zero manual configuration.

• Official image (librenms/librenms:26.8.2), thin wrapper for Railway
• Auto-configured: database credentials are generated per deploy and shared between services automatically; nothing to type
• Poller + dispatcher in one container: continuous device polling and discovery from the first minute (Railway forbids the upstream shared-volume sidecar, so this template consolidates the topology)
• Persistent storage: RRD graphs, logs, and config live on a /data volume and survive restarts

After Deploying

1. Give the librenms service a moment — the first boot creates the database schema and starts the poller dispatcher (typically 2–5 minutes).
2. Open the public URL and create your admin account (first-access install wizard, two clicks). If you lose access, recreate a user with railway ssh → php /opt/librenms/lnms user:add -n --role admin NEW_USERNAME.
3. Add your first device: Devices → Add Device. Enter an SNMP-reachable hostname/IP and its community string (v2c by default). Guaranteed smoke test: the container's bundled snmpd answers on localhost with community librenmsdocker. Devices that don't answer SNMP (ping-only) can't be monitored from Railway — ICMP is unavailable (see Troubleshooting).
4. Graphs start populating after the first poll (5-minute cycle). Run php validate.php inside the container any time for the built-in health check.

Key Variables (all pre-wired — nothing to set)

Sizing: give the librenms service at least 2 GB of RAM. Network monitoring is memory-hungry; small instances will struggle once you discover more than a handful of devices.

Deploy and Host

Deploy LibreNMS to Railway in one click. The template provisions and wires all three services, runs schema migrations on first boot, and hands you the install wizard to create your admin account — from zero to monitoring in minutes.

About Hosting

Hosting LibreNMS on Railway gives you a fully managed network monitoring station: three services are provisioned — librenms (web UI on port 8000 + SNMP poller + dispatcher, persistent /data volume), mariadb (10.11, LibreNMS requires MariaDB ≥ 10.5, utf8mb4, persistent volume), and redis (sessions/cache). Unlike a manual deploy, the template wires the database credentials by reference (generated fresh per deployment, never hardcoded), enables the LibreNMS dispatcher inside the main container (Railway's one-volume-per-service rule forbids the upstream sidecar), and pre-seeds icmp_check=false because Railway containers cannot use ICMP (no CAP_NET_RAW). Scale by deploying additional instances of this template — each is an independent poller with its own storage.

Why Deploy

• Zero-config bring-up: schema migrations, seeding, app-key generation, and the admin wizard run automatically on first boot.
• Credential hygiene: the MariaDB password is generated per deployment and shared by reference — no secrets in the repo or the template.
• Topology that actually fits Railway: the upstream compose uses a dispatcher sidecar sharing /data, which Railway forbids; this template runs the poller dispatcher inside the main service (SIDECAR_DISPATCHER=1 plus two adapted init scripts so web, snmpd, and cron co-exist with it) — the dispatcher registers in poller_cluster and shows as enabled in php validate.php.
• Persistence built in: RRDs, logs, and config persist across restarts and redeploys.
• Version-pinned: official librenms/librenms:26.8.2, mariadb:10.11, redis:7.2-alpine.

Common Use Cases

• Monitoring servers, switches, routers, firewalls, and SNMP-capable appliances (auto-discovery, CPU/RAM/traffic/interface graphs)
• Availability and latency dashboards with alerting (email/Slack/Telegram/webhooks) for ops teams
• Long-term capacity planning with RRD-backed trend graphs
• A private monitoring station for your Railway projects: add devices on Railway's private network and watch service-level metrics
• Lab/branch-network monitoring without maintaining a dedicated monitoring VM

Dependencies for

The template is self-contained: LibreNMS, MariaDB, and Redis are provisioned together, wired by private networking, and need nothing external.

Deployment Dependencies

• MariaDB 10.11 (mariadb service): LibreNMS requires MariaDB ≥ 10.5; the template sets utf8mb4/utf8mb4_unicode_ci and innodb_file_per_table per upstream recommendations. Password: auto-generated, shared via reference with the app service.
• Redis 7.2 (redis service): session and cache backend, private network only.
• Railway private networking: service hostnames (mariadb.railway.internal, redis.railway.internal) resolve automatically.
• Outbound SNMP/UDP: devices you add must be SNMP-reachable from Railway's network; ICMP (ping) checks are unavailable on Railway because containers run without CAP_NET_RAW — SNMP polling is unaffected.

Troubleshooting

• First deploy looks slow: first boot runs the full schema migration; give it several minutes and check the librenms deploy logs.
• php validate.php shows fping/CAP_NET_RAW failures: expected on Railway (ICMP unavailable); the template pre-sets icmp_check=false so SNMP polling ignores it. Dispatcher/poller-registry notices are informational with this single-container topology; verify polling via a device's "Last Polled" timestamp.
• Device shows down right after adding: wait one poll cycle (≤5 min); confirm the SNMP community and that the device is reachable from Railway (no ICMP-only allowlists).
• OOM / crashes during discovery of many devices: raise the librenms service memory (≥2 GB) and MEMORY_LIMIT.
• Permission errors mentioning /data: the volume is owned by PUID/PGID (1000:1000); don't attach other volumes over the same path.