Manage My Damn Life: a self-hosted CalDAV frontend for VTODO and VEVENT data
Manage My Damn Life (MMDL) is a self-hosted frontend for managing your CalDAV tasks and calendars.
At a glance
- What is it?
- MMDL is a Next.js frontend that talks to CalDAV servers through tsdav and renders tasks as lists, Gantt charts or calendar entries. It is beta software, GPL-3.0, and the README tells you to be careful with production data.
- Who is it for?
- Adopt MMDL if you already run Nextcloud, Radicale or Baikal and want a task-centric interface on top of CalDAV rather than a second copy of your data. Do not adopt it if you need mobile-first use, drag and drop, or a client that is past beta.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap MMDL fills: a task UI on top of someone else's CalDAV server
CalDAV servers store VTODO and VEVENT objects, but the server itself rarely gives you a usable interface for tasks. Nextcloud, Radicale and Baikal all speak the protocol; what they do not all offer is a view built around task fields such as due dates, status, recurrence and subtasks. MMDL is a frontend for exactly that layer. It does not hold your data. It reads and writes CalDAV collections, so the server remains the source of truth and you can keep using other clients against the same account.
The target user is someone who already self-hosts a CalDAV service and wants a desktop-oriented task manager on top of it. The README is explicit that this is a desktop-first project, and it points mobile users at JTX Boards and OpenTasks instead. That single sentence does more to define the audience than the feature list does. If your primary device is a phone, this is not the tool the author is building for you.
How MMDL talks to your server: tsdav, multiple accounts, OAuth
The README states that MMDL uses the tsdav library for CalDAV access, and that because of this it should support all servers tsdav supports. The project has been tested with Nextcloud, Radicale and Baikal. That is the whole compatibility story as published: a protocol library plus three tested servers, with the rest of the CalDAV world left to tsdav's own support matrix. If your server is not in that list, the honest position is that MMDL may work and nobody has said it does.
Authentication has two paths. The standard one is CalDAV account credentials. The second is OAuth, documented in docs/install/Configuration/OAuth.md, and the README notes that Google Calendars is supported as of now, with a setup guide at docs/Feature%20Guide/GoogleCaldav.md. That matters because Google's CalDAV endpoint does not accept a plain password the way a self-hosted Radicale instance does. The application also supports multiple CalDAV accounts and multiple user accounts, which suggests the frontend is designed to sit in front of more than one calendar store at once rather than assuming a single personal server.
On the rendering side, tasks appear as a list, on a Gantt view, or on a calendar. Filters are user-defined, so the views are driven by saved queries rather than fixed tabs. The README describes the layout as "Responsive-ish", with the qualifier doing real work: this is a desktop layout that degrades, not a layout designed for small screens.
Getting it running and the configuration files that matter
The README does not inline installation commands. It routes you to docs/install/index.md, and the OAuth material lives under docs/install/Configuration/. That is the honest starting point: the repository keeps setup instructions in the docs tree rather than in the top-level README, so anyone evaluating MMDL should open those files before assuming a one-command deploy.
What the README does confirm is the shape of the thing. It is a Next.js application in JavaScript, self-hosted, with a homepage at intri.in/manage-my-damn-life/ and a demo recording in docs/pics/. The screenshots referenced are TaskView.png, HomeView.png and GanttView.png under docs/pics/screenshots, which tells you what the three primary surfaces look like before you install anything. Translations are handled through Weblate at hosted.weblate.org/projects/mmdl-manage-my-damn-life/, with a status badge in the README, so the interface is not English-only but the coverage per language is not stated in the material available here.
Because installation details sit in the docs directory and not in the README excerpt, I cannot give you the exact environment variables or config keys from this material. Treat that as a gap to close by reading docs/install/index.md directly. Do not deploy against a live calendar on the strength of the README alone.
Beta status is the first constraint, and the README says so plainly
The README opens with a warning: this project is in beta state, so be careful if you are working with production data. That is not a disclaimer buried in a contributing guide. It is the second paragraph. For a tool whose entire job is writing to your task and calendar collections, that sentence should shape how you evaluate it.
The failure mode is not that MMDL corrupts data on its own. It is that a frontend writing VTODO and VEVENT objects to a shared CalDAV store can produce results you did not intend, and if that store is your real calendar, the blast radius includes every other client synced to it. The sensible evaluation path is a separate CalDAV account or a test collection on your existing server, then a comparison of what MMDL wrote against what another client reads back. The README gives you no rollback story and no migration tooling, so the recovery mechanism is whatever your CalDAV server provides.
A second constraint is the missing feature set. Drag and drop for tasks is listed under planned features, not current ones. Full RFC 5545 field coverage for VTODO and VEVENT is also planned. Customisable views and an external plugin system are on the same list. Anyone who needs drag and drop scheduling today is looking at the wrong release.
Where MMDL is the wrong tool, and what to use instead
If your workflow is phone-first, MMDL is the wrong choice and the README says as much by recommending JTX Boards and OpenTasks for mobile. Those are native mobile clients that talk to CalDAV directly. The difference in approach is not cosmetic: a native client holds a local database and syncs in the background, so it works offline and survives a dropped connection. MMDL is a self-hosted web frontend, which means the server has to be reachable when you want to change a task. That is a real trade-off for anyone who manages tasks on a commute.
The same reasoning applies if you want a task manager that owns its own data. MMDL deliberately does not. It is a view over CalDAV collections you already have. If you would rather have a single application with its own database and its own sync protocol, MMDL adds a moving part (the frontend) without removing the server you still have to run. The value only appears when you already have the CalDAV server and want a better task interface on top of it.
There is also the Gantt view to consider. It is one of three render modes and the README lists it as a feature, but a Gantt chart is a project-planning visualisation. If your tasks are personal reminders with due dates, the list and calendar views are likely doing the work and the Gantt view is extra surface area. Nothing in the material suggests it is required for normal use.
Licence and the cost of keeping a beta frontend current
MMDL is GPL-3.0. If you run it for yourself, that is straightforward. If you modify it and distribute it, or offer it as a network service to others, the GPL-3.0 obligations attach to the modified source. This is not legal advice; read the licence text and, if you plan to redistribute, get proper advice. The practical point for a self-hoster is that GPL-3.0 is a copyleft licence, so MMDL is not the component to fork into a closed product.
Maintenance cost is visible in the release cadence. v0.9.1, v0.9.2 and v0.9.3 landed within roughly a month of each other in mid-2026, which is a fast patch rhythm for a beta project. Fast releases are good for fixes and awkward for operators, because each one is a potential upgrade you have to apply and re-verify against your CalDAV server. There is no long-term support branch mentioned in the material, and no upgrade guide in the README excerpt. Budget for reading release notes before each bump and for testing the CalDAV round trip afterwards.
The dependency you do not control is tsdav. MMDL's compatibility claim rests on that library, so a change in tsdav's server support can change what MMDL can talk to. That is a reason to pin versions rather than track the latest tag blindly, and to keep the tested-server list (Nextcloud, Radicale, Baikal) as your reference point when deciding whether an upgrade is safe for your setup.
Editorial conclusion
Adopt MMDL if you already run Nextcloud, Radicale or Baikal and want a task-centric interface on top of CalDAV rather than a second copy of your data. Do not adopt it if you need mobile-first use, drag and drop, or a client that is past beta. Before pointing it at a real calendar, verify the install path in docs/install/index.md, confirm your server appears in the tsdav compatibility list, and test against a throwaway CalDAV account first, since the README warns about production data.
Community notes