> For the complete documentation index, see [llms.txt](https://docs.neevcloud.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.neevcloud.com/neevcloud-products/placement-groups/managing-placement-groups.md).

# 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 %}

<figure><img src="/files/KcpdwLHxtxUBlCy3p1Cl" alt=""><figcaption></figcaption></figure>

### 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.

<figure><img src="/files/rmL4dP1IeteDZeKmZiXO" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/JpSYI0RjAyNThU6kzDlY" alt=""><figcaption></figcaption></figure>

***

### 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

<figure><img src="/files/EaX6MipCIf43myqlisJK" alt=""><figcaption></figcaption></figure>

***

### 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 %}