Deploy and Host Uptime Kuma-self-hosted on Railway

Uptime Kuma is the open-source alternative to UptimeRobot and Pingdom. Track your API endpoints, websites, and services in real-time without paying per-monitor fees. Self-host on Railway and own your monitoring data completely — no vendor deciding what "unlimited" actually means this month.

About Hosting Uptime Kuma-self-hosted

Here's what per-monitor pricing actually costs you: UptimeRobot's paid plan runs $7-30/month depending on monitor count and check frequency, and Pingdom starts even higher once you need more than a handful of checks. Uptime Kuma self-hosted on Railway runs $3-8/month total, and that number doesn't change whether you're watching 5 endpoints or 200 — Railway bills for compute, not for how many things you're monitoring.

Self-hosting also means your uptime data never touches a third-party server. All monitoring history, incident timestamps, and notification configs live entirely on your own infrastructure. If a service you monitor is confidential — an internal API, a client's staging environment, anything under an NDA — that matters more than it sounds. You're not sending a list of your infrastructure's URLs to someone else's database every 20 seconds.

Teams use Uptime Kuma for three overlapping things: SLA compliance tracking (you need real historical uptime numbers when a client asks, not "it felt pretty reliable"), public status pages (so your users find out about an outage from you, not from a confused support ticket), and instant incident alerts routed to wherever your team actually looks — Slack, Discord, Telegram, email, or a webhook into something custom.

Common Use Cases

• Production API monitoring — Check critical endpoints as often as every 20 seconds, catching a degraded response time before it becomes a full outage your customers notice first.
• Public status pages — A branded, hosted status page that shows real incident history, not a vague "all systems operational" badge nobody trusts.
• SSL certificate expiry alerts — Get notified weeks before a cert expires, not the morning after your site starts throwing browser security warnings.
• Multi-region health checks — Monitor the same endpoint from different vantage points to catch region-specific outages a single-location check would miss.
• SLA uptime reporting — Pull real historical data for compliance audits or client reporting instead of reconstructing it from memory.
• Internal service monitoring — Watch databases, internal APIs, and backend services that a public monitoring SaaS was never meant to see.
• Homelab and side-project monitoring — Know your side project is down before the one person using it tells you.

Dependencies for Uptime Kuma-self-hosted Hosting

Uptime Kuma is a single-container application — no external database to provision, no separate services to wire together. It bundles the Node.js runtime, an embedded database, and the monitoring engine into one Docker image.

Deployment Dependencies

• Docker image: louislam/uptime-kuma:2, pinned rather than :latest (the current major-version line; :latest still points at the older 1.x series as of this writing, so pinning :2 is a deliberate choice, not a fallback)
• Storage: a Railway Volume mounted at /app/data — this is a real gotcha worth knowing: Docker's own VOLUME instruction is not supported by Railway's builder and will hard-fail the build with "docker VOLUME at Line 5 is not supported, use Railway Volumes" — persistence has to go through Railway's own volume system instead
• Port: 3001 internally, mapped automatically to your generated Railway domain
• Memory: 256 MB minimum, 512 MB recommended once you're past roughly 50 active monitors

Implementation Details

On first launch, version 2.4.0+ shows a database-choice screen: Embedded MariaDB (the pre-highlighted, officially recommended default — fully self-contained, no separate database service needed, better concurrent-write performance), external MariaDB/MySQL, or SQLite. This is a practically permanent choice — migrating from SQLite to MariaDB later isn't supported, so it's worth picking deliberately rather than clicking through. After that, you get Uptime Kuma's own "Create your admin account" form — there's no pre-generated login baked into this template, you set your own credentials fresh on first visit.

How Uptime Kuma compares to the alternatives

Vs. UptimeRobot — UptimeRobot's free tier caps you at 50 monitors with 5-minute intervals; paid plans add faster checks and more monitors for a recurring fee that scales with usage. Uptime Kuma has no monitor cap and checks as fast as every 20 seconds on the free, self-hosted version, because there's no "free tier" to upsell from — it's just the software.

