Health, monitoring and sizing
This page tells you how to check that MultiTaction Canvus Server is running, what to watch, and what hardware the installation pages ask for.
One server instance per deployment
Every Canvus Server deployment is a single server process with a single PostgreSQL database. Canvus Server has no clustering, replication, load balancing or automatic failover. Run one server instance per deployment.
Resilience comes from two things:
- Automatic restart. The service manager or the container runtime restarts the server when its process stops. See Automatic restart.
- Backups. Take regular backups and keep them away from the server. See Server backup and restore.
Health endpoint
GET /api/v1/server-info answers without authentication. It returns the server version and server ID. A response with HTTP status 200 shows that the server is up and serving requests.
curl -fsS https://canvus.example.com/api/v1/server-info
Add -k if the server still uses its self-signed certificate. See the server info API for the response fields.
Container health checks
The compose file defines a health check for both containers.
| Container | Check | Timing |
|---|---|---|
canvus-combined |
The mt-canvus-server process exists, and /api/v1/server-info answers on the HTTPS port (or, failing that, the HTTP port) within 5 s. |
Every 30 s, 15 s timeout, 3 retries, 120 s grace period after start. |
canvus-postgres |
pg_isready reports that the database accepts connections. |
Every 10 s, 5 s timeout, 5 retries, 30 s grace period after start. |
The canvus-combined check catches a server whose process is still alive but has stopped answering. After three failed checks in a row (about 90 s), Podman marks the container unhealthy. Read the status with:
sudo podman ps
sudo podman healthcheck run canvus-combined && echo healthy
An unhealthy status does not restart the container by itself. Restart it with sudo podman restart canvus-combined, then look at the logs.
Automatic restart
| Deployment | What restarts the server |
|---|---|
| Containers | Both services use restart: unless-stopped. When the server process exits, the canvus-combined container stops and Podman starts it again. |
| Linux standalone | The mt-canvus-server and canvus-postgres systemd units use Restart=on-failure with a 5 s delay. |
| Windows standalone | The mt-canvus-server service restarts the server inside the service after a failure, at most once every 5 s. It does not restart after a configuration error: fix the configuration, then restart the service. |
What to monitor
- Service or container state. On Linux:
systemctl is-active mt-canvus-server canvus-postgres. On Windows:Get-Service mt-canvus-postgres, mt-canvus-server. In containers:sudo podman psand the health status above. - The health endpoint from outside the server, through the same address your users use. This also catches DNS, firewall and certificate problems.
- Certificate expiry. When it starts, Canvus Server writes the certificate subject, names and expiry date to its log. It logs a warning when the certificate expires within 30 days and an error when it has expired. Clients refuse to connect with an expired certificate.
- License expiry. Admin area > Settings > License shows a warning when the license expires within 30 days. See licensing.
- Disk space on the volume that holds assets, backups and logs. Uploaded files, backups and log files all grow over time. See file locations and Server database.
- Server log errors. See file locations for where the log is.
Hardware requirements
The installation pages state these minimums:
| Deployment | Memory | CPU | Disk |
|---|---|---|---|
| Containers on Linux | 4 GB minimum, 8 GB recommended | 2 cores minimum, 4 recommended | 20 GB minimum, 50 GB recommended for production with asset uploads |
| Containers on Windows (WSL2) or macOS | 8 GB on the host minimum, 16 GB recommended, with at least 4 GB given to the Podman VM | 2 cores minimum, 4 recommended | 20 GB minimum |
| Windows standalone (MSI) | 4 GB minimum, 8 GB or more recommended | Not stated | 20 GB free minimum |
Linux standalone (.deb) |
4 GB minimum | 2 cores minimum | Not stated |
Running the containers with less than 4 GB has caused out-of-memory kills. The Linux standalone minimum of 2 cores and 4 GB is small enough for an entry-level cloud instance, for example on AWS or Azure.
Disk use depends mostly on how much content your users upload and how many backups you keep on the same disk.
Sizing for users and canvases
MultiTaction does not publish sizing figures by number of users, concurrent clients or canvases. Your license sets the maximum number of simultaneous Canvus clients. For a large deployment, contact MultiTaction before you choose hardware.