Updater-facing software changes only — documentation, site, repository, and cosmetic changes are excluded. Format follows Keep a Changelog; versioning follows Semantic Versioning.
- MOS backs itself up before it updates itself, to one destination you choose for everything automatic. Under Backup & Restore, the place you select under Where backups go is where scheduled backups and the backup before a MOS update go; a backup you take yourself goes there too unless you pick another for that one backup. Clicking Update takes a full backup first and only then applies. If that destination is not connected the update waits and starts by itself when it is back, and offers Cancel update or Update without a backup meanwhile; if the backup cannot be taken at all the update stops before changing anything. Backups and updates no longer collide: each waits for or refuses the other. These backups count towards your keep-last number like scheduled ones. App updates are not backed up first. A schedule set up before this release loses its destination: select one after updating.
- Your backups now have a recovery key you hold. MOS shows it once before your first backup, with a downloadable recovery kit, and will not back up until you confirm you have saved it; Show key under Backup & Restore shows it again behind your owner password, and names every place it opens. A replacement machine connects the same drive or bucket, chooses Enter recovery key, and restores. Connecting to backups another server wrote never changes them — not their contents and not the keys that open them: MOS keeps the key you entered on this machine to read that place, and Forget this key on its row takes it back off. That key becomes this machine's own only when you restore from it and choose to take the other server's place instead of restoring as a copy. Backups taken before this release keep working and move to the new key the first time each destination is opened.
- Backups can now go to an S3-compatible bucket, so a copy lives somewhere other than the building the server is in. Connect one under Backup & Restore with your provider's endpoint, bucket and access key; Test connection tells you before you save whether MOS can reach it, and says which of a wrong key, a missing bucket or an unreachable address it hit. A bucket is then a destination like a drive — back up to it by hand or on a schedule, check, note, restore and delete work the same way — and everything is encrypted before it leaves the server, so the provider cannot read what you store. Backups already on a drive are untouched.
- Backups can now run on their own. Pick a drive, daily or weekly, and a time, and MOS backs the whole suite up without being asked — times are in the time zone you set the schedule from, not the server's, so 3am means 3am where you are. If the drive is not connected when the time comes, MOS waits and backs up as soon as it is back rather than reporting a failure; if the server was switched off through the window, it catches up once shortly after starting, not once per missed day. Retention keeps the last 3, 7, 14 or 30 automatic backups and prunes the oldest after a new one succeeds. Backups you take yourself are never removed automatically, whatever retention is set to, including any taken before this release.
- Apps show their own version. An app's page and its update preview now name the version the app itself publishes, and an update that only changes MOS's packaging says the app stays as it is; the MOS package version moves under Advanced details. Packages declare it with the new optional manifest field
appVersion; every catalog package now does, which is why each one carries a new package version requiring MOS 0.20.0. - App updates now come from whichever is newer: the published catalog, or the packages your MOS version shipped with. Previously only the catalog on
mainwas consulted, so a server following the Staging branch was never offered the app versions it was already carrying, and a server that had never reached GitHub was offered nothing at all. Both now work, and when the newer package is already on the server nothing is downloaded. Servers on Stable or Main are unaffected: a tie goes to the catalog, so they take the same route as before. - Paperless-ngx package 0.3.0 updates Paperless-ngx to 3.1.3. Its AI suggestions can apply themselves through a workflow action and now prefer the tags and correspondents you already use; they stay off until you configure an AI backend under Paperless' own Settings, which MOS neither sets nor exposes. Migrations run on start and are forward-only.
- Backup & Restore is rebuilt around one question: am I safe, where does it go, when was the last one. The page opens with that answer and Back up now, then the places your backups can go, then the schedule, the restore points and the activity — in the order you would ask for them. Choosing where backups go is now selecting a place in the list, and each place states its own condition in one line instead of a pill, a helper and a footer that each said part of it. A place holding another server's backups now says so permanently, on its own row and in the key panel, rather than in one sentence that vanished on reload — so with several drives and buckets you can see which key opens which. Restore points are grouped under the place that holds them, adding a destination is a short guided flow, and technical detail (fingerprints, paths, engine names) is behind Advanced details as everywhere else.
- Restoring a backup onto a different machine now asks what to do with your address. A domain can only point at one machine, so when the backup came from another server and carries one, the restore screen asks before anything starts: Move my address to this machine serves the domain from here and you then point the name at the new server, or Restore as a copy runs the apps on this machine's own address and keeps the domain aside under Settings to move later. Restores onto the same machine, or of backups without a domain, are not asked. Backups written before this release do not record their machine or domain, so a restore of one is treated as this machine's own; take a fresh backup after updating before rehearsing a move. Dashboard tiles now open apps on the applied domain whichever address you reached Home through; after the first replacement-machine restore they pointed at an address nothing served. On a machine that still shows Save your server login on Home, backups and restores wait until you have saved it: a backup taken before that would carry the server password, and a restore would delete this machine's only copy of it.
- Owner password hashing moved up to current guidance — about eight times the previous work per attempt — and your existing password is upgraded to it the next time you sign in, without signing you out anywhere else. Signing in now takes a noticeable fraction of a second by design. The slowdown that follows repeated wrong passwords also survives a restart, so restarting MOS no longer hands whoever is guessing a fresh budget; it is recorded against a keyed digest of the address, never the address itself.
- A browser you have signed in from before is no longer held up by someone else guessing your password. The slowdown that protects your account from guessing across many addresses used to apply to you too; a browser you have used before now skips it, and only its own address is judged. A new browser during such an attack still waits, and changing your password forgets every remembered browser except the one you changed it from.
- MOS now sends you one email when someone is repeatedly trying your password, if an email relay is configured under Settings → Email relay — at most one message a day, with the count of turned-away attempts. This is the first message MOS sends on its own behalf; the relay is otherwise still only for apps.
- Backups are now written into an encrypted, deduplicating store on the backup drive (schema version 4): repeat backups only store what changed, and the drive alone cannot be read without the key held on the server. Restoring from it is verified — the recovery drills were re-run against the new storage on real hardware, including pulling the drive mid-backup, killing the restore outright, and cutting power partway through one, plus a 15.4 GB restore that came back byte-for-byte with every owner, permission and timestamp intact. Compatibility: backups written by MOS 0.19 or earlier, as unencrypted bundles, can no longer be restored by this release; they stay listed and can be deleted to free their space, and restoring one needs MOS 0.19 or earlier. Downloading a backup as a single file and uploading one back are gone with that format — the store on the drive is the copy you keep, and moving it to another machine means attaching the drive. A drive holding a storage format this version does not speak is refused rather than written into.
- App versions now come from the branch your server follows. MOS read the app catalog from
mainwhatever its update track, so a server on the Staging or Main branch could not be offered an app version published on its own branch, and a release that needed something new from the catalog could not read the one published before it — on the Staging track, every refresh failed. A branch track now reads its own branch and a stable release still readsmain, which is what publishes an app update between MOS releases. Compatibility:apps/catalog.jsonmust be signed on any branch a server follows, exactly as onmain. - A failed app-catalog refresh now says why. The reason existed only in the browser console and in no part of the diagnostics file, which reported such a server as having nothing wrong with it; it now reaches the server log once per change of state, appears in the diagnostics file beside the update check, and is readable under Advanced details on the Apps screen. A catalog a release cannot read is reported as version skew rather than an invalid catalog: apps keep updating from the packages that MOS version shipped with, so nothing is broken while it lasts.
- A restore no longer shows a browser error while it runs. Suite Manager is stopped on purpose for the middle of a restore, so refreshing the page used to give a bare
502 Bad Gateway; it now answers with a page saying MOS is busy and will come back on its own, and that page retries by itself until it does. - A drive formatted end to end, with no partitions on it, can now be mounted from Backup & Restore. Only partitions were offered before, so such a drive could not be attached at all.
- Space left behind by an interrupted backup is now reclaimed. A backup cut short — by a power loss, or by the drive being pulled — leaves data in the backup store that nothing refers to, and leaves the mountpoint on the system disk holding whatever was written after the drive went away (34 MB in our tests, and invisible once the drive is back). The first is collected at the start of the next backup to that destination, the second when MOS starts. Previously only deleting a backup ever reclaimed either.
- Restoring a backup now rebuilds apps on the web address recorded in the backup itself. Previously, on a server that got its domain after installation (typical for own-hardware installs), a restore rewrote every app route to the install-time LAN address, leaving all apps unreachable over HTTPS until the owner re-applied their HTTPS settings.
- A backup that fails because the drive was unplugged while MOS was writing to it now says so, instead of showing the storage engine's own message about a file path it could not write.
- The diagnostics file now reports what it actually read. Output from a command that finished quickly could be dropped as it was collected, so running services were listed as
unknownand called out under What looks wrong, and log sections could come back short — while the file still said every source answered. A Docker daemon that cannot be reached is now listed under what could not be collected, rather than reported as a machine with no containers.
- This release carries My Own Suite's first community contribution. @okeycj added backend test coverage for the HTTPS settings and backup-inventory services (#259), thank you.
- Suite Manager keeps technical detail out of the way until you ask for it. Package ids, digests, ports, volume names, generated configuration and raw logs are no longer shown on healthy screens; Settings → Technical controls brings them all back, per owner and off by default. Diagnostics on a screen that is reporting a failure stay visible either way, so a bug report can still quote them.
- Installed apps can now take environment variables you set yourself, under Advanced details in an app's Settings dialog. It is for values an app's own documentation asks for that MOS never knew to ask about — an upstream API credential, a feature switch — and it needs Settings → Technical controls switched on. Names MOS already manages are refused by name rather than silently ignored, hidden values are stored like any other app secret and never shown again, and MOS restarts the app and waits for it to answer: a value that stops it starting is rolled back to the previous environment on its own. Your variables survive app updates. Compatibility: a published privacy assessment describes an app as MOS ships it, so an app carrying your own variables says so on its posture panel.
- Settings → When something is not working gathers what MOS knows into one downloadable text file: what is running, what failed recently and why, and the relevant service and app logs, led by a summary of what looks wrong. Read it yourself, send it to someone helping you, or give it to an AI assistant. Passwords and app secrets are removed by exact value before it is written and the file reports how many it masked, but server and app names and local network addresses are kept — not secret, and a broken address cannot be diagnosed without them — which the file states in its own header. Collection uses a new read-only host agent that a managed update installs for you; the export needs a signed-in owner, so it cannot help someone locked out of Suite Manager.
- MOS now records why something failed instead of discarding it. An app that will not install or start explains what went wrong and what to do about it, with the error code and the runtime's own output kept under Advanced details so a bug report can quote them; the explanation disappears on its own once the app works again. Suite Manager's own internal errors were previously written nowhere at all — they are now logged, and the message you see carries a short reference code that finds the matching line, so "Internal server error." is finally something you can report. Server logs are also now bounded: the journal was allowed to grow to a tenth of the disk, which on a small server is gigabytes competing with your own data.
- The reason behind a failed privileged command is kept as well. A
docker buildthat fails, a Caddy validation that rejects a file, a service that will not restart, or a platform update step that exits non-zero now reports the last lines it wrote — never the command line, which for an app container carries its secrets — with secret values masked by the agent and again by Suite Manager. A failed platform update shows its reason on Updates, a failed HTTPS or Homepage apply on its own screen under Advanced details, and all of them reach the diagnostics file. Where every HTTPS failure used to readHTTPS_APPLY_FAILED, the code now names the step that failed, and an update step that hangs fails after an hour instead of holding the job open forever. - Own-hardware installs now work on machines with more than one internal disk, which the installer previously refused outright. It lists every disk large enough in a stable order and says what each already holds —
empty - no partitions, orNOT EMPTYwith the filesystems and labels it found — so the spare drive is distinguishable from the one with your photos on it. Only the disk you pick is touched; the confirmation names it and its contents again before anything is erased. - Settings → Email relay lets you point MOS at one outbound SMTP server — your mailbox provider, or a service like Fastmail or Mailgun — so apps that send mail have a way to send it. You enter the host, port and login your provider gives you; MOS matches the encryption to the port for you, verifies the login, and lets you send yourself a test message. The relay password is stored like any app secret and never shown again. One relay is shared with every app that asks for it and MOS never uses it for itself; it is optional, and nothing changes if you leave it unset. Vaultwarden, Immich, Paperless-ngx, Seafile and Radicale now send their email through it — invitations, share links, notifications, password resets, calendar invites — when a relay is set, and stay exactly as private as before when one is not. Compatibility: apps read the relay through a new manifest template namespace,
${smtp.*}, added to manifest generation 1 in this release; a package that uses it must setminimumMosVersionto this version, and older MOS releases refuse such a package rather than misconfiguring it. The relay resolves only when an app's runtime is built, so it never enters a stored projection or package digest — changing it does not make installed apps look out of date; they pick it up on their next update or restart.
- Installing an app now opens the same review dialog for every app in the catalog, replacing the Prepare panel some apps showed and the bare Install button the rest had. It lists whatever the app needs from you, the web address it will get, and whether to put a shortcut on Homepage. Apps that need nothing say so rather than installing on the first click.
- That dialog reopens as Settings once an app is running, and is no longer hidden behind technical controls. The values you gave at install are shown there as facts rather than editable fields: most are read only once, when the app first starts, so changing them afterwards would either do nothing or stop the app reaching its own data. Change them from inside the app itself.
- Fixed update checks that failed intermittently for months on some networks, leaving the Updates screen stuck on Already up to date. The cause was git's default transport (protocol v2 over HTTP/2) having its reply truncated mid-stream, which git misread as a login prompt; the updater now fetches over protocol v0 and HTTP/1.1, which is deterministic. A check that still fails now reports itself as failed, retries before giving up, and shows what github.com actually answered — HTTP status, request id, and whether this server sent a stored login — under Advanced details and in the diagnostics file; Update now refuses on an unchecked state instead of claiming there is nothing to do, and a running update no longer re-fetches on every status poll.
- Installing on your own hardware now registers the installed disk with the machine's firmware. Firmware that does not try the removable-media boot path on a fixed disk reported no bootable drive with the USB stick removed and booted normally with it in — a finished install that read as a failed one, and more likely now that the installer can offer several disks. If the firmware refuses the entry, the installer says so and names the disk to pick in the BIOS/UEFI screen.
- App containers can no longer fill the server's disk with their own logs. Each keeps at most 30 MB, where before a single app logging on a loop could take down the whole suite. Existing apps take the cap the next time they are applied or updated.
- Updating MOS no longer leaves your browser running the interface from before the update. The Updates screen reloads itself once an update that changed the interface finishes, any other open tab offers a Reload, and the Suite Manager page is no longer cacheable, so a reload can no longer hand back the old version.
- The own-hardware installer no longer turns a mistyped answer into a silent non-install. It numbers the choices, takes the erase confirmation as a separate step, and asks again on anything it does not recognise. Previously any answer other than exactly
YES— a lowercaseyesincluded — continued booting from the USB stick and brought the suite up there, which looked like a finished install on a machine that stopped booting the moment the stick came out. A machine running from the stick now says so on its console instead of reporting itself installed, and the stick is no longer expanded to fill itself, so it stays usable as an installer.
- A home-server install now has two ways in, and the screen shown when the install finishes offers both:
http://home.mos.home, which needs a*.mos.homerule in your own router or Pi-hole, andhttp://home.<your-lan-ip-with-dashes>.local.myownsuite.org— for examplehome.192-168-123-45.local.myownsuite.org— which needs nothing set up on any device. Installed apps answer under whichever you use, neither address is a setting, and dashboard tiles now open the app through the address you arrived on instead of the one that installed it. The second address sends DNS lookups for your app subdomains to MOS-operated nameservers, which do not log queries; the first never involves MOS infrastructure. It contains your server's LAN address, so set a DHCP reservation — both addresses need one, and if it changes, saved links and app addresses break until each app is applied again. Applying your own domain with HTTPS stops the second address being served, and cloud/VPS installs are unaffected. - App packages can declare what each of their services needs to run — memory and CPU at rest, and at peak where a service has heavy work to do — and the Resources view shows the figures beside the existing light/medium/heavy band. Radicale and Stirling PDF declare them first; apps without figures read as before. Compatibility:
resources.services.<id>.requiresis an optional addition to manifest generation 1 that older releases ignore, so packages using it require this release. - Actual Budget: envelope budgeting, one service and one volume. Sets its own password on first open; connects to no bank unless you add sync credentials.
- Paperless-ngx: searchable scanned documents, OCR on your own server in the language chosen at install (EN/NL/DE/FR/IT/ES). Cloud AI, remote OCR and its own update check are off. Rated "Private by default" — no outbound traffic observed.
- Installing on your own hardware now uses a prebuilt disk image (
.img.xz, ~2 GB) instead of an ISO installer: the machine is installed and boot-tested in the release pipeline and you flash the finished result, so first boot downloads nothing and takes minutes instead of 15–30. Compatibility: the target machine must boot in UEFI mode and have a single internal disk — it names the disk it found and asks you to typeYESrather than erasing anything on its own. Existing servers are unaffected and the ISO is no longer published. - Servers installed from the image now show a My Own Suite login message instead of Ubuntu's. Canonical's version advertised Ubuntu Pro, printed a package-update count that contradicted the Updates screen, and fetched news from
motd.ubuntu.comon a timer — an outbound call no owner asked for. The image still states plainly that it is built from Ubuntu and is not a Canonical product. - Privacy labels reworked around one question: does anything leave your server, and who decided. New "Your choice" label where an in-app setting stops it; "External dependency" now means nothing can, and that MOS accepted the trade. Labels link to the full published assessment. Seafile → "Private by default"; Vaultwarden → "Your choice" (fetches website icons; Settings → "Show website icons" stops it). No grade moved. Compatibility: the assessment format changed, so all eight packages ship patch updates requiring this release. Update MOS before apps — older installs are not offered these versions rather than failing partway.
- Immich's privacy assessment redone from network captures: "Privacy configured" → "External dependency". The map requests tiles from Immich's tile service, which logs tile, IP and timing, and MOS pins the config so it cannot be disabled; photo coordinates are never sent. Version check goes to version.immich.cloud, not GitHub.
- Immich package 0.5.0 updates Immich to v3.1.0; its health check now targets an endpoint Immich serves. Migrations are forward-only — no downgrade after this applies. Live Photos uploaded in the background on the previous version may lack thumbnails until Immich's "missing" job runs.
- Catalog packages name the full set of products they replace, and app search matches them: "onedrive", "lastpass" and "ynab" find the right app.
- Vaultwarden and Stirling PDF show screenshots before install. Patch update; no runtime change.
- The app list shows each app's one-line summary instead of the opening paragraph of its full description, which had turned the catalog into a wall of text; the full description still opens with the app. Radicale, Seafile, Stirling PDF, ONLYOFFICE and Vaultwarden ship plainer summaries to match, and Stirling PDF moves from "Light" to "Medium" resources, which its declared figures now back up.
- The Apps screen now reliably picks up new apps and versions. Its background catalog fetch rejected itself as "too soon" if Apps had been opened in the last 30 seconds, and never retried after a failure, so the list could sit stale for hours.
- Backing up to an exFAT or NTFS drive no longer fails with "EPERM: operation not permitted, chmod ...". The snapshot is now built on the system disk and only the finished archive written to the drive. Affected every installation with apps; the backup failed rather than producing an incomplete bundle.
- Seafile now enables its WebDAV extension: WebDAV-capable clients (for example the ONLYOFFICE mobile apps) can connect at
https://seafile.<your-domain>/seafdavusing Seafile account credentials.
- The app package manifest is now a locked, versioned contract (generation 1). Manifests declare
manifestVersion: 1, unknown fields are ignored instead of sometimes rejecting the package, every${…}template reference is validated against the fields it names, and a published JSON Schema (apps/manifest.schema.json) plusnpm run apps:manifest:checklet package authors validate without running MOS. All six catalog packages ship a patch update migrated to the locked shape (catalog.replacesis now a list, redundant route ports and dead onboarding metadata removed); the migrated packages require this MOS release or newer.
- The hosted one-line installer installs the latest published release instead of the tip of
main, so both installer paths now start on the same release commit. Cloud installs previously picked up unreleased commits while still reporting the last release version.
- Installing an app whose images take more than three minutes to build no longer fails with "App runtime apply timed out". The app was in fact running — Suite Manager had stopped waiting and lost track of it. ONLYOFFICE hit this on a small server; an app left stuck this way recovers by running its install again.
- USB-installed servers no longer expose an unauthenticated endpoint that wipes the suite. It deletes every installed app's containers and volumes, and was enabled on published installer images, so any device on the same network could have triggered it. It is now confined to the disposable test-VM build profile, and a release build fails if a publishable image carries it. Machines installed from the v0.16.0 image close the endpoint when they take this update; reinstalling is not required.
- Onboarding requires accepting the terms of use before the owner account is created.
- Settings can change the owner password. It verifies the current password, then signs every other browser out — the way to replace a password first set over plain HTTP on own-hardware and local installs.
- Suite Manager's menu combines Dashboard and Customize into one row.
- Customize saves in one click. Validation runs as part of saving rather than as a separate button, and the reload button is replaced by a reload offered only when the file changed underneath the editor.
- The welcome screen adapts to whether any apps are installed.
- An installed app with an update waiting leads with Review update; opening the app stays beside it.
- App setup forms can prefill values from the owner profile (
${owner.name}/${owner.email}manifest defaults), on install and when an update asks for newly required values. Radicale 0.4.0 uses this: the username prefills with the owner email and a new "Calendar name" field names the seeded calendar in connected clients — replacing the bare "default-calendar" slug phones showed, which invited deleting and recreating the calendar and silently broke the dashboard widget. - Fresh installs resolve the control plane's dependencies with
npm ciinstead ofnpm install, matching what managed updates already did. Installs now use the committed lockfile exactly and fail fast if it andpackage.jsondisagree.
- A new Radicale install no longer shows a broken Homepage calendar widget. Homepage treats a feed with no entries as an error, so the package now seeds a yearly "Your independence day" event dated the install day. Existing calendars are untouched.
- Dialogs and action menus opened from app details now centre on screen and frost correctly.
- USB installer hardening: the installed server keeps its own hostname, the Ubuntu install phase no longer needs network access (first boot still does), the success screen shows the server's LAN IP with the local DNS override to add, and the ISO carries a
MOS-INSTALLERvolume label. - The Vaultwarden package moves to server 1.37.0, restoring vault sync for Bitwarden clients 2026.7.0 and newer.
- Homepage customization now supports one level of nested service groups (sections inside a category), as Homepage itself renders and as MOS1 layouts used. Previously nested entries were silently accepted but ignored: their home-service Caddy routes were dropped on save and their metadata skipped validation. Guided add/remove and app URL reconciliation now reach entries inside subgroups too.
- The USB installer no longer decides the server's console password when the ISO is built. The autoinstall ships a locked account, and the installed machine generates its own login on first boot. The password is shown on the server's own screen and handed over once in Suite Manager, which deletes it as soon as the owner confirms they saved it — so it exists only on the machine that uses it. This replaces both the committed placeholder hash that briefly owned the account during install and the
MOS-server-login.txtfile written beside the ISO. Anyone who has shared a built ISO should treat its machine password as public and change it. SettingLINUX_PASSWORDstill pins a password for a lab machine you own, and an ISO built that way must not be shared.
- My Own Suite is now officially licensed as free and open-source software under the GNU Affero General Public License v3.0 only.
- Every official catalog app now carries a published MOS privacy assessment. Immich, ONLYOFFICE, Vaultwarden, and Seafile are graded B ("Privacy configured"), while Radicale is graded A ("Private by default"). Their package versions were bumped so existing installations receive the assessments through ordinary app updates.
- Suite Manager's app detail view now puts status, screenshots, privacy posture, resources, connections, and owner-relevant information first, with low-level diagnostics kept under Advanced details. App packages can now ship screenshots through the authenticated package API.
- Cloud owner setup now asks for the one-time claim key before account details when a setup link is incomplete, accepts the full printed key line, and allows a mis-copied key to be replaced. Owner setup also requires password confirmation.
- Privacy posture is presented as an A-to-D grade instead of a 0–10 score throughout Suite Manager and update review.
- The installer now prints one correct finish-setup link: cloud installs show only the claim-key URL required to create the owner account.
- Optional catalog and advisory refreshes now run quietly in the background. The Apps screen uses the signed catalog bundled with the release and no longer interrupts owners when a network refresh is stale or unavailable.
- Suite Manager's first-run screen now guides owners through installing an app, adding it to Homepage, and creating a backup. App connections use a clearer visual with a direct Connect action.
- App update availability is now determined by package version and MOS compatibility. Package contents must change version, downloaded updates remain verified against the signed catalog digest, privacy-assessment metadata no longer blocks official updates, and incompatible updates are explained in app details without an actionable badge.
- Catalog refresh now accepts a valid
304 Not Modifiedresponse while continuing to reject actual redirects. - Newly installed apps no longer show false catalog-integrity conflicts when the local checkout and catalog branch are at different commits.
- Catalog package versions are Immich 0.4.0, ONLYOFFICE 0.2.0, Radicale 0.3.0, and Seafile, Stirling PDF, and Vaultwarden 0.2.1. Radicale also updates to 3.7.6.
- The Stable update track can now apply tagged releases. Fresh installs default to Stable, named-branch checkouts continue following their branch, and branch-track updates land exactly on the tracked remote branch even after rewritten history.
Milestone release: My Own Suite is now an app platform instead of a fixed suite, with versioned and signed app packages managed individually through Suite Manager.
- Added browser owner setup, an authenticated Home/Suite Manager control plane, manifest-driven app lifecycle management, Homepage customization, private-LAN and public-VPS HTTPS, whole-suite backup and restore, and managed platform updates.
- Added independently versioned app packages with validated snapshots, preview, build, health-check, activation, rollback, recovery, and lifecycle handling. External Git packages use the same constrained pipeline and remain visibly External · Unverified.
- Added MOS Privacy Posture with evidence, provenance, freshness, per-dimension findings, and an explicit unrated state.
- Added hosted stable and development installers, a zero-configuration USB installer, and cloud and local installation paths.
- Added packages for Stirling PDF, Vaultwarden, Radicale, Seafile, ONLYOFFICE, and Immich, including setup fields, secrets, multi-service runtimes, Homepage projections, and Seafile/ONLYOFFICE integration.
- App installs and updates retain the exact validated package snapshot. Update review shows permissions, privacy changes, migrations, downtime, backup requirements, and breaking changes before applying the reviewed digest.
- Uninstall confirmation now clearly distinguishes permanent removal of app resources and data from stopping an app while retaining its data.
- Whole-suite backup and restore now use schema version 3 with owned-resource inventory, database-consistent snapshots, size accounting, preflight bundle checks, uploaded-bundle validation, operator notes, and interruption recovery. Restore reconciles resources created after the backup, preserves one rescue generation, verifies the restored inventory, checks disk space, and refuses ambiguous or unsafe destinations. Version 2 bundles remain restorable.
- Managed platform reconciliation refreshes Suite Manager, Caddy wiring, Homepage, systemd units, and repo-owned host agents without rebuilding installed apps. Main and Staging branch tracks are selectable; installed apps continue updating separately from their retained package snapshots.
- Hardened app update interruption and rollback recovery, integrated-app updates, disabled and concurrent lifecycle handling, external app identity and configuration, orphan reporting, privacy-review validation, bounded backup hashing, image cleanup, and runtime status reporting.
- Public-cloud owner setup now uses trusted HTTPS, a root-only one-time claim secret, secure cookies, and firewall configuration.
- Fixed DNS-01 and Homepage route reconciliation so MOS-owned links follow the active domain without rewriting user-authored links, and managed updates retain installed Home and state paths.
- Official catalog and advisory files now require offline Ed25519 verification against the key shipped with the release; invalid or missing signatures fail closed.
- External packages are rejected before build or apply when they request unsafe privileges or undeclared capabilities. Downloads use immutable revisions with bounded time, redirects, size, file count, extraction, canonical paths, and concurrency.
- Added bounded progressive login throttling by client and account, trusted-proxy handling,
Retry-After, and secret-free security aggregates with retention limits.
- Removed the temporary generation label from MOS-owned environment variables, runtime paths, services, sockets, containers, and backup folders. Prototype environments should be reset before validation.
- MOS paths now live at the repository root, and the control-plane URL moved from
suite-manager.<domain>/setup/tohome.<domain>/suite-manager/. - The app-agent contract is version 9. Manifests may constrain
amd64andarm64; backup schema 2 rejects pre-snapshot bundles; external routes useext-<host>; and releases require matching signed catalog and advisory metadata. - USB installer owner fields were removed. Owners are created in the browser, and each installer build generates a unique machine login password.
- MOS is beta. Platform updates leave installed apps on their package snapshots; apps update separately.
- Backups are manual, whole-suite, unencrypted, destination-limited, and version-sensitive. Restore requires a compatible MOS installation, and rollback is not guaranteed across data migrations.
- External packages remain unverified; publisher-key verification and cryptographic replay prevention are not yet implemented.
- Added repo-owned self-host service and backup agents. Managed reconciliation now maintains their systemd units, sockets, tokens, and Suite Manager mounts, while compatibility wrappers preserve the former update-agent paths.
- Added offline whole-suite backup and restore with mounted local, removable, and network destination discovery, capacity and free-space checks, cold volume archives, bundle validation, rescue copies, persistent job state, and capability-driven Suite Manager controls.
- Update and backup actions are now capability-driven: managed controls appear only when their corresponding host agent advertises support.
- Homepage customization can validate and apply generated external Caddy proxy routes through the service agent or
npm run caddy:external-proxies:apply, while explicit user-authored links remain untouched. - Added Cloudflare DNS-01 HTTPS configuration through Suite Manager, using a shared
DOMAIN,PUBLIC_URL_SCHEME, andMOS_TLS_MODEcontract for Caddy routes and managed Homepage links.
- Self-host reconciliation manages
mos-update-agent,mos-service-agent, andmos-backup-agent, their/runsockets,/etctoken files, and Suite Manager env/socket mounts. SUITE_MANAGER_UPDATES_MODEwas removed from active configuration.- Caddy now imports generated snippets from
deploy/vps/generated/caddy/*.caddy; DNS-01 mode also usesdeploy/vps/services/caddy/.envand requires HTTPS, a real domain, an ACME email, and a Cloudflare API token.
- Managed updates can recover when the only dirty file is the generated external-proxy Caddy snippet.
- Fixed onboarding clipboard feedback and hardened Vaultwarden onboarding against upstream UI changes.
- Updated application images and dependencies, including Seafile 13 and its native database, admin, and cache bootstrap settings.
- Replaced Seafile's Memcached service with Valkey and added a migration for existing installations.
- Improved self-host installer handoff so domain, Linux, and Suite Manager settings flow through one first-boot manifest, supported Ubuntu media can be fetched automatically, and installation remains human-confirmed.
- Added managed self-host updates through
mos-update-agent, including update-track selection, job status, full profiled image rebuilds, container recreation, and obsolete-service cleanup without removing persistent volumes. - Added named own-infrastructure migrations for compatibility changes during managed updates.
- Moved Homepage customization into Suite Manager-owned runtime config with allow-listed YAML, CSS, and JavaScript editing and validation.
- The Seafile cache service is now
seafile-valkey; cache configuration usesCACHE_PROVIDER=redisandREDIS_*variables instead ofMEMCACHED_*. - Self-host setup recognizes
UPDATE_TRACKandUPDATE_REF, and managed installs useSUITE_MANAGER_UPDATES_MODE=managed. - Homepage runtime config uses
HOMEPAGE_CONFIG_SYNC_TOKEN;services.yamlremains generated fromservices.template.yaml.
- Fixed Vaultwarden startup when shared SMTP is disabled, Suite Manager startup with default Homepage runtime state, self-host owner and domain propagation, ONLYOFFICE startup with newer images, and PostgreSQL 18 volume layout for Vaultwarden.
- Hardened the single-USB installer so it requires explicit confirmation, carries the primary user into bootstrap, and starts the stack after setup.
- Added deployment-aware update status in Suite Manager, release metadata checks, and manual self-host/VPS update commands with preflight safeguards.
- Reworked onboarding into dependency-based tracks after Vaultwarden credential setup.
- Added optional shared SMTP configuration consumed by Seafile and Vaultwarden.
Milestone release: MOS gained a validated self-host installation path on home-server hardware over LAN.
- Added an Ubuntu 24.04 single-USB installer builder with a clearly destructive boot entry and a ready-to-flash output image.
- Hardened the default stack against third-party calls by removing remotely hosted fonts and Homepage icons, disabling Vaultwarden relay push, and disabling Stirling PDF analytics by default.
- Fixed Vaultwarden credential-import onboarding and a Suite Manager runtime syntax error.
- Added the Ubuntu 24.04 self-host bootstrap path, canonical
appname.mos.homeandappname.mos.<your-domain>addressing, Cloudflare wildcard tunnel scaffolding, and unattended installation support.
- Hardened the default stack against third-party calls by removing remotely hosted fonts and Homepage icons, disabling Vaultwarden relay push, and disabling Stirling PDF analytics by default.
- Fixed Vaultwarden credential-import onboarding so the flow advances after manual confirmation.
- Improved first-run credential handoff from Suite Manager to Vaultwarden.
- Changed the default Docker Compose project name to
mos; generated networks and named volumes now use themos_prefix instead ofvps_. - Hardened local cross-platform operation with simpler
*.localhostrouting and Windows-safe script and entrypoint line endings.
- Added the authenticated Suite Manager control plane with persistent onboarding state and guided first-run setup.
- Made Suite Manager the single control-plane entry point, with Homepage linking into
/setup/. - Improved onboarding with Vaultwarden-first setup, guided Radicale connection, clearer completion, and a direct return to Homepage.
- Replaced the bootstrap-token gate with owner email/password authentication and signed sessions.
BOOTSTRAP_TOKENwas replaced by requiredOWNER_PASSWORDandSESSION_SECRET;SUITE_MANAGER_URLnow requires the/setup/suffix. - Removed
HOMEPAGE_PUBLIC_URLfrom the Suite Manager contract in favor ofHOMEPAGE_URL. - Added shared owner and integration inputs for Suite Manager and changed local/VPS Vaultwarden routing to HTTPS.
- Added the initial Suite Manager service with status reporting and Homepage health checks.
- Reworked VPS/local setup around shared Suite Manager inputs and service-level env templates.
- Simplified
vps:initandvps:doctorfor the new template layout and removed legacy.env.examplecompatibility. - Fixed
vps:rebuildso clean-slate rebuilds remove profiled service volumes and auth state.
- Added
vps:init,vps:doctor, andvps:upfor non-destructive VPS configuration and startup. - Added generated and shared secret expressions plus derived Base64 values in env templates.
First official release of My Own Suite, establishing the release foundation and initial Docker Compose application stack.