DEV Community: Edris

Edi Life OS v1.2: accounts, a one-command Docker install, and my first outside contributors

Edris — Mon, 19 Oct 2026 10:04:18 +0000

Less than two weeks after launching Edi Life OS, my self-hosted life dashboard (habits, goals, focus timer, Kanban, finances, plus an MCP server for AI assistants), here is v1.2. More than twenty pull requests have landed since the last release, and most of them came from people I had never met.

What's new

Multiple accounts with private workspaces

Each account signs in on its own and has its own Finance, Focus, Goals, Growth, Kanban, habits, notes, attachments, theme and currency. Everything in the app and the API is filtered to the signed-in account, so one account cannot read another's data by guessing an ID.

Two things to know before you use it:

Every account is an administrator. Administrators can reset each other's passwords, which means they can sign in as that person. There is no public sign-up; only add people you trust.
Back up your database before upgrading. Version 1.2 migrates the schema (version 3), and older versions of the app must not run against it, because their queries would show every account's rows. The details are in docs/accounts.md.

A prebuilt Docker image

No clone, no build. The image is published for amd64 and arm64, so it also runs on a Raspberry Pi:

curl -fsSLO https://raw.githubusercontent.com/edrisranjbar/lifeos/main/docker-compose.image.yml
curl -fsSL https://raw.githubusercontent.com/edrisranjbar/lifeos/main/.env.example -o .env   # then set your sign-in and passwords
docker compose -f docker-compose.image.yml up -d

Open http://localhost:8080. Upgrade later with docker compose -f docker-compose.image.yml pull && docker compose -f docker-compose.image.yml up -d; your data lives in named volumes. Pin a version with LIFEOS_VERSION=1.2.0 in .env.

And more

18 more display currencies (SEK, NOK, DKK, PLN, CZK, BRL, MXN, ARS, CLP, COP, SAR, QAR, KWD, EGP, ZAR, NGN, PKR, BDT). They only change the label; nothing is converted.
Inline editing of goal checklist tasks, and redesigned Notes, Notepad and Personal Growth views.
Hardening: logout is a POST with a CSRF check, schema changes run once per version under a lock, and static assets are cached with versioned URLs.

The community part

This is the part I did not expect. A set of small, well-explained issues (an accessibility fix, a few currencies, backup commands, reverse-proxy examples, a troubleshooting guide, a Spanish README) turned into pull requests from three people who had never contributed here before. Their work is in the release notes with their handles. If you want a first open-source contribution, the good first issues are real and there are more.

A bug I caught after publishing

Right after I published the image I looked at the registry's tag list instead of assuming it was fine. The compose file asked for the latest tag, and latest did not exist yet, because that tag is only created when you push a release. The one-line install would have failed for the first person who tried it.

I fixed the default, tagged the release, and then added a CI job that runs the README's exact steps on a clean machine (download the compose file, set a password, start the published image, sign in) on every change. If you publish an artifact, test the artifact, not just the code that builds it.

Edi Life OS v1.1: what a public security pass changed after launching on Hacker News

Edris — Sat, 10 Oct 2026 14:48:40 +0000

A little while ago I posted Edi Life OS on Hacker News. It's a self-hosted dashboard for habits, goals, focus, money and projects, written in plain PHP, MySQL and vanilla JavaScript, with an MCP server so Claude and other assistants can work with your real data.

The launch brought a lot more eyes than I expected. More people looking at the code meant more people who would actually install it on their own servers, so the first release after launch had one theme: trust.

Here's what changed in v1.1, and what I learned doing it.

A security pass, written down in public

I went through the PHP backend and the frontend JavaScript and wrote every finding into one public issue, ordered by priority. Then I fixed them from the top.

High

Stored XSS on the dashboard. Goal titles, categories, metrics and finance category names were rendered with innerHTML without escaping. Those values can also be written through the bearer-token API, so API data could run script in the signed-in session. They're now escaped.
Open redirect after sign-in. The redirect parameter only had to start with / and not //, which browsers can be tricked around. It now has to be a real same-origin path.

