DailyNotes: a self-hosted planner where the notes are Markdown files

Why a planner was written instead of bought

The About section explains the origin better than any feature list can. The idea came from using a Hobonichi Techo planner every morning to write down what needed doing that day, and then using it to scratch down thoughts as the day went on. The closest thing the author had seen to an app for replacing that system was Noteplan, but the author does not use a Mac or an iOS device and Noteplan is not self-hostable, so the decision was to write one. That origin explains the design choices that follow. The application is deliberately personal, self-hosted and simple, the README says, and the whole project is dedicated to Joe Ipson, the original creator, who passed away in the summer of 2025. The project continues in his memory, and the current maintainer describes the goal as interpreting the features he had in mind before calling it a 1.0 release, together with feature requests from issues he was considering. The primary language is Vue on the front end, the licence is MIT, and the last push was on 2026-05-22.

Markdown with task lists, edited in CodeMirror

The core decision was the storage format. Plain Markdown does not natively support tasks, and the author needed to keep track of to-dos throughout the day, so the app uses GitHub Flavored Markdown with task lists written as - [ ] and - [x], along with tables and code blocks. The editor is CodeMirror rather than a plain textarea, because the author wanted it to feel like an actual text editor, and the README lists syntax highlighting, code folding and keyboard shortcuts as consequences. Fira Code supplies the font ligatures. The editing surface is not just for prose. A task list panel shows the tasks inside the note you are looking at, and you can toggle the status of a task from any date or any note, which is the behaviour that turns a journal into a task tracker. There is also an optional auto-save, so a forgotten keystroke does not lose a paragraph. The README points to a Settings and About section as the place to check the running version.

Search, nested tags and a Kanban board

Organization is the part that decides whether a daily note app is usable after a month. Search is syntax based rather than plain substring, with tag: and project: prefixes plus full text queries. Tags nest, so work/meetings and home/family group notes hierarchically, and a project is a separate notion from a tag. A Kanban board gives the task list a visual form, with drag and drop columns, so you can see what is in progress without opening notes. The README also lists live HTML preview with the shortcuts Cmd+K V for a side by side view and Shift+Cmd+V for full screen, Mermaid diagrams for flowcharts, sequence diagrams and ERDs written directly in a note, and light, dark and system themes. The calendar side is two-way in a sense: a Calendar Feed publishes your notes as ICS so you can subscribe in Google Calendar or Apple Calendar, and external ICS feeds can be shown alongside your daily notes.

Encryption at rest, multi-user and the export promise

The privacy story has three parts. Notes are encrypted at rest with AES, and email addresses are encrypted at rest as well. Multiple users are supported, each with separate encrypted data, and the data stays on your own server, which the README frames as no vendor lock-in with the promise that you can export all your notes as markdown files at any time. The account layer adds two flows that need an email server: password recovery by email with a reset link valid for one hour, and passwordless sign-in through a magic link valid for fifteen minutes. The security table in the README is specific about the protections. Tokens are cryptographically random and SHA-256 hashed, each can only be used once, rate limiting allows three requests per email per hour, and the response is the same whether the email address exists or not, which is the email enumeration prevention. The full list of environment variables behind this is in the compose file.

Deploying with Docker Compose

The README has no install command beyond the compose file, so the deployment path is the compose file itself, and the repository carries a Dockerfile, a Dockerfile.dev, a Dockerfile.single-stage and four compose variants for MySQL, Postgres, development and the xhenxhe setup. The default docker-compose.yml builds the image, maps port 8000 to the host, mounts a ./dailynotes-volume directory at /app/config for the persistent state, and passes the two secrets through the environment.

services:
  server:
    build: .
    ports:
      - 8000:8000
    volumes:
      - ./dailynotes-volume:/app/config
    environment:
      API_SECRET_KEY: CHANGE_THIS_WITH_SECURE_PASSWORD
      DB_ENCRYPTION_KEY: CHANGE_THIS_WITH_SECURE_PASSWORD

Those two key values are placeholders and the first thing you have to change. The commented SMTP block in the same file is what enables the password recovery and magic link flows, and the healthcheck calls the health endpoint on port 8000 with a thirty second interval, a ten second timeout and three retries after a sixty second start period.

The Python stack behind the server

The requirements.txt file is a good map of the backend. The framework is Quart at version 0.20.0, described in the file as an async Flask compatible framework, with quart-cors for cross origin requests, and uvicorn with the standard extra as the ASGI server. The database layer is SQLAlchemy with the asyncio extra at 2.0.36, alembic for migrations and aiosqlite as the async SQLite driver, with optional drivers for PostgreSQL through psycopg2-binary and asyncpg and for MySQL through pymysql and aiomysql. Authentication uses pyjwt for tokens and argon2-cffi for password hashing, and note encryption uses pycryptodome. Mail goes out through aiosmtplib, which is the async SMTP client behind the magic link and reset flows. The Dockerfile builds the Vue client in a node stage and then assembles a Python 3.12 runtime stage that also carries the compiled front end, and the repository has migrations/ plus verify_env.py and verify_data_migrations.py for checking the deployment and the schema.

Where this app does not fit, and the honest caveats

The limits follow from the design. There is no shared workspace, so multi-user support is not the same as collaboration: each account has its own encrypted data, and a team that wants a common task list is not served by this. The dependency on an SMTP server for the password and magic link flows is a real operational cost for a self-hosted app you might otherwise run with no external service at all, and the rate limit of three requests per email per hour is another constraint to plan around. The file format is Markdown, which is excellent for portability and awkward for anything structured, so if you need relational reporting over your notes you will be doing that outside the app. And the project carries the weight of a single person's memory: it was created by one person, continued by another after he died, and the release tags show a naming scheme of dated builds, with 2026.02.23-01 and 2026.02.23-00 the most recent. The alternative approach, and the one worth comparing against, is a plain directory of Markdown files in a git repository with a task plugin, edited in your own editor. You lose the Kanban board, the calendar feed and the search syntax, and you gain no server to run, no encryption layer to configure and no format imposed on you.

Editorial conclusion

Adopt DailyNotes if you want a planner whose data is plain Markdown files you can read, grep and export, and if you are prepared to run the Docker Compose stack and manage its secrets yourself, since the compose file ships with placeholder keys that you must replace. Do not adopt it as a team collaboration tool or as a hosted service, because multi-user support means separate encrypted data per account rather than shared notes, and there is no vendor behind it. Before you deploy, replace API_SECRET_KEY and DB_ENCRYPTION_KEY, decide whether you need SMTP for the magic link and password recovery flows, and confirm that your notes directory stays on a backup you control.

Frequently asked questions

Official sources

1. djedi/DailyNotes on GitHub
2. Issues
3. License: MIT
4. README
5. Releases