Personal Management System: a self-hosted PHP backend for one person's data
Your web application for managing personal data.
At a glance
- What is it?
- Volmarg's Personal Management System is a Symfony-based backend that bundles contacts, notes, passwords, payments, schedules and more into a single database you host yourself. It is built for a single operator on a home network, not for teams or multi-tenant use.
- Who is it for?
- Adopt it if you are a PHP developer or a comfortable self-hoster who wants one database for contacts, notes, passwords, payments and schedules, and who is willing to run the backend and the separate frontend repository yourself on a machine that stays off the public internet. Do not adopt it if you need multi-user accounts, mobile clients, or a hosted service with support.
- 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 last received commits 6 days ago.
- 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 problem: personal data spread across clouds you do not control
The README states the author's reason for building this directly: he was tired of having very personal data on OneDrive, other data on Google cloud, some notes in one place and some in another. The stated end goal is an application running on a terminal or a Raspberry Pi, plugged into a home network, without access to the internet. That is the design target. The system is for one person managing their own records, and the module list reflects that: Todo/Goals, Notes, Contacts, Passwords, Achievements, Schedules, Issues, Travels, Payments, Shopping, Job, Images and Files. There is no mention of user roles, shared workspaces or an organisation model anywhere in the supplied material. The README compares the logic to a CMS such as WordPress or a CRM such as SugarCRM, and says the system offers fewer possibilities than those, but does what the author wants. That comparison is about architecture, not about scale.
How the backend is structured: Symfony, modules, and a separate frontend
The repository is described as the backend only, and the README links to a second repository, personal-management-system-front, for the frontend. So the runtime is at minimum two codebases: a PHP application built on Symfony, and a client that talks to it. The primary language listed is PHP, and the topic list includes symfony, docker and self-hosted, which tells you the intended deployment shape. Modules are the organising unit. The README says writing extensions is not too hard depending on the logic required, and that anyone with development knowledge can write their own extensions for personal needs. That is the extensibility story: you add a module rather than configure a plugin marketplace. Several modules are explicitly submodule-based rather than flat. Payments contains Products Prices for tracking prices of particular products, an owed money submodule for who owes you and who you owe, and a Bills submodule kept separate from monthly payments. Job contains Afterhours, where you allocate minutes or hours to a named goal or leave them in a general pool, and Holidays, which tracks days used from a yearly allowance. Schedules feeds the Dashboard and the notification bell, so there is a cross-module data flow from scheduled items into the notification surface. Passwords stores credentials encrypted in your database and the frontend exposes a copy button that returns the original value, which means decryption happens server-side and the plaintext reaches the client on request.
Getting it running: what the material actually specifies
The README does not include an installation command block. What it gives you is the demo and the documentation site. The demo is at personal-management-system.pl with the login admin@admin.admin and the password and lock password both set to admin. Those are demo credentials, not defaults you should carry into a deployment, and the README presents them only as a way to look at the running application. The documentation lives at volmarg.github.io, and that is where installation steps would be. The homepage is personal-management-system.pl. Because the repository is backend-only, any setup procedure has to cover the frontend repository as well, and the supplied material does not state whether the two are pinned to matching versions. The topic list includes docker, so a container-based path is likely documented, but I cannot confirm the compose file name, the image name, or the environment variables from what is here. If you are evaluating this for adoption, the first thing to read is the documentation site, not the README, because the README is a feature tour and a statement of intent.
Where it fits badly: single-operator assumptions and a two-repository install
The clearest limitation comes from the stated goal itself. The author wants this running on a terminal or Raspberry Pi on a home network without internet access. That is a deliberate constraint, and it shapes everything. A system designed for one person on a private network is not a system you hand to a five-person team, and nothing in the material suggests account separation, permission boundaries or an audit trail. The Passwords module is the sharpest example of the risk. Credentials are encrypted in your database, and the frontend fetches the original back through a copy button. That design is convenient and it means the application holds a decryption path. The README does not describe the key management, so whether the key sits in an environment variable, a config file or the database is something you must confirm in the documentation before you store anything you would not want exposed by a misconfigured host. The second constraint is operational: backend and frontend are separate repositories, so an upgrade is two upgrades, and the release list shows a beta tag published between stable tags, which means you should read release notes rather than assume every tag is a drop-in. The third is scope. This is not a password manager in the sense of a dedicated, audited, browser-integrated vault, and it is not a bookkeeping package with double-entry accounting. It is a personal record keeper with a payments module attached.
What it replaces, and how the approach differs
The obvious alternative for the same job is Nextcloud, which is also self-hosted, also PHP, and also aimed at keeping your own data on your own hardware. The difference in approach is the unit of organisation. Nextcloud is a file and groupware platform: you install it, you get users, shares, calendars, contacts and a file tree, and applications are added on top of that substrate. Personal Management System is a set of purpose-built modules over a single personal database, with no user model described in the material and no file-sync substrate. If your problem is that your files and calendars live in three clouds, Nextcloud addresses that directly. If your problem is that your contacts, owed money, car service schedule, holiday allowance and password list live in five unrelated places and you want them in one schema you control, this project is closer to the mark. A second reference point the README itself names is the WordPress-plus-plugins route, which the author rejected on the grounds that assembling and customising plugins would take as long as writing his own system. That trade is real: you get one coherent codebase instead of a plugin stack, and you give up the plugin ecosystem, the theme market and the large pool of people who already know how to administer it.
Maintenance, releases and what the MIT licence covers
The project is not archived and the last push recorded is 2026-09-10, with releases at v2.0.4 in April 2026, v2.0.3 in January 2026, and v2.0.3b, a beta, in mid-January 2026. That cadence suggests active but not rapid development, and the presence of a beta tag in the release list means you should track tags deliberately rather than pulling whatever is newest. Maintenance cost for you is real and mostly front-loaded: you are running two repositories, a PHP runtime and a database, and you are responsible for patching both halves. Because the stated deployment target is a machine without internet access, automatic updates are unlikely to be part of the design, so upgrades are manual and you should read the release notes for each tag before moving. On licensing, the repository is MIT, which is permissive and permits commercial use and modification provided the licence and copyright notice are preserved. That is a statement about the licence text, not legal advice, and it says nothing about the licences of any dependencies pulled in through Composer or npm, which you would need to check separately if you plan to redistribute the application or ship it inside a product.
Who should run this, and what to check before you do
The fit is narrow and clear. You are the right user if you are comfortable with PHP and Symfony, you are willing to deploy a backend and a separate frontend, and you want one private database holding your contacts, notes, schedules, payments, job hours and passwords. You are the wrong user if you need multiple accounts, a mobile app, a hosted service with an SLA, or a password vault that has been independently reviewed. Before you migrate anything sensitive, open the documentation at volmarg.github.io and answer three questions. First, how the Passwords module derives and stores its encryption key, and whether that key is separable from the database backup. Second, whether the frontend repository documents a version pairing with backend tags such as v2.0.4. Third, what the upgrade procedure is between tags, given that v2.0.3b shipped as a beta alongside v2.0.3. If the documentation answers those, the demo at personal-management-system.pl with the admin@admin.admin login is the fastest way to see whether the module set matches how you actually keep records.
Editorial conclusion
Adopt it if you are a PHP developer or a comfortable self-hoster who wants one database for contacts, notes, passwords, payments and schedules, and who is willing to run the backend and the separate frontend repository yourself on a machine that stays off the public internet. Do not adopt it if you need multi-user accounts, mobile clients, or a hosted service with support. Before committing, verify three things in the documentation and the demo: how the Passwords module encrypts stored credentials and where the key lives, whether the frontend repository is versioned in step with backend releases such as v2.0.4, and what the upgrade path looks like between tags, since the release history shows a beta tag (v2.0.3b) published alongside the stable v2.0.3.
Community notes