Medium

CSRF on Habittify. Every write endpoint checked a CSRF token except the habit tracker's API. Now it does too, through one shared life_os_require_csrf() helper.
Sign-in rate limiting. After 5 failed attempts from one client in 15 minutes you get 429 with Retry-After, and the password isn't even checked. The limit is per IP (stored as a SHA-256 hash), not per username, so an attacker can't lock the owner out from everywhere.
Security headers. Content-Security-Policy, X-Frame-Options: SAMEORIGIN, Referrer-Policy and X-Content-Type-Options on every response. The CSP still allows inline scripts for now, because the app has inline handlers; moving them out is next.
HTTPS behind a reverse proxy. A new LIFEOS_TRUST_PROXY setting makes the session cookie Secure based on X-Forwarded-Proto and rate-limits by the real client IP. It's off by default, because trusting those headers on a directly exposed app would let anyone spoof them.

The lesson: with no framework, every protection a framework gives you for free (escaping, CSRF, headers) has to be built on purpose and applied everywhere. One endpoint that was written a little earlier than the others is enough to leave a gap.

A leaner MCP server

The MCP server never touches the database. Every tool goes through the same token-protected HTTP API the app uses, delete tools are marked destructive so the client asks first, and secret notes stay hidden unless the server explicitly allows them.

In v1.1, the 12 read-only tools became one lifeos_query tool with a type parameter (dashboard, goals, tasks, habits, finance_summary, notes and so on). Fewer tools means less of every conversation spent on tool descriptions, and an easier choice for the model.

Also new

Display currency. Finance started out Toman-only. You can now pick USD, EUR, GBP, AED and others in Settings. Amounts are labels and are never converted.
A landing page: edrisranjbar.github.io/lifeos
First outside contributions: CI that runs the PHP and Node tests on every PR, a Docker health check, and light-theme screenshots.

Try it

git clone https://github.com/edrisranjbar/lifeos.git && cd lifeos
cp .env.example .env   # change the username and passwords
docker compose up -d   # then open http://localhost:8080

There's also a release zip for shared hosting: extract it, add your MySQL details, done.

Repo: https://github.com/edrisranjbar/lifeos
Release notes: https://github.com/edrisranjbar/lifeos/releases/tag/v1.1.0

If you self-host things: what's the first thing you check before you install an open-source app on your server? I'd love to hear it in the comments.

Building a self-hosted life OS that my AI assistant can actually use

Edris — Thu, 08 Oct 2026 08:05:45 +0000

My days used to live in five places: a to-do app, a habit tracker, a budgeting spreadsheet, a Pomodoro timer and a notes app. Each one was fine on its own. None of them knew about the others, so the question I actually cared about ("am I moving toward the life I want?") had no single place to live.

So I built one. Edi Life OS is a self-hosted dashboard for focus, habits, goals, projects and money, and it ships with an MCP server so an AI assistant like Claude can work with my real data. It's open source under the MIT license: github.com/edrisranjbar/lifeos.

This post is about the decisions behind it, including a few that were less obvious than I expected.

What's in it

Ten workspaces share one design, one sign-in and one database:

Overview: a daily score built from focus time, habit consistency, goal progress and finished work.
Growth: six life areas (spirituality, health, relationships and family, finance, self-growth, fun and rest), each linked to long-term goals, SMART goals, habits and tasks, with guided weekly, monthly and quarterly reviews.
Focus: a Pomodoro timer with a built-in soundtrack.
Habittify, Goals, Kanban, Calendar, Notepad, Notes.
Finance: expenses, income and budgets, plus debts and credits (one-time or recurring) that write straight into the ledger.

The point isn't the number of features. It's that they're connected: a habit can drive a goal's progress, a Kanban card shows up in the calendar, and the Overview turns all of it into one picture of the day.

Growth: six life areas, each with its own progress, habits and tasks.

Habittify: small daily habits and a seven-day picture of consistency.

