Backups & Upgrades - Speakeasy.im Docs

What to back up

What	Why	Where (Linux guided install)
Database	Accounts, rooms, messages, roles, and file attachments	`/var/lib/speakeasy-self-host/speakeasy.sqlite`
Config / env file	Includes your server's auth secret; preserve it with the database	`/opt/speakeasy-self-host/config/server.env`
TLS certificates	Preserves certificate state for recovery	`/opt/speakeasy-self-host/control/certs`

On Windows, the packaged installer keeps all server state under one data root, %ProgramData%\SpeakeasySelfHost: the database at data\database.sqlite, the config / env file at config\server.env, and TLS certificates under certs\. The SQLITE_PATH line in server.env names the database file your server uses. Attachments are stored inside the database, so there is no separate uploads folder to remember.

These are default packaged/guided paths; use the effective install/data/control/config roots recorded for your installation.

Taking a backup (SQLite)

Linux

Stop the server so the database file is quiescent:
```
sudo systemctl stop speakeasy-self-host
```
While the service is stopped, back up all three effective Linux roots: data (default /var/lib/speakeasy-self-host), config (default /opt/speakeasy-self-host/config), and control (default /opt/speakeasy-self-host/control). Preserve file owners and permissions, and keep the database and its SQLite journal files together.

Start it again:

sudo systemctl start speakeasy-self-host

Windows

In PowerShell running as Administrator, stop the server so the database file is quiescent:
```
Stop-Service SpeakeasySelfHost
```
While the service is stopped, copy the whole effective data root (default %ProgramData%\SpeakeasySelfHost). Its folders grant access only to SYSTEM and Administrators; keep those permissions on the copy, and keep the database and its SQLite journal files together.
Start it again:
```
Start-Service SpeakeasySelfHost
```

Do not open the database with your system's sqlite3 tool. The server bundles a newer SQLite than many operating systems ship, and an older sqlite3 command-line tool can report the schema as malformed even though the database is healthy. Do not use it to inspect, check, or repair the database; back up and restore by copying the stopped server's files as described above.

For advanced installs using PostgreSQL, use pg_dump for the database and back up configuration and control state separately.

Restoring

Install the same server release on the recovery machine. Same-release recovery is the baseline; cross-version restore requires the release's supported procedure.
Stop the service. Restore every root you backed up (Linux: the data, config, and control roots; Windows: the data root), preserving owners, permissions, and the configured paths.
If the machine's IP or domain changed, update DNS and the domain settings in server.env before restarting.
Start the service and verify accounts, rooms, and attachments from the backup.

Upgrading the server

Take a backup first (above).
Follow the release's supported upgrade procedure. For a release that uses the guided installer's upgrade mode:
```
sudo ./install.sh --upgrade
```
The upgrade replaces the application code, preserves all data and config untouched, restarts the service if it was running, and waits for the health check to pass. Database migrations apply automatically on startup.

On Windows, follow the release's supported self-host installer upgrade procedure. The packaged data root defaults to %ProgramData%\SpeakeasySelfHost; back up your effective roots before upgrading.

Upgrading clients

Desktop clients notify users of updates (Windows and AppImage can self-update after confirmation; Linux .deb/.rpm are manual). Use the client/server versions and upgrade order declared for the release.

Test your backup once. A backup you have never restored is a hope, not a backup. After your first backup, restore it onto a spare machine or a temporary directory and confirm the server starts.