Containers

Containers runs prebuilt container images on your account: a single container, or a stack of several containers built from a compose file.

Everything runs under your own account, without root. A container is one of your processes: your account's resource limits apply to it, it can reach your databases, it starts automatically with the machine, and it restarts under a policy you choose.

note

Containers need persistent services, which let your work keep running while you're signed out. Your provider turns them on per account; if the page refuses with such a message, ask your provider.

Create a container

Two ways:

• With a form.
• From a command line. Paste a podman run or docker run command, e.g. from a project's README, and the panel translates it into the same fields. It ignores flags that mean nothing under supervision (-d, --rm, -it) and reports anything else it can't translate; nothing is dropped silently.

The Image is a full reference such as docker.io/library/nginx:latest. A short name also works: nginx means the official image on Docker Hub. The panel pulls the image when the container first starts.

No registry credentials

The panel doesn't manage them. An image must be publicly available, or already present from a pull you did over SSH.

Ports

Publish Ports takes one hostPort:containerPort mapping per line, optionally with /udp.

A published port is not open to the Internet

It binds your account's private IP address. To serve a container on a website URL, publish a port and attach it to the site with a Mount Port mount; the panel's proxy handles TLS and the public side. As a shortcut, the port's page in the Podman section offers to create the mount for you.

Volumes

Volumes takes one source:destination entry per line. Add :ro for read-only access.

Form	Kind	Right for
A plain name, e.g. pgdata	A named volume. The container runtime creates and keeps it.	A database, and other state you never edit directly.
A path, e.g. ~/mysite/uploads or data/cache	A bind mount from your home directory. Paths are relative to your home, and ~ works.	Files you also touch with the file manager or SSH.

A quirk of rootless containers

A file that a non-root container user creates inside a bind mount appears in your home directory owned by a mapped helper user ID, not by you. For data only the container touches, prefer a named volume.

Environment variables and secrets

Two fields, with one difference that matters:

Field	Format	Stored where
Environment Variables	One KEY=value per line.	In the panel's configuration. Right for an ordinary setting.
Environment Files	Paths to files in your home directory, relative to your home; ~ works.	The panel stores only the path. The container reads the contents straight from your home directory at start. They never enter the panel's database.

Put a password or an API key in an environment file

If the file is missing, the container doesn't start. That's deliberate: a typo can't silently start an app without its secrets.

Health checks

A Health Check Command runs inside the container at an interval. If the container keeps failing it, the runtime stops the container and the restart policy applies, so a container that runs but doesn't work becomes one that restarts.

You control four values:

• Interval: how often the check runs
• Timeout: how long one check may take
• Retries: failures in a row before the container counts as unhealthy
• Start Period: a window after start in which a failure doesn't count

Type none as the command to turn off a health check built into the image.

Restart policy and resources

Policy	Behavior
always (default)	Restarts after a failure and after a clean exit. What a service needs.
on-failure	Restarts only after a failure.
no	Never restarts.
unless-stopped	Accepted for compose compatibility; behaves as always here.

Each container can have a Memory Limit, such as 512m or 2g, and a Shared Memory Size. All your containers together also sit under your account's memory, CPU, and process caps. See Quotas and limits.

Stacks

A stack runs several containers as one unit. Paste your compose.yml and the panel builds one container per service.

The common compose vocabulary is supported: services, images, ports, volumes, environment variables and files, health checks, restart policies, depends_on, networks, and labels.

Read the import warnings

Not everything in the compose format is supported. Whatever isn't produces a warning at import that lists exactly what was skipped, so the result can differ from docker compose up. One notable gap: ${VARIABLE} interpolation isn't applied.

How a stack behaves:

• The members share a network namespace. They reach each other on localhost, and the service names from the compose file also resolve.
• Published ports from all members bind your account's private IP address, as usual. Expose them with mounts.
• depends_on sets the start order. With condition: service_healthy, a member waits until its dependency's health check passes.
• A named volume gets the stack name as a prefix, e.g. mystack_pgdata, following compose conventions.
• You can't edit or remove one member alone. Edit the stack's compose text and save; the panel regenerates the members and restarts the ones that changed.

tip

Restart on the stack restarts the whole unit in the right order. Use it rather than restarting members one at a time.

A running container: status, logs, console

Each container and stack shows its live status (active, failed, starting, and so on) with Start, Stop, and Restart actions. Logs streams the container's output live in a browser terminal.

The Containers workspace also has a Podman section: a live view of what the container runtime really holds, running and stopped containers, downloaded images, networks, volumes, pods, and listening ports. It's the authority when the managed view and the real state seem to disagree, and it offers a console into any running container for debugging.

Update to a newer image

The panel doesn't update images automatically.

Your tag	How to update
A pinned tag, e.g. postgres:16.3	Change the tag and save. The runtime pulls the new image at the next start.
A moving tag, e.g. latest	Remove the downloaded image in Podman's Images section, then restart the container to force a new pull.

tip

A pinned tag plus a deliberate update gives a predictable result.