Last Updated: October 13, 2026
SaladCloud Infrastructure
SaladCloud is a distributed network with nodes located worldwide, ranging from esports arenas to personal computers.
This global network allows us to offer computing resources at exceptionally low prices and gives us the ability to grow
the network by hundreds of nodes a day when needed.
It is important to understand that as a result, the nodes powering our network can disconnect at any time, stopping
container instances running on the node. When this happens we automatically reallocate these instances to a new node as
quickly as possible.
Although some nodes may remain connected for days at a time, maintaining constant uptime requires multiple replicas for
redundancy.
Priority Levels
Priority levels let you balance interruptions and cost savings according to your needs. Container Groups run at one of
four priority levels on our network: “High”, “Medium”, “Low”, or “Lowest” (formally “Batch”). Lower priority levels have
reduced costs. Higher priority container groups can preempt lower priority ones if a higher-paying job becomes
available. Pick the lowest priority level that meets your interruption tolerance when you deploy. If instances at a
lower priority level are being interrupted too frequently for your needs, you can raise the priority of a running
container group at any time. See Changing Priority.
After adding a GPU to your container group, you can choose between priority levels. At the highest priority level, your
container group instances will not be interrupted by other workloads. However, high priority instances will still
be reallocated if your container exits, you request a reallocation, or the node powering the instance disconnects.
Container groups without a GPU always run at the “Lowest” priority level, and can be interrupted by any container group
requesting a GPU.
Changing Priority
You can change the priority level of an existing container group in the Portal by editing the container group, or with
the Update Container Group API.
- Changes apply to running instances immediately. Nothing restarts or redeploys. The new priority level determines
both whether your instances can be preempted by higher priority container groups and the hourly rate billed from that
point on.
- Raising priority is allowed at any time on a running container group.
- Lowering priority on a running container group is only allowed once the container group has been running at its
current priority level for 1 hour. The hour counts from the container group’s last start or its last priority change,
whichever is later, and a priority change in either direction restarts it. This applies while the container group is
deploying or running.
- Rejected changes. If you attempt to lower the priority before the hour has passed, the request is rejected and the
container group keeps its current priority level. The API returns HTTP
400 with the problem type
container_group_update_exception and the message: “The priority of a running container group can only be lowered
after it has been running at this priority for 60 minutes. Stop the container group to change its priority
immediately.” The Portal shows the same error.
- Stopped container groups can change priority freely, and stopping clears the 1-hour timer. To move a running
container group to a lower priority level right away, stop the container group, change the priority, and start it
again. The new priority level applies when the container group starts.
- Container groups without a GPU always run at the “Lowest” priority level. A priority value set on them is ignored.
Choose the lowest priority level that meets your interruption tolerance when you deploy. Raise priority whenever you
need nodes faster. To lower priority right away, stop the container group, change the priority, and start it again.
