Etar

Last reviewed Sep 13, 2026 · 737 words

Etar does not have a server, does not speak CalDAV, and there is nothing to put in Docker. It is an Android calendar app, a fork of the original AOSP Calendar maintained since 2016 under GPL-3.0, and the 2,597 stars belong to that app. The reason it belongs on a self-hosting site anyway is that it is the best front end for a calendar you host yourself: Etar draws events from Android's calendar provider, DAVx5 fills that provider from your CalDAV server, and the result is a Google-free calendar on your phone with a self-hosted server behind it. If the catalogue description read to you like a server, this guide is the correction.

The stack: a CalDAV server, DAVx5, and Etar

Three parts, each replaceable. The server holds the calendars and speaks CalDAV; Nextcloud is the common choice because most self-hosters already run it, and its Calendar app gives you a web UI for free. If you want something a fraction of the size, Xandikos is a single Python process that stores calendars as .ics files in a git repository, and DAVical is the long-running PostgreSQL-backed option for multi-user households. The calendar category page compares those.

DAVx5 is the sync layer. It is on F-Droid free or Google Play for a few euros, and it logs into the CalDAV server, discovers the calendars, and registers them as Android calendar accounts. Sync interval, which calendars to show, and conflict handling are DAVx5 settings, not Etar ones.

Etar is the last piece, and it is deliberately ordinary. It shows whatever calendars Android knows about, so it works equally well with a DAVx5 account, a Nextcloud account, or, if you keep one, a Google account. It has no idea where the events come from, which is the point.

What Etar does better than the stock calendar

The stock Google Calendar app is fine until you remove Google Play Services, at which point it stops syncing anything. Etar has no such dependency; it runs on a de-Googled phone, GrapheneOS or LineageOS included, with nothing missing. Beyond that: month, week, day, and agenda views with a proper Material design; home-screen widgets for the day and the month; a dark theme; per-calendar colours; and an import path for .ics files sent by email or downloaded from a site. It is small, fast, and has not changed its behaviour under you in years, which for a calendar is a compliment.

Notifications are handled by Android's calendar reminder system, so they fire whether Etar is open or not, and they respect the phone's do-not-disturb rules. Recurring events, invitations with attendees, and time zones all work, because that logic lives in the calendar provider Etar inherits rather than in Etar itself.

Where it falls short

Invitations are read-mostly: you can see attendees on an event synced from Nextcloud, and you can accept or decline, but organising a meeting with external attendees and tracking RSVPs is a server feature, and Nextcloud's web UI is where you would do it. Tasks are not calendars; if you want VTODO lists from the same server, add the Tasks app from F-Droid, which DAVx5 also feeds. There is no desktop Etar; on a laptop you use Thunderbird against the same CalDAV server, or the Nextcloud web calendar. And Etar's own development is steady rather than fast: bug fixes and small features, not a roadmap.

None of that is a reason to avoid it, but it clarifies where the work happens. The server decides sharing, permissions, and invitations. DAVx5 decides what syncs and how often. Etar decides how it looks and how you enter things.

What I'd do

Run a CalDAV server you already trust, Nextcloud if you have it and Xandikos if you do not, install DAVx5 from F-Droid, and install Etar as the calendar app. Set DAVx5 to sync every 15 minutes on Wi-Fi and hourly on mobile data, and export a calendar backup from the server, not from the phone. Etar is the right front end for this stack and the Google Calendar alternatives page has the fuller list of server choices to sit behind it. Just do not go looking for its Docker image; it has never had one and never needed one.