Overview

Luna is a self-hosted calendar frontend and aggregator: one web app that pulls all of your calendars together into a single view. It speaks CalDAV, plain iCal feeds and the Google Calendar API, so a CalDAV account from your mail provider, a Nextcloud instance and a read-only holiday feed can sit side by side without you opening three tabs. Different accounts are separate sources inside one interface, and Luna keeps its own user management on top.

The second half of the idea is customisation. Themes, fonts and the layout of the calendar grid are all configurable, with a set of built-in colour schemes and a documented theme format for anything that is not included.

What it does

• Multiple calendar protocols — CalDAV accounts, iCal/ICS feeds and Google Calendar, aggregated into one calendar view.
• One place for every account — add sources per user rather than juggling several calendar apps.
• User management — accounts and their sources live in Luna’s own database, so it is a service you host for a household or a small group rather than a single-user toy.
• Deep theming — colour schemes, fonts and calendar appearance are adjustable, with built-in themes and an installation path for additional ones.
• Self-contained deployment — a frontend, a backend and PostgreSQL, defined in a docker-compose.yml that ships in the repository.

Deployment and requirements

Luna is a three-container stack: a Svelte frontend on port 8080, an API backend on port 3000 and PostgreSQL 16. The repository includes a sample docker-compose.yml with the expected environment — PUBLIC_URL for the address users visit, API_URL for the frontend’s link to the backend, and the usual DB_* credentials — plus bind mounts for the database and for Luna’s data directory. There are no first-party Docker images yet: run make in the repository root with Docker and Make installed to build them, and point the compose file at those builds. Community-built images are published on Docker Hub, but they carry no warranty from the author.

The compose file is an example, not a production recipe: it publishes the frontend port directly and uses the placeholder passwords luna/luna for the database, so put it behind a TLS-terminating reverse proxy and change the credentials before it is reachable from anywhere.

Project status

Luna is honest about being unfinished. The author describes it as nearing a usable 1.0.0 with no release date set, and the deployment guide warns to keep frequent backups and to assume the database may have to be recreated on updates while breaking changes are still landing. Recurring-event support and small-screen layouts are named as the notable gaps. Read that warning as literal: it is an ambitious side project by a single developer, suitable for testing and personal use, not for a calendar you cannot afford to rebuild.

No licence file is published in the repository and the project states no licence, so it is not open source in the formal sense — by default the code stays under the author’s copyright with no grant to reuse or redistribute it. Running it for yourself is one thing; depending on it, forking it or shipping it needs the author’s permission first. If an unencumbered licence matters, use one of the alternatives below instead.

Who it is for

People who already self-host their mail or calendars and want a single, good-looking frontend over several CalDAV and ICS sources, and who are comfortable editing a compose file and building images themselves. Anyone who needs a stable, licensed, supported calendar server today should look elsewhere — the CalDAV servers below are mature, and Luna is the view on top rather than a replacement for the storage.

Related tools

• Radicale — a small CalDAV/CardDAV server, MIT-licensed, a solid backend for a frontend like Luna to read from.
• Nextcloud — calendars, contacts and files in one self-hosted suite, with its own CalDAV endpoint and clients.
• Baikal — focused CalDAV/CardDAV server with a web admin, if you want the server side only.