Skip to content

Container installation

This section describes how to install Canvus Server using containers (Podman or Docker).

Which install do I want?

Container and standalone are both current, supported deployment methods --- see Choosing an installation method. For legacy installations from Canvus 3.x and earlier, see Legacy - Linux or Legacy - Windows.

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 default production deployment is two containers on an internal bridge network (canvus-network):

  • canvus-combined --- Ubuntu 24.04 image bundling the C++ server (mt-canvus-server) with an in-process Go gateway that serves the unified React web-client (SPA) directly --- there is no separate Node.js process. The container publishes 80 (HTTP redirect → 443) and 443 (HTTPS) to the host.
  • canvus-postgres --- PostgreSQL, pinned to 17.11 (managed by the canvus-postgres container), with the Canvus schema applied on first start. The standalone installers bundle a different PostgreSQL major version (18.6) --- see PostgreSQL version note.

A third service, canvus-media (mediasoup SFU for WebRTC video routing and FFmpeg for HLS transcoding), exists to support WebRTC video streaming, but WebRTC is coming soon and is disabled by default in 26.4.0. The canvus-media service ships commented out of the default compose file, and CANVUS_WEBRTC_ENABLED defaults to false. Once enabled, canvus-media 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 --- only needed once you enable the coming-soon WebRTC feature; not pulled by the default compose file.

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 log in with the CANVUS_ADMIN_EMAIL /
#    CANVUS_ADMIN_PASSWORD you set in podman-compose.yml

Set the admin email and password before you deploy

Canvus Server has no built-in default admin account. The admin user is created on first start from the CANVUS_ADMIN_EMAIL and CANVUS_ADMIN_PASSWORD environment variables in the canvus service of podman-compose.yml. The downloaded compose file ships those variables set to example values (admin@local.local / Taction123!) so the stack is usable immediately for evaluation --- change both before deploying for real use. If you deploy the compose file unedited, those example values are what gets created, so anyone who can reach your server before you change them can log in as an administrator.

A few things operators new to this setting often ask:

  • CANVUS_ADMIN_EMAIL does not need to be a real, routable email address --- it is only used as the admin's login name. Any unique string in email format works.
  • CANVUS_ADMIN_PASSWORD is only checked against the server's password policy, which by default requires a minimum length of 8 characters and does not otherwise require a mix of letters, numbers, or symbols. The shipped example, Taction123!, happens to include all three, but that mix is not itself a requirement unless you configure stricter rules --- see Password policy.
  • Set both variables to your own values in podman-compose.yml before podman-compose up -d, so the example values are never actually created. If you already started the stack with the example values, sign in once and change the admin password immediately instead.

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 --- the tag tooling picks up when it pulls without an explicit tag. On this registry :latest points at the same build as :dev, not at :stable, so an untagged pull gets a pre-release image. Always set the tag explicitly.

  • :<version> --- an immutable pin to one release (for example :26.07.9). 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 combined and postgres on the same tag (and media too, once you enable WebRTC and add it to your compose file). Mixing channels or versions across 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