Ever want to spread or tweak how your server is provisioned on the host? With this feature you can. Be it placement of your load balancer nodes, or your Kubernetes worker nodes, this featue helps you achieve high availability.
Provisioning Preference
When you create a new VPS, Webdock has to decide which host (node) should run it. The Host Affinity setting controls how that choice is made. You can find this setting in Dashboard → Account → Provisioning Preference. You can also toggle this setting using our API (yay!)
By default, Webdock uses available capacity as a strong signal. In practice, the host with the most free capacity is often also the best-performing host at that moment.
If your goal is uptime and redundancy, you may prefer to spread servers across different hosts instead.
We provide 4 host affinity settings.
Affinity Mode 1: Capacity First
What it does
Webdock prefers the host with the most free capacity.
Why choose this
Usually gives the best immediate performance profile. Good general-purpose default. Ideal when you care most about speed/fit per server.
Trade-off
Multiple servers from your account may end up on the same host over time, especially if you create them quickly in succession.
Example use case
Launching a single, high-traffic database or an e-commerce backend
Affinity Mode 2: Spread (best effort)
What it does
Webdock tries to place new servers on hosts where your account currently has fewer servers. If there is a tie, it falls back to the host which has the most capacity.
Why choose this
Better distribution across hosts. Helps reduce “all eggs in one basket” risk. Good balance between redundancy and performance.
Trade-off
Not strict isolation; if capacity is limited, placement may still repeat hosts.
Example use case
Deploying 2 to 3 web application servers behind a Webdock load balancer or on Kubernetes worker nodes.
Affinity Mode 3: Strict Spread (if possible)
What it does
Webdock first tries hosts your account is not yet using. If none are suitable/available, it falls back to the least-used by your account suitable host.
Why choose this
Strongest anti-concentration behavior.
Best choice when host-level redundancy is a top priority.
Trade-off
Can place on a less optimal host versus Capacity First if strict spreading is possible.
Example use case
Setting up a High-Availability (HA) database cluster or a Kubernetes (master) control plane
Affinity Mode 4: Pack
What it does
Webdock prefers hosts your account is already using, consolidating placements.
Why choose this
Keeps workloads grouped.
Useful for customers who prefer consolidation over distribution.
Trade-off
Lowest host-level redundancy of the four options.
Example use case
Spinning up multiple short-lived staging, testing, or QA environments for a software development team
Important Notes
- This setting affects newly provisioned servers only.
- Existing servers are not moved when you change the setting.
- Placement is always best effort and still depends on real-time capacity and availability.
- If your saved setting is missing or invalid, Webdock safely defaults to Capacity First.
Which mode should I pick?
- Choose Capacity First if you want the most performance-oriented default.
- Choose Spread (best effort) if you want safer distribution with good performance balance.
- Choose Strict Spread (if possible) if redundancy is your highest priority.
- Choose Pack if you intentionally want consolidation.
Conclusion
Host Affinity gives you precise control over your infrastructure’s underlying physical footprint without adding complex configuration overhead.
In case you’re unsure which to pick for your usecase, ping us and we’ll try to point you in the right direction.
