Skip to content

Container installation

This section describes how to install Canvus server using containers (Podman or Docker). This is the recommended method for new deployments in Canvus 26.4.0 and later.

Note

For existing bare-metal installations (using .deb or .exe installers), see Linux package install or Windows installer.

Why containers?

  • Simplified deployment --- all dependencies are bundled in the images
  • Consistent environment --- the same image set works on any host that runs Podman or Docker
  • Easy upgrades --- pull new images and restart
  • Isolated --- no system-level package installations or service configuration

Why Podman?

Podman is recommended over Docker for enterprise deployments:

  • Free for enterprise --- no licensing restrictions (Docker Desktop requires paid subscriptions for organizations with more than 250 employees or more than \$10M annual revenue)
  • Drop-in replacement --- same commands and compose files
  • Rootless by default --- better security without a background daemon

The compose files work with Docker; Podman is recommended to avoid Docker Desktop licensing exposure.

Architecture (26.4.0)

The production deployment is three containers on an internal bridge network (canvus-network):

  • canvus-combined --- Ubuntu 24.04 image bundling the C++ server (mt-canvus-server) and the Node.js web-proxy gateway. The web-proxy listens internally on port 5805 and serves the unified React web-client (SPA) directly. The container publishes 80 (HTTP redirect → 443) and 443 (HTTPS) to the host.
  • canvus-postgres --- PostgreSQL 17 (managed by the canvus-postgres container) with the Canvus schema applied on first start.
  • canvus-media --- mediasoup SFU for WebRTC video routing and FFmpeg for HLS transcoding. Required when CANVUS_WEBRTC_ENABLED=true (the default in 26.4.0). Exposes UDP port range 40000-40100 for WebRTC media and an internal WebSocket on port 4443 for signaling relay from canvus-combined.

Image paths (registry docker.multitaction.com):

  • docker.multitaction.com/mt-public/canvus-server-images/combined:stable
  • docker.multitaction.com/mt-public/canvus-server-images/postgres:stable
  • docker.multitaction.com/mt-public/canvus-server-images/media:stable

These public images pull anonymously --- no registry login is required. The compose file you download pins to the :stable channel; see Container image tags and channels to choose a different tag.

Note

The server image itself is Linux. Canvus 26.4.0 is Linux-only on the server side --- there is no native Windows or macOS server binary. On Windows and macOS you run the same Linux images inside a Podman Machine or Docker Desktop VM. See the Windows and macOS pages below.

Quick start (Linux host)

# 1. Install Podman
sudo apt install -y podman podman-compose

# 2. Download the compose file (pinned to the :stable channel)
wget https://canvus-downloads.multitaction.com/server/podman-compose.yml

# 3. Start services (public images pull anonymously — no registry login needed)
sudo podman-compose up -d

# 4. Open https://localhost and login (default admin@local.local / Taction123!)

Container image tags and channels

The public images are published to named channels so you can choose how closely you track updates. Set the tag on each image in your podman-compose.yml:

  • :stable --- the recommended channel, and what the downloaded compose file pins to. It always points at the newest generally-available release. To move forward, pull and restart:

    sudo podman-compose pull
sudo podman-compose down
sudo podman-compose up -d

  • :latest --- an alias of :stable, for tooling that pulls without an explicit tag.

  • :<version> --- an immutable pin to one release (for example :26.6.0). Use this for a reproducible deployment that never changes underneath you. A version-pinned compose file is also published alongside each release.
  • :dev --- the latest pre-release build, for testing fixes ahead of a release. Not for production.

Warning

Always keep the three images (combined, postgres, media) on the same tag. Mixing channels or versions across the three services is not supported.

Verifying image signatures

All public images are cryptographically signed with Microsoft Azure Trusted Signing, using Notation (COSE signature format). The signature is bound to the image digest, so it stays valid across the floating channel tags.

Operators with supply-chain requirements can verify an image before deploying it with the notation CLI, configured with MultiTaction's published trust policy and certificate identity. Verification confirms the image was published by MultiTaction and has not been altered. Contact MultiTaction support for the trust policy and certificate material if you intend to enforce signature verification in your environment.

Platform guides

  • Linux --- production deployment
  • Windows --- development/test via Podman Desktop + WSL2
  • macOS --- development/test via Podman Machine