How YunoHost's Per-App Isolation Shapes SSO and Backup Decisions

The Problem: Self-Hosting Without a Platform Contract

Most self-hosters start by dropping a Docker Compose file on a VPS. That works until an upstream update changes a config format, a database migration fails, or you need to restore one service without rolling back the whole server. YunoHost takes a different approach: every installed application gets a dedicated system user, an isolated filesystem under /var/www/<app>, and a declared relationship with the platform's SSO and backup subsystems. This post examines how that isolation decision shapes single sign-on integration and backup reliability, and where the trade-offs appear.

Isolation by Design: One User, One App

When you run yunohost app install <appid>, the package manager creates a dedicated system user and sets up a home directory at /var/www/<appid>. The app's files and runtime state live in that tree, owned by that user. No other app can read them without explicit permission.

This isn't just permission hygiene. It lets the platform capture an app's state—code, config, data, and database—by archiving the app's directory and its associated database. Because the app's footprint is isolated under its own user and path, the backup command can snapshot it without manually mapping volumes. Contrast this with a typical Docker setup where you must track each volume and database by hand.

SSO Integration: The Package Declares the Contract

YunoHost's built-in SSO (SSOwat) authenticates users against the local LDAP directory. For an app to participate, its package must wire the app into SSOwat and LDAP during installation. If the upstream application supports generic OIDC or LDAP, the packager configures those settings. If the upstream only has a local login form, the app may still present its own credentials screen even after installation. That distinction matters: SSO integration is package-dependent, and some apps retain independent login forms.

You can verify whether a given app uses single sign-on by checking the web admin SSO settings or /etc/ssowat/conf.json after installation. The file records how each app is registered with SSOwat, which tells you whether the app receives the authenticated identity or is merely protected by it.

Worked Example: Installing and Verifying a Packaged App

Assume a fresh YunoHost server with a valid domain and reachable HTTP/HTTPS ports. We'll install an official blog package, confirm how it registers with SSO, and trigger a backup.

# List packages to confirm the app ID
sudo yunohost app list | grep wordpress

# Inspect the packaged version and maintainer
sudo yunohost app info wordpress

# Install (interactive; accepts defaults for domain/path)
sudo yunohost app install wordpress

# Check the SSOwat configuration for this app
sudo cat /etc/ssowat/conf.json

# Create a backup and confirm the app appears in the archive list
sudo yunohost backup create
sudo yunohost backup list

Run these commands as root or via sudo on the YunoHost host. The yunohost app info step is critical: the packaged version often lags upstream. If you need a specific release, check the manifest's version field before proceeding.

Expected checks: the SSOwat configuration should show an entry for the installed app. The backup list should display an archive containing the app. If the app ID doesn't appear in the available list, it may not be packaged for your YunoHost version.

Trade-off: Packaging Lag and the Manual Installation Path

The isolation model works because the package maintainer mediates between upstream releases and the platform's contracts. The downside is version lag. Official packages are community-maintained and may trail upstream releases. You cannot simply run a manual upgrade inside /var/www/<appid>—the package owns that tree, and direct edits can break the next yunohost app upgrade or backup restore.

If you need a newer version, you have two supported options, each with consequences:

1. Wait for the package update (safest, but delays security fixes).
2. Install the app manually outside the official repository (loses automatic updates, backup integration, and SSO management).

This is the practical engineering decision: YunoHost optimizes for reproducible, platform-managed operations at the cost of upstream velocity. For many self-hosters, that trade-off is the right one—until it isn't.

Actionable Closing: Verify Before You Commit

Before adopting YunoHost for a new service, run the verification steps on a test VM:

• yunohost app info <appid> — confirm packaged version and architecture support.
• Install the app, then check /etc/ssowat/conf.json or the web admin SSO settings to confirm whether the app uses single sign-on.
• Run yunohost backup create and inspect the resulting archive structure to confirm the app's data is included.

If the app isn't in the official catalog, assume you'll own the integration work. The platform's strength is its opinionated contracts; its limitation is that those contracts move at package-maintainer speed. Choose the path that matches your tolerance for maintenance versus control.