Kener: a SvelteKit status page you run yourself

What Kener actually solves, and for whom

A status page answers one question for your users: is the thing down, and if so, when will it be back? Kener's README frames the project as a lightweight alternative to the heavy commercial platforms rather than a replacement for them: it is "not here to replace heavyweights like Datadog or Atlassian" but to give you a good-looking status page with minimal effort. That sentence sets the audience. It is for a team that runs a handful of services, already has Docker in its stack, and wants to publish uptime and incidents under its own domain without buying a monitoring suite.

The feature list in package.json is broader than a static page: real-time monitoring, uptime tracking, incident management and dashboards. The repository also carries migrations/, seeds/ and a knexfile.ts, which tells you the project persists its state in a real database rather than a flat config file. If your need stops at a hand-written HTML page with a green dot, Kener is more machinery than you need. If you want per-monitor history and incidents, the database and scheduler are the point.

SvelteKit plus Redis: how the pieces fit together

Two processes carry the design. The first is the SvelteKit application itself, built with Node.js and served on port 3000. The second is Redis, which docker-compose.yml describes as "required for BullMQ queues, caching, and scheduler". BullMQ is a Redis-backed job queue, so the recurring checks that produce uptime data are jobs, not in-process timers. That has a practical consequence: if Redis is unreachable, the application may still render pages while the checks stop running, and a status page that silently stops checking is worse than one that is down.

Storage is layered. The compose file comments show the default as SQLite, with DATABASE_URL examples for sqlite, postgresql and mysql. The Dockerfile installs sqlite, sqlite-dev and tzdata in both the Alpine and Debian builder stages, which matches the SQLite-first default. A single container with a mounted /app/database volume is therefore a complete deployment, and Postgres or MySQL is an opt-in for teams that already operate one.

The codebase is TypeScript on SvelteKit, with separate build steps for the SvelteKit output and the server (scripts/build-sveltekit.js and scripts/build-server.js). Nothing in the repository suggests a plugin system or external agent; monitors are configured inside the application and executed by the queue workers.

Installing Kener with Docker Compose and adding a monitor

The README calls Docker the recommended path. Clone the repository, then bring up the compose file, which starts Redis alongside Kener. The README warns in a callout that you must set a strong KENER_SECRET_KEY and point ORIGIN at your public URL before the first run.

git clone https://github.com/rajnandan1/kener.git
cd kener
docker compose up -d

After the containers start, the README says to open http://localhost:3000. If the page loads and the Redis container reports healthy, the application and its queue are both up.

The compose file carries the same two variables with placeholder values, and the comment next to the secret suggests generating one with openssl. ORIGIN is described there as the public URL and as required for CSRF protection, which is why a mismatch between the URL you open and the value you set produces failures rather than a cosmetic warning.

environment:
  KENER_SECRET_KEY: replace_me_with_a_random_string
  ORIGIN: http://localhost:3000
  REDIS_URL: redis://redis:6379

If you prefer not to clone the repository, the README gives a single-container form that pulls the published image, mounts a local database directory and points REDIS_URL at a Redis you run yourself.

mkdir -p database
docker run -d \
  --name kener \
  -p 3000:3000 \
  -v "$(pwd)/database:/app/database" \
  -e "KENER_SECRET_KEY=replace_with_a_random_string" \
  -e "ORIGIN=http://localhost:3000" \
  -e "REDIS_URL=redis://host.docker.internal:6379" \
  docker.io/rajnandan1/kener:latest

The README does not walk through creating your first monitor, so treat the dashboard itself as the reference: once you are past the setup screen, monitors are the objects the scheduler checks and the page reports on.

Running Kener under a subpath such as /status

Many teams cannot take the root of a domain, so Kener publishes dedicated subpath images and a KENER_BASE_PATH variable. The README lists latest-status and latest-status-alpine on both Docker Hub and GHCR, and the subpath run command adds KENER_BASE_PATH=/status.

