Run a Docker image

An AppVM is a Docker or OCI image booted as its own virtual machine. It has its own kernel and its own disk, and no container engine runs inside it. The machine is the boundary.

You keep the parts of the container workflow that matter: the image you already publish, environment variables, restart policies, health checks, and logs.

Import an image

An OCI image becomes a template before it can boot. Open AppVM images under Compute and add one.

1. Find the image.

   Search the public catalog, or type a full image reference yourself. Typing the full reference is the way in for a private or self-hosted registry, with credentials when the registry needs them.

2. Let the host convert it.

   Virtainer Free pulls the image and converts it into a bootable template. This happens once per image, on the host.

3. Check the result.

   The template records what the image declared: its entrypoint and command, environment, working directory, user, and health check.

You can also build a template from a Dockerfile with a build context, or from a git repository, and rebuild it later from the same source.

Templates and machines are independent

Creating an AppVM makes a full copy of the template, so a template can be deleted without touching machines already running from it.

Create the AppVM

Open Instances under Compute and create one from your template. Size it, attach it to a network the same way as a classic VM, set environment variables, and choose a restart policy.

Before you create it, it is worth knowing whether your image runs unchanged. Most service images do. Base images such as alpine, debian, node, and python exit immediately, because their entrypoint is an interactive shell. Will my image run? covers this in one page.

Publishing a template

A template built on this host exists only as a disk image here. Publish on a ready template row pushes it to a registry so another host can pull it instead of building it again.

1. Choose the registry, and give the namespace/repo and tag.
2. Supply credentials for that registry. They are required, and they are not written to logs.
3. Watch it go. The push runs in the background, and the Logs button shows its progress live.

What gets published is what this host is running

Publishing reconstructs the image and checks that its layers match the template you are running before it pushes anything. If they do not match, the push is refused and tells you what to do first: rebuild a template you built here, or redeploy one you imported. Templates created before this check existed compare differently, so a build-type template may need one rebuild first. The dialog says so before you fill anything in.

Free hosts can publish to Docker Hub and Quay. A failed push turns its status label into a button: opening it shows why the host stopped, along with the raw push output as evidence.

Restart policies

Policy	Behaviour
no	Never restarted automatically
always	Restarted whenever the workload exits
on-failure	Restarted only on a non-zero exit

Restarts back off from 2 seconds up to a 5 minute ceiling, and the counter resets after the workload has stayed up for 30 seconds. A machine you stopped yourself is never restarted automatically.

Persistence

The system disk is a private copy of the template and survives stop and boot. It does not survive a redeploy, which resets it from the new template on purpose.

Anything you need to keep across a redeploy belongs on a data volume. See Data volumes.