Poznote: a self-hosted PHP notes server you reach through Docker Compose
Powerful note-taking without the hassle.
At a glance
- What is it?
- Poznote is a PHP web application for notes, tasks and wikis, distributed as a multi-arch Docker image plus an MCP companion container. The README covers installation, authentication, Git sync and S3 storage in depth, and says almost nothing about hardware requirements or database choice.
- Who is it for?
- Adopt Poznote if you already run Docker and want a notes, tasks and wiki server on your own hardware, with Git sync or S3 as the documented escape hatches. Skip it if you need a native desktop client with local file storage, or if you cannot run a server at all.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly PHP, 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 Poznote fills between Notion and a folder of Markdown
Poznote is a web application you host yourself. The README positions it as a free, self-hosted, open-source alternative to Notion, Obsidian, Evernote and OneNote, and the repository topics list docker, documentation, free, note-taking, notes, self-hosted, tasks, todolist, webapp and wiki. That combination describes a specific buyer: someone who wants the wiki and task-list surface of a hosted notes product, but wants the data on their own machine. It is written in PHP and released under the MIT licence, which matters because it removes the seat-count question that hosted tools raise. The README does not state a minimum RAM figure, a supported PHP version, or which database the container uses. If those numbers decide your deployment, you will have to read the compose file and the .env.template rather than the README.
Two containers: webserver plus MCP
The install instructions describe pulling and starting two images, the Poznote Webserver and the Poznote MCP. The MCP container is separate from the web application, which is the architectural detail worth noticing: the assistant integration is not baked into the request path of the notes server. The README also documents an AI Assistant and an MCP Server as distinct features alongside a Chrome extension and an Android share target, so Poznote is designed as a central store that other clients write into rather than a single web page. Around that core sit Git Synchronization, S3 Attachment Storage, S3 Backups, Webhooks and an Activity Log. The repository layout is not included in the supplied material, so the internal module structure of the PHP code cannot be described here. What the README does make clear is the direction of data flow for the integrations: notes live in the Poznote instance, and Git, S3 and webhooks are outbound paths from it.
Installing with docker compose pull and up
The README gives the same four-step sequence for Windows, Linux and macOS. Create a directory, fetch the environment template, fetch the compose file, then run two commands. On Linux the commands are: mkdir poznote, cd poznote, curl -o .env https://raw.githubusercontent.com/timothepoznanski/poznote/main/.env.template, curl -o docker-compose.yml https://raw.githubusercontent.com/timothepoznanski/poznote/main/docker-compose.yml, docker compose pull, docker compose up -d. Windows uses the same curl lines from PowerShell plus notepad .env instead of vi .env, and macOS matches Linux. The README does not list the keys inside .env, so the only honest statement is that the template exists at that URL and the compose file reads it. For Kubernetes there is a community chart: helm repo add helmforge https://repo.helmforge.dev, helm repo update, then helm install poznote helmforge/poznote --namespace poznote --create-namespace. Note the attribution in the README: the chart is maintained by the HelmForge community, not by the project author, which is a different support relationship from the Docker image. The official image is multi-arch for linux/amd64 and linux/arm64, and the README says it runs on Docker Desktop, Raspberry Pi and NAS systems.
Authentication, app passwords and the multi-user model
The table of contents lists Authentication, App Passwords, Multi-users and Activity Log as separate features, which suggests roles and per-user credentials are first-class rather than an afterthought. The README does not describe the login mechanism, whether sessions are cookie-based, or how app passwords are scoped. That is a gap worth flagging for anyone exposing the instance to the internet. A live demo is provided at demo.poznote.com with the credentials poznote and poznote, and loading it is the fastest way to see the authentication flow before you commit to a deployment. Treat the demo as a look at the interface, not as a security review. The Activity Log is listed as a feature, but the README does not say what events it records or how long entries are kept.
Git sync, S3 and backups are the real lock-in answer
The strongest part of the README is the data-portability section. Git Synchronization, S3 Attachment Storage, S3 Backups, Backup / Export and Restore / Import all appear as documented features, and the README also lists Offline View and Multiple Instances. For a self-hosted notes tool, this is the difference between a weekend experiment and something you can migrate away from. Git sync in particular means your notes can exist as versioned files in a repository you control, which is closer to the Obsidian model than to a hosted database. The README does not specify the sync direction, the conflict resolution rules, or which Git hosts are supported. If you plan to run Git sync against a busy repository, test the conflict path on the demo or on a throwaway instance before you point it at anything you care about.
Where Poznote is the wrong tool
Poznote is a server. Every install path in the README starts with Docker or Helm, so if you want a notes app that opens a local folder of Markdown files without a running daemon, this is not that. Obsidian is the direct contrast here: it reads and writes plain files on your disk, and sync is an optional paid add-on, whereas Poznote stores notes in its own instance and treats Git and S3 as outbound integrations. The failure mode follows from the architecture. If the container is down, the notes are unreachable, and the README's offline story is limited to an Offline View feature rather than a full local client. The second limitation is documentation depth. The README defers features to poznote.com and screenshots to poznote.com/screenshots.html, and the install section never states resource requirements, backup verification steps, or a supported upgrade path beyond the Update application heading. The release cadence is brisk, with 6.82.0, 6.83.0 and 6.84.0 all published within roughly two days in September 2026, and the README does not describe a migration process between versions. Frequent releases on a self-hosted tool mean you should read each release note before pulling, not after.
Licence, maintenance and what an upgrade actually costs you
Poznote is MIT licensed, so you can run, modify and redistribute it, including commercially, provided the licence text travels with copies. This is not legal advice; read the LICENCE file in the repository for the actual terms. The maintenance cost is the part the README understates. You are running at least one container, and the compose file pulls a second image for the MCP server, so upgrades mean re-pulling images and restarting the stack. The README's Update application section is listed in the table of contents but the supplied text does not include its contents, so the exact upgrade command is unverified here. The Helm chart adds a second maintenance surface with a different maintainer, which means a Poznote bug and a chart bug arrive through different channels. Before you put real notes in it, confirm three things: that .env.template contains every variable your deployment needs, that your backup and restore path actually round-trips through Backup / Export and Restore / Import, and that you are comfortable running a PHP web app that is updated several times a week.
Editorial conclusion
Adopt Poznote if you already run Docker and want a notes, tasks and wiki server on your own hardware, with Git sync or S3 as the documented escape hatches. Skip it if you need a native desktop client with local file storage, or if you cannot run a server at all. Before committing, pull the image and load the demo at demo.poznote.com, read the .env.template to see which variables the compose file expects, and check whether your target server is amd64 or arm64, since the official image is published for both.
Community notes