Running your first container
A walkthrough of the whole path: joining a group, registering an image, creating a volume, filling in the create form, and managing the container once it is up.
Sign in and pick a group
Accounts are issued through your organisation's login, so there is no separate signup form. After signing in you land on Home, which lists the groups you belong to.
Almost everything in AInode is scoped to a group. Images, volumes, resource tiers and containers all belong to one, and you can only pick from what the group you selected contains. If Home shows no groups, create one under Group Workspace or ask a group owner to invite you before continuing.
Register a container image
A container always starts from an image you have registered. Open Image from the sidebar and add the registry address of the image you want to run.
Public images work with the address alone. For a private registry you also need an ImagePullSecret, which stores the registry username and password so the cluster can authenticate on your behalf. Register the secret once per group and every image in that group can reference it. Without it the pull fails and the container never leaves the Creating state.
The same form lists the ports the image serves. Each row carries a protocol and an exposure, and a new row defaults to External — that is what later turns into a link you can open from the browser.
Prepare a volume for your data
Anything written inside the container's own filesystem is gone when the container is deleted. Put work you want to keep on a volume instead. Volumes belong to the group, so the same one can be attached to several containers over time.
You can create a volume ahead of time from the group's volume list, or create it inline from the container form with Create Volume.
Datasets are not quite the same. You upload one once at the group level, but you mount it from the container's detail page after the container exists — dataset mounts are not part of the create form. They land under /mnt/dataset/ and are mounted read-only, so several containers can read the same copy.
Fill in the create form
The form is six sections, top to bottom. Name, Image and Resource are required; the rest have workable defaults.
Name the container and decide whether it should stop itself. The name has to be a DNS-1123 label — up to 63 lowercase letters, digits and hyphens, starting and ending with a letter or digit. Auto-stop shuts the container down after a period of inactivity.
Pick one of the images registered to the group. The picker only lists that group's images, so if the one you want is missing, register it first.
Pick the machine size. Each tier shows its CPU, memory, GPU and hourly credit rate, so you can compare cost before selecting. Tiers available to you depend on the group.
Attach one or more volumes and give each a mount path. Paths are always created under /mnt/volume/, and you supply the part after it. Two volumes cannot share the same mount path, and a path cannot contain . or .. segments.
Key and value pairs handed to the process, for things like an API token or a project name. Keys must be unique. Toggling the eye icon marks a value as secret and masks it in the form.
The ports the container serves. Rows are filled in from the image you selected, and each carries a protocol and an External or Internal exposure. Add a row only when the image serves something it did not declare.
Open the workspace
After you submit, the container sits in Creating while the image is pulled and the volumes are attached. How long that takes depends mostly on the image size — a first pull of a large CUDA image is slower than every pull after it.
Once the status turns Running, the container's endpoint appears in the container list as a link that opens in a new tab. What you get there comes from the image: AInode publishes the HTTP ports the image declares, so an image that ships VS Code or Jupyter is reachable from the browser with nothing installed locally and no SSH keys to distribute. AInode does not add an editor to an image that has none — if you bring your own image and want a browser editor, the image has to provide it and expose its port.
Container states
Start and Stop are only offered when the current state allows it, so a control being greyed out is usually the answer to "why can't I start this".
| State | What it means | Available action |
|---|---|---|
| Creating | The image is being pulled and volumes attached. No endpoint links yet. | Wait |
| Running | The workspace is up and drawing credits at the tier's hourly rate. | Open · Stop |
| Terminating | A stop was requested and the pod is shutting down. | Wait |
| Terminated | Stopped. The pod is gone but the container record and its volumes remain. | Start · Delete |
| Failed | The container could not come up. A bad image address or a missing ImagePullSecret is the usual cause. | Start · Delete |
| Deleting | The container and its record are being removed. | — |
Keeping credit use down
A running container draws its resource tier's hourly rate whether or not you are typing in it. Three habits account for most of the difference between accounts that run out of credit and accounts that do not.
An idle GPU container is the most expensive thing in the platform. Auto-stop ends the session for you.
Stopping a container is cheap and safe when your data lives on an attached volume rather than inside the image.
Do data prep and debugging on a CPU tier, then recreate the container on a GPU tier for the training run itself.
Published hourly rates for every tier are in the resources and credits table, and your remaining balance and per-container usage are on the Billing and Pricing pages. One thing the rate table does not show: the base volume keeps billing until the container is deleted, not until it is stopped. Delete the containers you are finished with rather than leaving them stopped.
Something not covered here
The FAQ goes into registry credentials, group permissions and billing in more detail.