# Managing Placement Groups
## How to Create a Placement Group
1. In the left sidebar, navigate to **Servers**
2. Click the **Placement Groups** tab
3. Click **+ Create Placement Group**
4. Select your **Location** (Mumbai or Central India)
5. Enter a **Name** for the group (e.g., `db-cluster`, `web-ha-group`)
6. Select your **Policy**
7. Click **+ Create**
Once created, the group appears in the Placement Groups list showing its Policy, Member count, Region, and Creation date.
{% hint style="warning" %}
You must choose a policy at creation time. **The policy cannot be changed after the group is created.**
{% endhint %}
### How to Add a Server to a Placement Group
A server must be assigned to a Placement Group **at creation time**. You cannot add an existing running server to a group after it has been launched.
When creating a new server:
1. Go to **Servers → Create Server**
2. Fill in your server details (image, flavor, network, etc.)
3. In the **Placement Group** dropdown, select your group
4. Complete and launch the server
The server will appear as a **Member** in your Placement Group once its status is Active.
***
### Viewing Placement Group Details
Click on any Placement Group name from the list to open its detail view. This page shows:
* **Policy** — the active placement rule
* **Members** — total number of servers currently in the group
* **Region** — the region where the group is deployed
* **Created At** — timestamp of when the group was created
* **Members table** — lists each server with its name, status, flavor, vCPUs, RAM, and IP address
***
### Examples
#### Example 1 — High-Availability Web Cluster
Run 3 web servers that survive individual physical host failures.
**Policy:** Anti-Affinity | **Region:** Mumbai
**Steps:**
1. Create a Placement Group named `web-ha` with policy **Anti-Affinity** in Mumbai
2. Create `web-server-1` and assign it to `web-ha`
3. Create `web-server-2` and assign it to `web-ha`
4. Create `web-server-3` and assign it to `web-ha`
Each server lands on a separate physical host. A hardware failure on any one host takes down only that server — the other two continue serving traffic uninterrupted.
***
#### Example 2 — Low-Latency Database Pair
Run a primary and replica PostgreSQL server with the lowest possible replication lag.
**Policy:** Affinity | **Region:** Central India
**Steps:**
1. Create a Placement Group named `db-cluster` with policy **Affinity** in Central India
2. Create `db-primary` and assign it to `db-cluster`
3. Create `db-replica` and assign it to `db-cluster`
Both servers run on the same physical host and share its internal network, giving you the lowest possible latency for replication traffic.
{% hint style="danger" %}
If the host fails, both servers go offline simultaneously. Use Affinity only when performance takes priority over redundancy. For mission-critical databases, consider **Soft Anti-Affinity** combined with application-level replication instead.
{% endhint %}