Vs. Pingdom — Pingdom is built for larger teams and has real strengths in synthetic transaction monitoring, but the pricing reflects that. For straightforward uptime and API health checks, Uptime Kuma covers the same core need without the enterprise price tag.

Vs. Better Uptime / Better Stack — Better Uptime's incident management and on-call scheduling are genuinely more polished for larger teams. Uptime Kuma trades some of that polish for zero recurring cost and full data ownership — the right tradeoff depends on whether you need the extra incident-management workflow or just reliable monitoring and alerts.

Getting Started

After deploying, open your Railway domain and you'll land on the database-choice screen described above — Embedded MariaDB is the right call for most people. Create your admin account, then click "Add New Monitor" to set up your first check: pick a monitor type (HTTP(s), TCP port, ping, DNS, or push-based), enter the target, and set a check interval. Sixty seconds is a reasonable default for most services; drop to 20 seconds for anything genuinely critical.

From there, add a notification channel under Settings → Notifications — Slack, Discord, Telegram, email, and generic webhooks are all supported out of the box. Set up at least one notification channel before you actually need it; a monitor that goes red with nobody watching the dashboard defeats the whole point of monitoring in the first place.

If you want a public status page, create one under the Status Pages tab and pick which monitors to expose; incidents you post there show up automatically for anyone watching. Most teams keep a handful of monitors private (internal APIs, staging environments) while surfacing the customer-facing ones on a branded status page — Uptime Kuma supports both existing on the same instance without extra configuration.

Is this overkill for a single side project? Maybe — a free hosted tier is less setup for one URL. It earns its keep once you're managing more than a handful of things, want a status page without someone else's branding, or don't want your infrastructure list living in a third party's database.

Why Deploy Uptime Kuma-self-hosted 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 Uptime Kuma-self-hosted 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.

Frequently Asked Questions

How many monitors can I run?

There's no hard limit built into the software. Practical limits come from your Railway compute allocation — the default 512 MB is comfortable for 50+ monitors checked every minute; heavier setups just need more RAM.

Do I need a separate database?

No, unless you choose external MariaDB/MySQL on the first-run screen. The recommended Embedded MariaDB option runs entirely inside the same container — no second Railway service required.

Can I migrate from SQLite to MariaDB later?

No — this isn't officially supported. It's worth choosing Embedded MariaDB on first run if you're not certain, since it's the harder option to switch away from after the fact, not the easier one to switch into.

What happens if I lose the volume?

You lose all monitor history, configuration, and your admin account, since everything lives in /app/data. Railway Volumes persist across redeploys and restarts on their own, so this only matters if the volume itself is deleted.

Does this support multiple team members?

Yes — Uptime Kuma has its own user accounts you can create after the first admin login, though it doesn't have granular role-based permissions the way some paid tools do.

What notification channels are supported?

Dozens, including Slack, Discord, Telegram, Microsoft Teams, email (SMTP), SMS via third-party providers, and generic webhooks for anything custom.

Is Uptime Kuma actively maintained?

Yes — it's one of the more actively developed self-hosted monitoring tools, with the 2.x line adding real architectural changes (the database-choice screen, performance work on the embedded database) rather than just cosmetic updates.

How much does this cost to run on Railway?

Budget $3-8/month for typical usage. Cost scales gradually with check frequency and monitor count, not per-monitor the way commercial tools bill.

System Requirements for Self-Hosting Uptime Kuma

Minimum viable setup: 1 shared vCPU, 256 MB RAM, and a few hundred MB of storage for the database and logs — this template's defaults comfortably cover that. If you're running 100+ monitors at sub-minute intervals, bump RAM to 1 GB and keep an eye on Railway's usage dashboard; the embedded database is efficient, but check frequency multiplied by monitor count is what actually drives resource usage, not the software's baseline footprint.