Deploy and Host Nightingale on Railway

Nightingale (n9e) is an open-source monitoring and alerting platform — what Grafana is to visualization, Nightingale is to alerting. This template deploys the all-in-one Nightingale server with your admin account secured at start-up. It is a community-maintained template and is not affiliated with the Nightingale project.

About Hosting Nightingale

Nightingale's server bundles a web UI, a metrics query and alerting engine, and — in its default configuration — an embedded time-series database and an embedded Redis, backed by SQLite with automatic schema migration. It ships with a well-known default admin (root/root.2020), which on a public URL can be claimed by whoever opens it first, and it keeps its data on local disk.

This template runs Nightingale on Railway as a single self-contained service: the admin is secured at first boot (the default password is replaced with a generated one), the SQLite database and the embedded time-series database are persisted on one volume, and the port and health check are wired. A time-series datasource is auto-registered, so querying and alerting work immediately. It runs from the official image, pinned by digest.

Common Use Cases

A self-hosted monitoring and alerting hub for servers, containers and websites.
A lightweight, all-in-one alternative to assembling Prometheus + Alertmanager + Grafana yourself.
A private metrics store and alerting engine where the data stays in your own infrastructure.

Dependencies for Nightingale Hosting

Nothing external — the database, cache and time-series store are all embedded and persist on a volume.
To collect metrics from a machine, install an agent (e.g. categraf) on it and point it at this deployment.

Deployment Dependencies

Nightingale: https://github.com/ccfos/nightingale (Apache-2.0)
categraf agent (installed on the machines you monitor): https://github.com/flashcatcloud/categraf
Template repository, image and tests: https://github.com/youssefsiam38/nightingale-railway

Implementation Details

Nightingale runs upstream's official n9e image, pinned by digest. The wrapper adds curl for the start-up bootstrap, relocates the SQLite database onto the data volume (the embedded TSDB already writes there), and secures the admin: on first boot it logs in with the default root/root.2020 and changes the password to the generated OWNER_PASSWORD (username stays root) via the profile API, using a mode-600 file so the password never touches a command line. The web UI, REST API and agent metric-push endpoints all share the HTTPS domain; agents push over plain HTTP(S). SQLite (users, dashboards, alert rules) and the embedded time-series database (metrics) both persist on the /app/data volume, and an embedded-tsdb datasource is auto-registered for queries and alerts.

Tested in CI and on a live deployment of this template: the server is healthy, root/root.2020 is secured, the owner logs in while a wrong password is refused, the embedded datasource exists, a metric pushed to the agent endpoint is read back through the datasource, and the admin and metrics survive a redeploy.

After deploying, copy OWNER_PASSWORD from the service's variables and sign in at the app's domain (username root). To collect metrics, install an agent on a machine and point it at the domain.

Why Deploy Nightingale on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Nightingale on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.