Before you start
You need a compatible VPS, access to the domain’s authoritative DNS zone and a network-configuration backup before changes. app.example.com and 192.0.2.10 are illustrative examples. Use your actual service values instead of copying another server’s gateway or subnet.
Separate domain, address and service
An IP address identifies a network destination; a domain name can help locate it. Nginx and other web servers use virtual hosts to distinguish websites sharing an address. TLS SNI lets the client indicate the expected name during connection setup. Different domain names therefore do not, by themselves, require an additional IP purchase for every website you host.
Identify a reason for distinct addresses
Extra IPv4 may help separate services or software that must bind to different addresses. They do not create a complete security boundary: permissions, processes and isolation still require configuration. Separate ports or virtual hosts may be sufficient in some cases. Confirm compatibility and expected application behaviour before paying for a group of addresses that your project does not actually need.
Count additional addresses correctly
Distinguish the desired total from the number to add. With one primary address included, five IPv4 in total means four additional addresses. At the €1.20/month rate checked on 27 October 2026, that adds €4.80/month. Ten additional addresses cost €12/month and provide eleven in total. The estimator reads the configured price and does not invent quantity discounts.
Order and check assignment
The client area provides the existing subscription flow. Additional addresses follow the account’s compatibility, assignment and parking rules. The primary IPv4 remains bound to its service. Having no fixed commercial limit per VPS does not mean every requested quantity is available. A simulation reserves nothing and does not guarantee that an IP can be moved to another service or location.
Prepare forward DNS before the PTR
For a desired PTR pointing to app.example.com, first create an A record in the authoritative DNS zone pointing that name to the relevant IPv4. Wait until public resolution actually returns the address, then request the reverse DNS change through the client area. CubixServ checks this forward mapping before accepting the update. Cached old responses can explain a temporary rejection; verify resolution rather than only the value entered at your DNS provider.
Verify without losing access
Keep the primary address and console access available during guest-system network changes. Do not replace a complete network file with an online example: interface names and routing must match your service. After a PTR update, verify forward and reverse resolution separately. Reverse DNS does not replace a certificate, create a web service or guarantee email delivery or an address’s reputation.
For your situation
| Situation | Next check |
|---|---|
| Several website domains | Start with virtual hosts and TLS; check whether one IPv4 is enough. |
| Ten addresses in total | Simulate nine additional IPv4, then confirm actual availability. |
| Reverse DNS rejected | Check that the public A record resolves to the relevant IP before retrying. |
Official sources
These documents describe the relevant protocols and software. Your service terms and configuration still need to be checked.