Containers, one-click services and Redis/Memcached

#Overview

The three features on this page are connected:

In the Community edition these menus are marked as Pro and no new container instance can be created. Even if a license lapses, existing containers can still be stopped from the panel, and suspending or deleting an account covers them too. For the differences between editions see Pricing.

In a container installation on Docker or Railway, nested containers cannot run, and without systemd Redis/Memcached instances are unavailable too. These features work only on a server (native) installation. Details: Docker and Railway.

#Container runtime

#Installation and requirements

The Podman component is not installed by default. The server administrator installs it from Server Admin → Containers; it installs the distribution packages (podman, uidmap, slirp4netns or passt, fuse-overlayfs, catatonit) and delegates the cpu, io, memory and pids controllers to user managers. Installing it changes no account on its own: when an account opens its first instance, the panel prepares that account's subordinate ID range and persistent user manager.

For the runtime to become active, the server needs:

• Podman 3.4 or later, systemd and loginctl
• cgroup v2 (the default on Ubuntu 22.04+, Debian 12+ and AlmaLinux/Rocky Linux/RHEL 9+)
• the newuidmap and newgidmap tools

If something is missing, the screen tells you what. On AlmaLinux/Rocky Linux/RHEL, SELinux stays in enforcing mode and volumes are mounted with an account-specific label.

#Creating an instance

Each instance is a pod with one or more containers, running as units in the account's systemd user manager (Quadlet or podman generate systemd units, depending on the Podman version). There are two sources:

• Template: picked from the one-click service gallery; the wizard asks for the required fields and generates any passwords and keys left empty.
• Image: the user enters the image, HTTP port, extra ports, persistent volumes, environment variables, command and an optional health check (an HTTP path or a command).

An image needs a version tag or a digest (@sha256:…); the latest tag is rejected. That way an image never changes silently on a pull, and updating is a deliberate action in the panel. Short names such as nginx:1.27 resolve under docker.io.

#Domains, ports and restarts

Container ports are published on the host only on 127.0.0.1, on ports allocated from the 20000–29999 range; nothing is exposed directly. An instance with an HTTP port can be attached to the account's domains. It then also shows up under Applications and is served through the web server with the domain's SSL certificate. If another user's process takes over the HTTP port, the panel stops routing traffic to it and notifies both the account owner and the administrator.

The restart policy is on-failure (default), always or no. For services where the first visitor becomes the administrator or that ship with a default password, the panel adds a setup lock: until setup is finished and the lock is released, the domain is protected with a username and password generated by the panel.

#Day-to-day use

The instance page offers start, stop and restart, container logs, a container shell in the browser, environment variables (secret values are masked) and memory and CPU settings. The Images section lists the account's images and removes the ones no instance uses. When an instance fails its health check, the account is notified; the administrator can turn this off in the server settings.

An image update pulls a new pinned tag from the same repository, recreates the instance and waits for the health check; if that fails, it rolls back to the previous image. When a template image moves to a new publisher, the volumes are backed up first and restored from that backup if the new image does not become healthy.

#Volumes and backups

Persistent data lives in the home directory under ~/containers/<instance>/<volume>. Volume backups taken from the instance page are written to ~/container-backups as .tar.gz files; by default the container is stopped during the backup for consistency. Deleting an instance keeps its volumes by default, and an instance recreated under the same name picks up the old backups. Account backups also capture container volumes separately: Backups and migration.

#One-click services

The One-Click Services gallery is a template catalog on top of the container runtime; every service you install is managed as a regular instance on the Containers page. This release ships these templates:

Template images are pinned to fixed version tags. Mattermost Team Edition installs only on amd64 processors. A template retired from new installs disappears from the gallery, while instances created from it keep running. The Redis template in the gallery is a separate Redis running in the account's own container, independent of the Redis & Memcached feature below.

#Limits and isolation

#Package limits

Memory per instance is at least 64 MB (some templates require more), and CPU is set between 10% and 12800%, where 100% equals one core. Package details: Accounts and packages.

#Disk usage

Files written by container processes under subordinate IDs do not count toward the file system quota. The panel measures this data separately; when quota plus container data exceeds the package's disk limit, the account's containers are stopped, and new instances, starts and restores are refused until space is freed.

#Isolation

• Containers run as the account's own user (rootless), not as root.
• Every account gets its own subordinate ID range in /etc/subuid and /etc/subgid that never overlaps with other accounts.
• The user manager and its containers run in the account's resource slice; memory and CPU limits are enforced through cgroup v2.
• Images can be pulled only from allowed registries (default: docker.io, ghcr.io, quay.io). The administrator can edit the list and also enforce it at the Podman level through /etc/containers/policy.json; the original file is kept and restored when enforcement is turned off.
• Template passwords and secret environment variables are stored encrypted in the database and never written to unit files.

For account isolation in general see Account isolation.

#Administrator and reseller access

The Server Admin → Containers screen shows all instances, the Podman component, the registry policy, the default memory and the unhealthy-instance notification setting; instances can also be started and stopped from there. Installing the component and changing server settings are limited to the server administrator. Resellers see the instances of their own accounts and can set package limits if they are allowed to create packages.

#Redis and Memcached

The per-account cache does not use containers. Each account's Redis and Memcached instance runs in its own systemd unit, as the account user and inside the account's resource slice. Instances do not listen on TCP; they are reachable only through a unix socket in the home directory:

On the user page the account turns the instance on or off, sees connection details, configuration examples and statistics, flushes the cache and restarts it. The memory limit comes from the package and is 0 for new packages, so the service stays unavailable until the administrator assigns memory to the package. An instance accepts at most 512 concurrent connections.

The server components (redis-server, memcached) are installed from Server Admin → Redis & Memcached; on AlmaLinux/Rocky Linux/RHEL 10 the compatible Valkey is installed instead of Redis. The shared, passwordless instances that come with the distribution packages are switched off on install; the administrator can turn them on from the same screen. For page caching and the web server side see Web server and caching.