Frequently asked questions

It is the credential AInode uses to read an image from a private registry on your behalf. You store the registry URL, username and password once as a Registry Secret, and attach it to the image you register. Without it AInode cannot authenticate to a private registry, so pulling the image fails and no container can be created from it. Public images do not need one.

From the image registration form, next to the Registry Secret field. You provide: • Secret name: a unique name inside the group • Registry URL: the registry address (for example ghcr.io, docker.io) • Username: your registry username • Password: your registry password or access token Group secrets can be created by the group owner or an administrator. Secrets at the global scope are administrator only.

There is no allow-list. The registry address is whatever you enter, so Docker Hub, GitHub Container Registry, GitLab Container Registry, Amazon ECR, Google Container Registry, Azure Container Registry and self-hosted registries all work as long as they accept standard Docker authentication and are reachable from the cluster. One thing to plan for: the registry address cannot be changed after the image has been created.

Yes. Each value is encrypted with AES-256-GCM before it is written and is transmitted over TLS. Passwords are never stored in plain text. The API has no field that returns a secret value, so once saved a registry password cannot be read back out by anyone. Access tokens are still preferable to account passwords.

Create a new Registry Secret with the updated credentials and attach it when you register the image. The image edit screen shows a Registry Secret field, but a change made there is not saved yet — the update request does not carry that field. Until that is fixed, register the image again with the new secret, or contact us and we will move it for you.

No. A secret belongs to the group it was created in, and only images in that group can reference it. Create the secret again in each group that needs it. A secret that is attached to an image cannot be deleted while any image still references it, so cleaning up is safe by default.

Each resource tier has an hourly credit rate made of two parts: the hourly compute price and the hourly base volume price. The total shown on the resource is the sum of the two, and that total is what a running container draws per hour. Hours are rounded up. A container you ran for five minutes still costs one hour.

Compute is only billed while the container is running, so stopping it releases the compute portion of the rate straight away. The base volume is different. Its charge runs until the container is deleted, not until it is stopped — a container you stopped weeks ago and never deleted is still drawing credits for its storage. The balance shown on screen already accounts for this. If you are finished with a container, delete it rather than leaving it stopped.

The billing page shows the remaining credit balance for your account and the top-up history behind it. Per-container usage is on the pricing page as a chart and a table, so a group can trace where its credits went. A container appears there as two rows — one for compute and one for its base volume.

That depends on the image you selected. AInode publishes the HTTP ports the image declares, so an image that ships VS Code or Jupyter is reachable from the browser as soon as the container is running — nothing has to be installed on your own machine. 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. While a container is running, its endpoint appears in the container list as a link that opens in a new tab.

Upload the dataset once at the group level, then mount it from the container details page in the Dataset Mounts section — dataset mounting is not part of the create form. You choose a path under the fixed /mnt/dataset/ prefix. Datasets are mounted read-only, so the same dataset can be mounted into as many containers as you need instead of being copied per workspace.

A Container Instance runs your registered image on the shared cluster and is the usual choice for development and training. A Virtual Machine gives you a full machine with its own base volume, for cases where a container is not enough.