DigitalOcean deployment guide
A complete cloud deployment walkthrough for Ubuntu 24.04, private Control Plane access, DNS, certificates, and TURN.
Message Easy Mode / Roadmap
0.2.0 is released. The roadmap now moves forward from a stable foundation.
Message Easy Mode has moved from an installer-focused project to a Docker-first operator Control Plane for Matrix + Element. The next work is about better onboarding, broader deployment guidance, post-release refinement, and carefully chosen operator improvements.
Current stable release
Message Easy Mode 0.2.0
AvailableThe 0.2.0 release establishes the current MEM foundation: guided deployment, diagnostics, services, domains and certificates, backup and restore, migration, operator security, and durable operational evidence.
Project lineage: Message Easy Mode (MEM) 0.2.0 succeeds Matrix Easy Mode 0.1.0. The project was renamed to reduce potential legal and brand-confusion risk around use of the Matrix name as MEM continues as an independent project. The underlying Matrix protocol and ecosystem remain central to the product.
Production installer
Public source
Release artifacts
Operator documentation
What 0.2.0 delivered
A real operating layer, not just an installer
The original installation goal grew into a Control Plane that can deploy, inspect, protect, recover, and move a Matrix + Element environment while keeping important system state visible.
Deploy and operate
Guided Setup, chat servers, domains, certificates, services, and day-to-day operator workflows.
Understand failures
Diagnostics, incidents, evidence, service checks, and recovery guidance keep important failure modes visible.
Protect and recover
Backup inventory, integrity checks, private restore testing, and controlled recovery workflows protect Matrix state.
Move existing installations
Migration workflows assess an older installation, preserve evidence, test privately, and control production adoption.
Operate real infrastructure
Postgres, Nginx Proxy Manager, Coturn, storage, Docker, and runtime health remain visible instead of becoming a black box.
Protect high-risk actions
Named operator access, MFA, recent step-up, explicit confirmation, and fail-closed boundaries protect sensitive operations.
Current work
Make the released product easier to deploy and understand
The immediate roadmap is intentionally practical: document the deployment paths we have actually proven, improve onboarding from real operator experience, and keep refining 0.2.0 without pretending that the next version has already been designed.
Proxmox + pfSense deployment guide
A fresh on-premises deployment walkthrough covering the VM, private network boundary, firewalling, DNS, certificates, and TURN.
Additional operator walkthroughs
Turn proven operational workflows into focused guides that help new operators understand the product without hiding the underlying system.
Video tutorials
Build visual walkthroughs around real MEM deployments and operator tasks once the written deployment guides are established.
Beyond 0.2.0
Direction without invented promises
Future development will build from the 0.2.0 foundation and real operator needs. These are product directions, not a commitment to a particular version number or delivery date.
Deployment environments
Broaden proven deployment guidance and supported operating patterns without weakening the private Control Plane boundary.
Operations and recovery
Keep strengthening diagnostics, evidence, recovery, and lifecycle workflows using real deployment experience.
Migration and portability
Build on the migration and backup/restore foundations established in 0.2.0 while preserving explicit safety boundaries.
Operator experience
Reduce unnecessary operational friction while keeping infrastructure state, trust boundaries, and irreversible actions visible.
Roadmap principles
The operating philosophy does not change with the version number
MEM should make difficult infrastructure easier to operate without pretending that the infrastructure or its failure modes disappeared.
Visible, guided, recoverable complexity
Expose failure modes instead of hiding them behind fake simplicity
Prefer recoverable operations over clever automation
Keep important trust boundaries visible
Make public support claims match what has actually been tested
Build for real operators, not only clean demos