Container Apps

The Container Apps page lets you deploy and manage single-machine container workloads from the kopernik.us console.

What are Container Apps?

Container Apps are cloud virtual machines that run a managed Docker container. kopernik.us handles machine provisioning, networking, storage attachments, image pull, container start-up, and status tracking.

This is useful when you want a simpler deployment model than Kubernetes while still keeping control over:

machine size and region
VPC, subnet, firewall, and SSH keys
block storage volumes
container image and runtime configuration

You can create an app in two ways:

from a template, such as MySQL or OpenSearch
from a custom container image

View Container App instances

The table lists container app instances across your connected cloud accounts. Each row represents a managed app backed by a provider machine.

Common attributes include:

app identifier
provider
region
account
display name

Depending on layout and provider data, you may also see machine or container-related fields.

Table behavior

The table supports the same interaction model as other resource pages:

Reload refreshes visible data
Layout chooses visible columns
Add filters narrows the result set

See the Resource Filter documentation for filter syntax and behavior.

Use pagination controls at the bottom of the page to navigate between pages when there are too many apps to display.

When table data is being updated, table rows are displayed in italic and table controls become inactive.

Creating a new container app

Select Create in the toolbar to open the Add Container App page. The page requires an account with write access: pick one under Hardware settings, and Review and Create lists what is still missing until the app can be created.

Create flow

The create page is organized into sections:

Create from chooses between a template and a custom image
Container app properties stores optional metadata such as name and tags
Hardware settings configures provider account, region, machine type, base image, networking, SSH keys, and storage
Application properties appears for template-based apps
Image properties appears for custom-image apps
Runtime properties configures environment variables, ports, bind mounts, and restart policy
Review and Create summarizes the configuration and highlights missing requirements

Whichever way the app is created, the page starts with what there is nothing to ask about already chosen: an account, when it is the only one you can create in; the region that account works in, which is the only one it offers; and the machine image hosting the container, which is the newest operating system release with long-term support that the chosen machine type can boot. Each of them is yours to change.

Create from template

Use a template when you want kopernik.us to pre-fill image settings and expose only the relevant application properties.

Template-based apps typically provide:

the image to run
required and optional environment values
default ports
the container paths that store data, and how much storage each should have
the machine capacity the application needs to run well

For stateful software such as databases, templates declare data paths like /var/lib/mysql. If you do not map those paths to attached storage, data stays on the machine root disk and may be lost when the app is deleted.

Selecting a template then fills in the hardware it asks for, so that the app is sized for the application rather than for the smallest machine on offer:

the machine type becomes the cheapest one in the selected region meeting the template’s requirements. Choosing a machine type yourself replaces it for good; until you do, selecting another template or version chooses again. Where the region offers nothing that meets them, Review and Create says so and leaves the choice to you.
a volume is added under Hardware settings for each data path the template sizes, and each path is stored on its own volume. A volume is yours to resize or remove afterwards, and a request smaller than the provider’s smallest volume is raised to it.
Estimated cost counts the machine type and the volumes, so it changes as soon as a template is selected.

A region which does not offer block storage gets no volumes, and the template’s data paths stay on the machine root disk.

Volume bindings belong to the selected template: its declared data paths are the only ones you can bind, and changing the template asks where the new template’s own paths are stored. Review and Create lists the bindings the app is created with, and the container paths left on the root disk.

Choosing where a container path is stored

Each volume binding names one container path and what stores it on the machine:

a volume added under Hardware settings, which stores the data at the mount point the volume has. A volume added here is mounted at /mnt/disk1, /mnt/disk2, and so on, so there is usually nothing to type: add a volume, then pick it. The binding follows the volume, so changing its mount point moves the data with it.
Machine root disk (no dedicated volume), which binds nothing and leaves the container writing the path inside its own image. The data then shares the root disk’s fate and is lost when the machine is replaced.
Custom path…, which stores the data at a host path you enter. Use it for a path the machine already provides.

Two container paths can be stored on the same volume: the second one picked gets a sub-directory of the volume named after its container path, so the two do not write over each other.

A volume with no mount point cannot store a container path and is not offered. If a volume a binding uses is removed later, or loses its mount point, Review and Create blocks the creation until the binding is pointed somewhere else.

Create from custom image

Use a custom image when you want full control over the container definition.

Typical fields include:

image reference such as nginx:latest
optional image digest for pinning
optional registry credentials for private registries
runtime env vars and ports
bind mounts from host storage into the container, chosen the same way as for a template, with the container path entered by hand

Deleting a container app

To delete a container app, select one or more rows and click Delete. This action is disabled when the app is associated with an account that does not have write access.

Deletion may take time because kopernik.us must remove the backing machine and any related features. Status and progress are available on the Actions page.

If you are automating the same workflow outside the console, these references are the most relevant: