Skip to main content
io.net offers a simple and powerful interface for deploying containers using high-performance infrastructure. Whether you are running inference, training models, or hosting APIs, the Containers system gives you flexibility and speed. This guide will help you deploy using IO Cloud API keys on our Container clusters. For detailed API usage, refer to our API Reference.
Support for AWS ECR private images is not available at this time for Containers.

​
Deploy Container

Click the Deploy Container button to launch a wizard that guides you through the deployment process.

​
Container Deployment Wizard

The wizard has four steps: Recipes, Select Processor, Configure, and Deploy.

​
Step 1: Recipes

The wizard opens on Pre-Configured Recipes. A recipe is a ready-made deployment for one model: it carries the container image, the start command, the traffic port, the environment variables and the serving configuration, so the only choice left to you is the hardware. Recipes are built on serving stacks such as vLLM, llama.cpp and ComfyUI, depending on the model. Each recipe shows:
  • Tags describing the model and the hardware that suits it.
  • Matching hardware Selecting a recipe fills in the processor and the number of GPUs the model needs, so Step 2 opens with that hardware already selected.
  • Availability A recipe whose hardware has no capacity right now is marked Hardware Sold Out and cannot be selected. A recipe that does not fit the hardware available to your account shows the reason in its place. Select another recipe, or come back later.
To bring your own image instead, select Custom Deployment at the end of the list. This skips the presets and takes you through the remaining steps with every field empty.
Recipes are added and updated as new models are released. Use the wizard for the current list.

​
Step 2: Select Your Container Processor + Location

Choose the hardware and region for your deployment:
  • Available GPUs Search by GPU model and view:
    • GPU Model
    • GPUs per Container
  • Location Selection After selecting a GPU, you’ll see a list of locations showing:
    • Region (e.g. Canada, Germany)
    • Available containers per location
If you selected a recipe, the matching processor is already selected for you. Once both GPU and location are selected, proceed to the next step.

​
Step 3: Configure

Configure your container. A recipe fills these fields in for you, so review them instead of entering them:
  • Container Image (required) Example: myorg/myimage:latest
  • Image Type
    • Public Image
    • Private Image
  • Start Command Enter the start command in JSON array format, example:
  • Traffic Port (required) Default: 8000
  • Health Check (optional) An HTTP GET endpoint on your container that returns a successful (2xx) response when your application is ready. Recipes prefill the recommended path (for example /health); expand the Health Check box to change it, or leave it empty to disable health monitoring.
  • Environment Variables Click Add Variable to define key-value pairs. Options:
    • Normal Variable
    • Private Variable You can add or remove variables as needed.
Once all required fields are completed, click Next Step.
To avoid deployment failures:
  • Always define environment variables in the env_variables section.
  • Do not substitute variables directly in the entrypoint or args.
  • When referencing variables in the entrypoint, escape$as $$.
Example:
  • Correct: $${TEST_VAR} prints the variable value inside the container.
  • Incorrect: $TEST_VAR may cause deployment failure.
  • Always use env_variables for variable management.
For advanced users: There is a known issue where Terraform variable interpolation ($) may conflict with service-layer substitution. Escaping with $$ resolves this issue.
  • We request your endpoint every 10 seconds through the same route as your public traffic. Only a 2xx response counts as healthy; redirects are not followed.
  • The endpoint must respond without authentication.
  • Your deployment’s public URL is published once the health check passes. If no health check is set, the URL is published once the container is reachable.
  • Applications with long startups — for example, large models loading — may show as unhealthy until they begin responding. This is expected.
  • Health checks are monitoring only: a failing check never stops your container or blocks traffic that is already being served.
  • You can add, change, or remove the health check later via Adjust Deployment.

​
Step 4: Deploy

On the Deploy step, the choices you made in the process are displayed. Name your deployment, review the cost, and deploy.
  1. In the Container Name field, enter a name for your deployment.
  2. In the Number of GPUs per Container field, set how many GPUs each container runs on. The maximum is the GPU count of the processor you selected, and a recipe starts at that maximum. This field is shown only for hardware that offers more GPUs per node than a single container needs.
  3. Under When we can’t get all your GPUs, choose what happens if we cannot start every container you asked for:
    • Keep running, extend the rest Launch every container we can and reuse the time you already paid: the running ones stay up longer instead of being refunded. This is the default.
    • Keep running, refund the rest Launch every container we can. Containers that can’t start are refunded, the rest keep their original runtime.
    • Fail cluster completely If any container can’t start, cancel the whole deployment and refund you in full.
  4. In the Replicas field, select how many copies of the container to deploy. More replicas will increase the cost. This field is shown only for hardware that offers replicas.
  5. Review all the details of your cluster, including the Total Cost.
  6. Click Pay & Deploy.

​
View Cluster

After payment is processed, the Containers list opens and you can view your cluster loading. Open your cluster from the list to reach its detail page. On the detail page, each container shows a Public URL field once it is ready, and a Check Logs button that opens a live view of its output. The log view has separate stdout and stderr tabs, a filter box (prefix the text with ! to invert the match), and options to follow new lines, copy or download the output, and open it fullscreen in a new window.

​
Container Health Status

If a health check is configured, each container on the deployment page shows a heart icon reflecting the latest health check result: The health status updates within a couple of minutes of a change. A newly deployed container may briefly show as unhealthy while your application starts up — once it responds successfully, the status turns green and the public URL is published.
🚧 Troubleshooting Container Issues If your container is not running, you do not need to delete the whole cluster. Instead, open the deployment settings, adjust any incorrect details (for example, the image name or registry credentials), and redeploy. This way, you avoid the minimum 1-hour charge for deleting and recreating a cluster.