Containers beta

LXC containers (family container): lightweight Linux systems with their own address, hostname and root access - optionally with a GPU. Containers are being rolled out and are available to the users and teams in the rollout.

More coming

Detailed documentation for containers will follow here.

Ordering

You choose:

• a plan - vcores, memory_mb, swap_mb, disk_gb, and gpu for GPU plans,
• a location, a template (the operating system) of that location and a network,
• optionally an SSH key of your team (installed for root), a hostname, a post-install script and LXC options.

The root password is mailed to the team owner. See Order attributes → Container.

Templates

A template is the operating system a container is created from. The catalog lists the templates of each location (options.locations[].templates[]), for example Debian, Ubuntu and Fedora releases. For each template it tells you:

Field
supports_post_install_script	whether the template can run a post-install script
gpu_vendors	the GPU vendors the template supports (GPU-ready templates)
driver_version	the host GPU driver the template needs, if any

Every container gets its own SSH host keys and machine id on first start.

Post-install scripts

Run a script of yours once, as root, right after the installation or a reinstall. For containers this works over SSH: the Console briefly puts a one-time key into the container and connects as root. So:

• the template must start sshd at boot and allow root login with keys - only templates with supports_post_install_script qualify (e.g. Debian and Ubuntu; not Alpine),
• do not disable sshd or root key logins before your script has finished, and do not reboot from the script.

See Post-install scripts.

LXC options

For software that runs its own containers inside the container - for example rootless Podman - you can order LXC options:

Option	For
feature fuse	FUSE file systems such as gocryptfs
feature keyctl	kernel keyrings
device tun	/dev/net/tun: rootless networking (pasta/slirp4netns), VPNs

Nesting is always on. The options stay through reinstall, backup restore and snapshot rollback. See LXC options.

GPU containers

GPU plans give a container a GPU - exclusive (the GPU is the container's alone) or shared (several containers use it, without memory or compute isolation). GPU plans are available to the users and teams in the GPU rollout. The catalog shows each plan's GPU (vendor, model, vram_gb, mode, count) and the GPUs of each location; use the catalog filters to find them.

• GPU plans need a GPU-ready template.
• The GPU driver's user space is not part of general templates: its version must match the host's kernel driver exactly, so install it inside your container for the driver version the host runs (for NVIDIA, readable from /sys/module/nvidia/version).
• A GPU container keeps its GPU through reinstall, backup restore, snapshot rollback, a billing suspension and a transfer. Deleting it gives the GPU back at once.

Managing

Feature
Power	start, stop, shutdown, reboot
Reinstall	with one of the templates available for the container - all data and snapshots are lost; address and hostname stay; the new root password is mailed to the team owner
Backups	create, restore, delete
Snapshots	create, roll back, delete
Rename	the hostname inside changes with the next restart
Deletion protection	while on, the container cannot be deleted
Deletion	kept for 14 days (support can restore it), then purged