docker run -d \
  --name kener-status \
  -p 3000:3000 \
  -v "$(pwd)/database:/app/database" \
  -e "KENER_SECRET_KEY=replace_with_a_random_string" \
  -e "ORIGIN=http://localhost:3000" \
  -e "KENER_BASE_PATH=/status" \
  -e "REDIS_URL=redis://host.docker.internal:6379" \
  docker.io/rajnandan1/kener:latest-status

The note under that block is the part people get wrong: in subpath mode ORIGIN stays the site origin, http://localhost:3000, and does not include /status. That is consistent with ORIGIN being used for CSRF checks rather than for building asset URLs. There is also a docker-compose.status.yml in the repository for the same scenario.

Where Kener stops being the right tool

Redis is not optional. The compose file calls it required, and the standalone run command expects a REDIS_URL. If your platform gives you a single container with no sidecar and no managed Redis, Kener is a poor fit until you add one, and the status page will not check anything without it.

The secret and origin requirements are unforgiving on first boot. Both the README and the compose comments repeat that KENER_SECRET_KEY must be strong and ORIGIN must be the public URL, and the failure mode when ORIGIN is wrong is described in the compose file as CSRF protection rejecting requests. A related search phrase, "Kener cross site POST form submissions are forbidden", points at the same mechanism: the application validates the origin of form posts, so a reverse proxy that rewrites the host or terminates TLS under a different name can break the admin UI even though the public page renders.

Finally, Kener is a status page, not an alerting platform. The README positions it against Datadog and Atlassian by saying it does not try to replace them. If you need on-call escalation, log correlation or tracing, this project is one small piece of that stack and you will still be shopping for the rest.

Kener compared with Uptime Kuma and Gatus

The most common comparison is Uptime Kuma, and it is a real fork in the road. Uptime Kuma is a self-hosted uptime monitor first, with a status page attached; Kener is a status page first, with monitoring attached. Both run in Docker and both need persistent storage, but Kener's docker-compose.yml pulls in Redis for its BullMQ queues while Uptime Kuma's typical deployment does not. If your only goal is to be paged when a service drops, Uptime Kuma is the more direct tool. If your goal is a public page with incident history, Kener's defaults are closer to that job.

Gatus sits at the configuration-file end of the spectrum: checks are described declaratively and the emphasis is on the check engine. Kener's monitors live in the application database, which is friendlier for non-engineers editing incidents but less friendly for reviewing monitor definitions in a pull request.

Openstatus and OneUptime appear in the same searches. Both are separate projects with their own deployment models, and nothing in this repository describes their internals, so the honest summary is that they are alternatives in the same category rather than drop-in replacements. The choice between them and Kener comes down to whether you want the whole stack managed for you or assembled from containers you operate.

Maintenance, upgrades and what MIT means here

Kener is not archived, and its most recent push was on 2026-09-13, with releases v4.1.5 on 2026-09-06, v4.1.4 on 2026-09-04 and v4.1.3 on 2026-08-31. That is a tight release cadence over a single month, and the package version matches the newest tag at 4.1.5. The practical upgrade cost is low if you run the published image: pull the new tag and restart, keeping the database volume mounted.

There is one wrinkle worth planning for. The repository has a migrations/ directory and a migrate script that runs knex migrate:latest through vite-node, so schema changes are expected between versions. The README does not document rollback, and the repository gives no downgrade procedure. Before upgrading a production instance, take a copy of the database file or dump, because going back to an older image after a migration is not described.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are kept. That is a permissive licence, but it says nothing about the images you deploy: the Docker Hub and GHCR images are published by the project, and you should confirm the terms you rely on for any third-party services you connect, such as Redis or an email provider. Nothing here is legal advice; read the LICENSE file in the repository.

Editorial conclusion

Kener fits small and mid-sized teams that already run Docker and Redis and want a branded status page they host themselves, and the Docker Compose quick start is the shortest path in. It is the wrong pick if you need a managed service with an SLA or if you cannot run Redis and a persistent volume for the database. Before adopting it, verify three things against your own environment: that the default SQLite file on the mounted volume survives your backup routine, that ORIGIN matches the public URL exactly so CSRF checks pass, and that the scheduler queue in Redis is covered by your restart policy.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. rajnandan1/kener on GitHub
4. README
5. Releases