Primary IP Assignment¶
HtzPrimaryIpAssignment assigns a Hetzner Cloud Primary IP to a server. It models the assignment as a first-class resource with its own lifecycle — create assigns, update reassigns to a different server, and destroy unassigns.
Type: Hetzner::Networking::PrimaryIpAssignment
Import: @cdk-x/hetzner
Server must be powered off
The Hetzner Cloud API requires the target server to be powered off before a Primary IP can be assigned or unassigned. Attempting to assign a Primary IP to a running server will fail with a server_not_stopped error. Use HtzFloatingIpAssignment if you need to assign a public IP to a running server.
Props¶
| Prop | Type | Required | Description |
|---|---|---|---|
primaryIpId |
number \| IResolvable |
✅ | ID of the Primary IP to assign. Typically supplied via attrPrimaryIpId from an HtzPrimaryIp. |
assigneeId |
number \| IResolvable |
✅ | ID of the server to assign the Primary IP to. Typically supplied via attrServerId from an HtzServer. |
assigneeType |
PrimaryIpAssigneeType |
✅ | Type of the assignee. Currently must be PrimaryIpAssigneeType.SERVER. |
No attribute getters
HtzPrimaryIpAssignment has no attr* getters — its primary identifier is the primaryIpId, which you already hold from HtzPrimaryIp.attrPrimaryIpId.
Create example¶
- The server must be powered off for the assignment to succeed. Set
startAfterCreate: falseto keep it off after creation. attrPrimaryIpIdproduces a{ ref, attr }token — the engine resolves it afterHtzPrimaryIpis created and injects the numeric ID. The assignment automatically depends on the Primary IP.- Same for
attrServerId— the assignment waits for the server to be ready before assigning.
Cross-stack example¶
When the Primary IP lives in a different stack (e.g. a shared networking stack), export it via StackOutput and import the value:
- The token is a cross-stack reference. The engine resolves it at deploy time once
Networkinghas been deployed. importValue()creates a cross-stack token that encodes the dependency — the engine deploysNetworkingbeforeCompute.
Dependency graph¶
The engine infers dependencies from the { ref, attr } tokens — no manual addDependency() call is needed:
Update behavior¶
Changing assigneeId triggers an unassign-then-reassign sequence:
- Engine calls
POST /primary_ips/{id}/actions/unassign— waits for the action to complete. - Engine calls
POST /primary_ips/{id}/actions/assignwith the newassigneeId— waits for the action to complete.
Both the source and target servers must be powered off during the operation.
Destroy behavior¶
The engine calls POST /primary_ips/{id}/actions/unassign and waits for the Hetzner action to reach success. The underlying Primary IP is not deleted — only the assignment is removed.
Destroy order
When HtzPrimaryIp and HtzPrimaryIpAssignment are in the same stack, the engine destroys HtzPrimaryIpAssignment first (because HtzPrimaryIp depends on it indirectly via the token). If they are in separate stacks, destroy the compute stack before the networking stack.
Primary IP Assignment vs Floating IP Assignment¶
HtzPrimaryIpAssignment |
HtzFloatingIpAssignment |
|
|---|---|---|
| Server state required | Powered off | Any (running or stopped) |
| IP type | Bound to location | Routable, not bound |
| Typical use | Static IP for a server provisioned offline | Failover / live reassignment |
See also
- Primary IP — the IP resource being assigned
- Server — the compute resource receiving the IP
- Floating IP Assignment — same pattern for Floating IPs (no server power-off required)
- Tokens & Cross-resource References — how
attrPrimaryIpIdandattrServerIdresolve at deploy time