Server database

MultiTaction Canvus Server keeps its data in a PostgreSQL database. Every deployment type ships its own PostgreSQL. You do not install or configure PostgreSQL yourself.

The database holds user accounts, groups, permissions, the folder and canvas index, canvas content and the audit log. Uploaded files (images, videos, PDFs) are not stored in the database. They are files in the server's asset folder. See file locations.

Which database each deployment uses

	Linux standalone (.deb)	Windows standalone (MSI)	Containers
PostgreSQL version	18.6	18.6	17.11
Runs as	systemd service canvus-postgres	Windows service mt-canvus-postgres	container canvus-postgres
Address	127.0.0.1:5433	localhost:5432	postgres:5432 on the internal canvus-network
Data directory	/var/lib/canvus/postgres	%ProgramData%\MultiTaction\canvus\postgres	/canvus-data/postgres on the host
Database and user	canvus, canvus_admin	canvus, canvus_admin	canvus, canvus
Password	generated at install, stored in /var/lib/canvus/.postgres.pw	generated at install, stored in %ProgramData%\MultiTaction\canvus\.postgres.pw	POSTGRES_PASSWORD in podman-compose.yml

The Linux package uses port 5433 so that its database cannot collide with a system PostgreSQL that already uses the default port 5432.

The containers run a different PostgreSQL major version from the standalone installers. This matters only when you move data between them. See Migrating a standalone server to containers.

Who can connect

The bundled database accepts connections from the server's own host only.

• Linux and Windows standalone. PostgreSQL listens on the loopback address. It accepts only the canvus_admin user from 127.0.0.1 or ::1, with password authentication (scram-sha-256), and rejects every other connection.
• Containers. The canvus-postgres container publishes no port on the host. Only containers on the canvus-network bridge reach it, and they must give the database password.

The password files on the standalone installs are readable only by the service account (Linux: the canvus user, mode 600; Windows: SYSTEM and Administrators).

The connection between Canvus Server and its database is not encrypted. Canvus Server cannot use TLS on the database connection, and no setting changes that. With the bundled database the connection stays on the loopback interface (standalone installs) or on the private container network, so it does not cross your network.

Connection settings

Canvus Server reads the database connection from the [sql] section of mt-canvus-server.ini: hostname, port, databasename, username and password. On Windows, postgresql-path points at the bundled PostgreSQL binaries. In containers, the entrypoint writes these values from the POSTGRES_HOST, POSTGRES_PORT, POSTGRES_DB, POSTGRES_USER and POSTGRES_PASSWORD environment variables at every start. See configuration file.

Warning

Do not change the database password in only one place. In containers, POSTGRES_PASSWORD must match in the postgres and canvus services. On a standalone install, the installer has written the same password into the PostgreSQL user and into [sql] password.

Using an external PostgreSQL server

Canvus Server connects to whichever PostgreSQL server [sql] hostname and port name, and in containers POSTGRES_HOST and POSTGRES_PORT set those values. The installers and the compose file are built around the bundled database, though:

• The Linux mt-canvus-server service requires canvus-postgres to be running and waits for the bundled database on 127.0.0.1:5433 before it starts.

• --backup and --restore run the PostgreSQL client tools (pg_dump and psql) against the configured database.

• The connection to an external database is not encrypted either. Canvus Server cannot connect to a PostgreSQL server that requires SSL (for example a hostssl-only pg_hba.conf, or a managed database service that forces SSL), so such databases are not supported.

The bundled database is the supported setup: the installers create and tune it for you, so the server works without separate database administration. MultiTaction does not publish a list of supported external PostgreSQL versions. If you must use a database server of your own, place it on a trusted network segment next to Canvus Server, and contact MultiTaction support first.

Default tuning

The Linux and Windows standalone installers write the same performance settings into postgresql.conf:

Setting	Value
max_connections	200
shared_buffers	256 MB
effective_cache_size	1 GB
work_mem	4 MB
maintenance_work_mem	64 MB
max_wal_size	1 GB
autovacuum	on

The container image uses the PostgreSQL defaults of the official image. It also sets synchronous_commit to off for the canvus database. With that setting, a host crash can lose the last few transactions the database had already confirmed. The database itself stays consistent.

Database logs

• Linux and Windows standalone. PostgreSQL writes its own log files to the log folder inside the data directory. It starts a new file every day, or when a file reaches 100 MB. It logs warnings, errors, checkpoints, lock waits and schema changes. Old log files are not deleted automatically, so remove them yourself when you no longer need them.
• Containers. PostgreSQL logs to the container output. Read it with sudo podman logs canvus-postgres.

Canvus Server's own log is separate. See file locations.

Upgrades and removal

Canvus Server runs any database schema migrations itself when it starts on a new version.

When a new standalone installer bundles a newer PostgreSQL major version, the database has to be exported and re-imported:

• Windows. The installer exports the database before it replaces any files, then imports it into a new cluster. It keeps the old cluster on disk, renamed.
• Linux. The package does not export the database for you. If it finds a cluster from an older major version and no valid dump at /var/lib/canvus/upgrade/predump.dump, it stops and leaves the old cluster untouched. It prints the pg_dump command to run. After you create the dump, run sudo dpkg --configure canvus-server and the package imports it into a new cluster. It keeps the old cluster on disk, renamed.

See updating.

Never purge the Linux package

sudo apt remove canvus-server keeps the database. sudo apt purge canvus-server deletes /var/lib/canvus and /var/lib/mt-canvus-server, which is the whole database, every uploaded asset and the server logs. It also deletes mt-canvus-server.ini.

To back up the database together with the assets, use the server's backup command. See Server backup and restore.