Deploy Kener

Deploy and Host Kener on Railway

Kener is an open-source status page and uptime monitor built with SvelteKit and Node.js. It watches the endpoints you depend on — HTTP APIs, TCP ports, DNS records, TLS certificates, SQL databases, gRPC health services and passive heartbeats — and turns the results into a branded public page customers can check when something feels slow. Around that it adds what a status page needs during an outage: incident timelines, maintenance windows, role-based team access, e-mail and webhook alerting, and embeddable badges.

Self-host Kener on Railway and this template gives you the production shape upstream documents, already wired together. The kener service runs the app and its background job runners in one container and is the only service with a public URL. Postgres holds every monitor definition, check result, incident and uploaded image. Redis backs the BullMQ queues that schedule each monitor's cron and fan results out to alerting. Deploy Kener with a username and password and the first admin account is created before the site accepts a request — there is no open signup window on a fresh URL.

Getting Started with Kener on Railway

Set KENER_ADMIN_EMAIL and KENER_ADMIN_PASSWORD when you deploy — Kener's own rule is eight or more characters with an upper case letter, a lower case letter and a digit. When the deploy finishes, the public URL shows a working status page carrying two demo monitors. Click Login, sign in, and you land on Site Configurations, where site name, logo, theme and home-page copy live.

Your first real task is a monitor. Go to Monitors → New Monitor, give it a name and a unique tag, and save. On its page open Configuration, pick a type — HTTP/API for a web service, TCP Port for a database, DNS for a resolver — fill in the target and press Test Monitor to confirm the check reaches it. Then open Page Visibility and tick a page; a monitor on no page never appears publicly. Within a minute the status page shows a green bar and a latency figure, which tells you the scheduler and Redis are working. Incidents → New Incident attaches that monitor, posts updates and marks it resolved; Users invites your team. A custom domain later means attaching it in Railway, updating ORIGIN, and setting the matching Site URL.

About Hosting Kener

A status page must stay up when the thing it reports on does not, so running one inside your own cluster defeats the purpose — and paying per seat for a hosted one is hard to justify for a page most people visit twice a year. Self-hosting Kener away from your production stack is the middle path.

• Monitor types: HTTP/API, TCP port, DNS, SSL expiry, SQL query, gRPC health, Prometheus, GameDig, Docker container, passive heartbeat and manual
• Incidents with per-update states (investigating, identified, monitoring, resolved) and per-service impact levels
• Scheduled maintenance windows that suppress alerts and show on the public page
• Alerting through e-mail, webhooks, Slack and Discord, driven by trigger templates
• Multiple status pages from one instance, each with its own monitors, branding and domain
• Role-based access control with admin, editor and member roles plus custom roles
• Embeddable widgets, SVG status badges, RSS feeds and a full REST API

The Railway topology mirrors the app's own architecture. Kener's job runners are not a separate process — they run inside the same Node server as the web tier — so the app is one service. Postgres is the system of record, uploaded images included, stored as rows rather than files. Redis is not a cache you can drop: the scheduler, the check queue and the alerting fan-out are all BullMQ queues.

Why Deploy Kener on Railway

Railway removes the parts of self-hosting unrelated to status pages:

• Postgres and Redis are provisioned, networked and backed up beside the app
• A TLS public URL is issued immediately; custom domains take one DNS record
• The app reaches its databases over the private network, so neither is exposed
• Redeploys track the source repository, so upgrading is one push
• Usage-based pricing suits a service that idles most of the month

Common Use Cases

• A public status page for a SaaS product, with per-component monitors and an incident feed customers follow by RSS or e-mail
• An internal reliability dashboard tracking API latency, TLS expiry and database reachability in one place
• A maintenance calendar where windows are announced ahead of time and alerts stay quiet
• A lightweight uptime monitor for side projects and homelab services, alerting into Discord or Slack

Dependencies for Kener

• kener — the application, built from the gridalpha/kener-railway repository on top of the published rajnandan1/kener image. Serves the public page, admin panel and REST API, and runs the scheduler and check workers in-process.
• Postgres — ghcr.io/railwayapp-templates/postgres-ssl:18. Stores monitors, check history, incidents, maintenance windows, users, roles, API keys and images.
• Redis — redis:8.2. Holds the BullMQ queues driving scheduling, check execution and alert delivery.

Environment Variables Reference

Deployment Dependencies

• Source repository: github.com/gridalpha/kener-railway
• Upstream project: github.com/rajnandan1/kener (MIT)
• Documentation: kener.ing/docs

Hardware Requirements for Self-Hosting Kener

Self-Hosting Kener with Docker

Upstream publishes an image per release. This runs Kener against an existing Postgres and Redis:

docker run -d --name kener -p 3000:3000 \
  -e KENER_SECRET_KEY="$(openssl rand -base64 32)" \
  -e ORIGIN="https://status.example.com" \
  -e DATABASE_URL="postgresql://kener:secret@postgres:5432/kener" \
  -e REDIS_URL="redis://redis:6379" \
  rajnandan1/kener:latest

To build from source, a Compose file brings up Redis alongside the app:

git clone https://github.com/rajnandan1/kener.git
cd kener
# set KENER_SECRET_KEY and ORIGIN in docker-compose.yml first
docker compose up -d

Omitting DATABASE_URL falls back to SQLite under /app/database, fine on a laptop but needing a mounted volume anywhere else.

Is Kener Free to Self-Host?

Kener is MIT-licensed and free — no paid tier, seat limits, feature gates or licence key. Every monitor type, every status page and the full API are in the open-source build. On Railway you pay only for what the three services consume, which for a typical status page is small.

FAQ

What is Kener? Kener is an open-source status page system. It runs uptime checks against your services, records the results, and publishes them as a branded public page with incident and maintenance communication built in.

What does this Railway template deploy? Three services: kener running the app and its job runners with a public URL, Postgres storing all application data, and Redis running the job queues. The first admin account is created from the variables you supply at deploy time.

Why does Kener need both Postgres and Redis? Postgres is the system of record for monitors, check history, incidents and images. Redis is not optional caching — the scheduler and check execution run on BullMQ queues, so with no Redis connection no check ever runs.

Do Ping monitors work on Railway? No. Containers there are not granted the raw-socket permission ICMP needs, so a Ping monitor always reports the host unreachable. Use a TCP Port, DNS or HTTP/API monitor instead — all work normally.

Can Kener monitor services on my private network? Anything in the same Railway project, yes. Point a TCP Port monitor at .railway.internal with the host type set to IP6 and it checks over the private network, so a database never needs a public endpoint.

How do I set up e-mail notifications for status page subscribers? Set SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS and SMTP_FROM_EMAIL on the kener service, or RESEND_API_KEY and RESEND_SENDER_EMAIL instead. Without one, invitations and notifications are generated but never sent.