Kanban: labels, due dates and checklists.

Focus: a Pomodoro timer with a soundtrack and a landscape that follows the time of day.

Boring stack on purpose

It's plain PHP 8, MySQL and vanilla JavaScript. No framework, no frontend build step.

That was a deliberate choice. I wanted something that runs on cheap shared hosting as easily as on a server, that I can still read in five years, and that has almost nothing to upgrade. Each workspace is a page; there is no bundler.

There are two ways to install it:

docker compose up -d with a .env file (PHP 8.3 + Apache and MySQL 8.4, with volumes for the database and attachments).
A release zip that matches cPanel-style hosting: extract it into your home directory, and public_html/ becomes the web root while the backend sits above it, out of public reach.

Keeping data safe without a framework

Most workspaces store their state as JSON documents in a single app_state table. That keeps the schema small, but it raises an obvious risk: two tabs (or a tab and an API client) editing the same document and silently overwriting each other.

So every save carries a revision, the SHA-256 of the document the client last saw. The server compares it inside a transaction with the row locked; if it doesn't match, it returns 409 Conflict instead of writing. The browser keeps your unsaved edits and asks you to reload. It's plain optimistic concurrency, and it means no client can quietly overwrite newer data.

Money that doesn't lie

The Finance workspace taught me the most.

Debts and credits are plans, not rows. A monthly rent payment, a loan split into twelve payments, or money a friend owes me once. Dues are derived when you look at a date range rather than created by a cron job, and each due has a stable ID (plan-id:index), so refreshing can never duplicate one.

A few rules turned out to matter:

Terms are fixed after creation. If you could edit a plan's amount, every past due would quietly change meaning. You can rename a plan, stop a recurring one from a date, or delete one entered by mistake, but only while nothing on it has been paid.
Month-end dates keep their anchor. A plan that starts on 31 January is due on 28 or 29 February and back on 31 March, not drifting to the 28th forever.
Paying is atomic. Recording a payment writes the decision and the ledger entry (an expense for a debt, an income for a credit) in one MySQL transaction, with revision checks on every document involved. Undo removes the entry only if you haven't edited it since.
Splits are exact. A total divided into N payments uses whole Toman amounts, with the rounding remainder in the last payment.

Letting an AI assistant in, carefully

This is the part I'm most excited about. Edi Life OS has a small HTTP API protected by a dedicated bearer token, and a stdio MCP server with 26 tools on top of it: dashboard, goals, tasks, habits, finance and notes.

That means I can ask Claude things like:

"Show me my dashboard."

"Create a SMART goal called Build a home studio, due in three months, and add Buy acoustic panels as a task."

"Mark Reading complete for today."

…and it reads or updates my real data.

The design rules I followed:

The MCP server only talks to the API. It has no database credentials, no SQL tool and no way to touch arbitrary state.
Destructive tools are marked as destructive, so the client asks before deleting anything.
Secret notes stay hidden unless the server explicitly allows them.
Writes are idempotent where possible (completing a habit twice is harmless), and the browser's revision checks mean an AI edit can never be silently overwritten by a stale tab, or the other way round.

Small things I care about

Reviews you can share without oversharing. After a weekly review, you can export a 1080×1350 image of your six-area scores. It contains numbers only; your reflections never leave the app.
Tehran time everywhere, because "today" should mean my today.
Light and dark themes, and layouts that work on a phone.

How it was built

I built Edi Life OS with heavy help from Claude Code: designing, writing and reviewing code, and testing flows in a real browser. I made the decisions; the AI did a lot of the typing and caught a fair number of bugs. Building software this way is a big part of why a one-person project could reach this scope, and the code is open for anyone to review.

Try it, and tell me what's missing

Repo: github.com/edrisranjbar/lifeos
Release: v1.0.0
License: MIT

It's designed for a single owner, so it's a personal tool rather than a SaaS. I'd love feedback, especially on the MCP design and the debts-and-credits model. What would you want an AI assistant to handle in your daily planning?