Choose a service node
Pin a service deliberately and understand what happens when that node is unavailable.
Self-hosted alpha.21 adds Run on node to service configuration. Choose Automatic for normal Kubernetes placement, or an exact node from the picker. The same setting is available as node_name in service TOML.
A pin is a constraint#
The selected name must be the Kubernetes node name, not its IP address or VM label. All replicas of that service use the pin. Jobs and scheduled jobs can also be pinned; different services can select different nodes.
Architecture, taints, resource requests and runtime allocation still apply. A pinned service waits if its node goes away. It does not fail over automatically to another machine. Remove the pin to restore automatic placement, subject to other constraints.
Check capacity and storage#
Plans reject unavailable or cordoned nodes, architecture conflicts and known CPU or memory overcommit. The observation does not reserve capacity. Concurrent deployments and rolling updates still need headroom.
Local volumes stay on their original node. Conflicting volume affinity or incompatible pins are rejected. Removing a pin does not transfer data. Plan a migration or restore before moving a stateful service.
Use automatic placement unless you have a reason to select a machine. Read the versioned placement reference for the configuration example and API permissions.