Summary

  • Nebius documents an addressing layer that currently supports IPv4 only, one public IPv4 address per Compute machine, and a default allowance of three public IPv4 addresses per region.
  • Dynamic public addresses return to the provider's pool after a machine has been stopped for more than an hour, and the only customer-chosen address ranges the documentation describes are RFC 1918 private space.

An IPv4 address is the number other networks use to reach a machine, and there are not enough of them to go around, which is why cloud providers meter them instead of handing them out. Nebius meters them hard. Its overview of Virtual Networks describes an addressing layer that "currently supports only IPv4 addresses" — no IPv6 path for compute traffic — built on a default public pool that is "automatically provided" and "shared across all projects in a tenant", and that a customer "cannot be customized, modified, or deleted".

The phrasing is not accidental. A tenant does not receive a slice of public space to administer. It receives consumption rights against a pool somebody else administers, and the console will only show which blocks that pool is offering in the project's region (Getting public IPv4 ranges).

Three doors a region, one door a machine

The numbers are not vague. The Virtual Networks quota table lists a default of three public IPv4 addresses per region, next to a ceiling of 1,000 total IP allocations per region (quotas and constraints). Quotas are regional, can be configured differently for each project in the region, and increases can be requested (Quotas in Nebius AI Cloud). On the compute side, each virtual machine takes exactly one public IPv4 address (Private and public IP addresses of Compute virtual machines).

Read the two together and the operating picture appears. A project in a region starts with three public front doors. Every machine you want reachable takes one of them. A fleet of fifty inference nodes and three public addresses leaves forty-seven nodes that the Internet cannot dial directly. That is usually the correct architecture — but only if you planned it, rather than discovered it during a launch window.

Because the quota is requestable, three is a starting line and not a wall. It is still the number a new project sees, and it says what the platform expects: that most tenants need a handful of ingress points, and that public addresses are a shared scarce good to be recycled rather than a resource to be parcelled out.

Three levels of tenancy over one number

The machine documentation sets out a lifecycle with three distinct rungs, and the distance between them is the distance between holding, borrowing and losing.

A dynamic public address is the loosest arrangement. The documentation is blunt: "Dynamic public IP addresses are not persistent." If a machine stays stopped for more than an hour, the address returns to Nebius's public range and may be reassigned.

A static address that was automatically assigned is sturdier while the machine lives. It survives a stop. It does not survive deletion of the machine.

A pre-created public allocation is the closest thing to an address you can keep. It remains available after the machine it was attached to is deleted. Then the documentation adds a decay clause: an unassigned public allocation may itself be deleted after 30 days.

Three rungs, three failure modes. Losing a dynamic address is a stop that lasted through lunch. Losing an automatically assigned static address is a delete. Losing a pre-created allocation is forgetting about it for a month.

What you may choose, and what you may not

The one place the documentation hands a customer real control over addressing is private. The custom-address procedure is explicit that the chosen block "must fall within the RFC 1918 private address ranges" (Allocating custom private addresses).

RFC 1918 is shorthand for the reserved blocks — 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 — that never appear on the public Internet. Letting a tenant pick those is a favour with no scarcity cost attached, because private addresses are effectively unlimited: nobody routes them. Extending the same freedom to public prefixes is a different proposition, because a public prefix must be justified to a registry and the supply is finite.

The documentation reviewed here describes no procedure for bringing a customer-owned public prefix to Nebius. Be precise about what that proves. A page that omits a workflow is not a contract term forbidding one, and large customers routinely negotiate things that never reach a public page.

Why the scarcity is the story

The instinct is to file this under housekeeping. Quotas exist everywhere; every cloud caps something. Look instead at what is capped against what is being sold. This is a platform built for customers running large fleets of expensive accelerators, and the default public identity allowance is three addresses per region. The capacity is elastic. The front door is not.

The structure is legible without knowing anybody's intent. Public IPv4 is the one input in this stack that cannot be manufactured — the registry pool is exhausted and every address in service already belongs to someone. A provider holding a finite pool has an interest in returning addresses to circulation quickly, which is what the one-hour reclamation rule does. It also has an interest in handing out as few as possible by default, which is what a quota of three does. Neither choice is sinister. Both push the same way: toward a tenant that treats reachability as a service consumed rather than an asset owned.

One consequence deserves attention before anybody signs. An address is not only a routing target; it accumulates a history. Reputation systems, abuse databases, allowlists and reverse DNS records attach to the number, not to the company using it. When a dynamic address goes home and gets reassigned, the history stays with the address. The next holder inherits whatever standing the number had earned, and the previous holder's standing does not travel with them.

What a buyer should actually do

Ask the question before the architecture hardens: does anything in this deployment need an identity that survives a pause, a delete, or a change of provider?

If the answer is yes, know which rung you are standing on. Pre-create the allocations you depend on instead of letting the platform assign them, because a pre-created allocation is the only documented arrangement where the address does not vanish with the machine. Put the 30-day decay on a calendar, because an unassigned allocation that quietly expires is the kind of failure that surfaces in a post-incident review three weeks later. Request the regional quota increase before the migration weekend, not during it.

And if the honest answer is that you need to carry a prefix between providers, settle that in the contract rather than inferring it from a console. The documentation reviewed here describes the rental. It does not describe a way to bring your own door.

The evidence boundary

This briefing rests on six pages of Nebius's own public cloud documentation, read on 11 November 2026, plus the company's directory entry (Nebius B.V.). It does not examine Nebius B.V.'s obligations as a registry member, how its address holdings might move in a corporate transaction, or what justification a registry would demand for such a move; none of that appears in the pages reviewed, and none of it is asserted here. Where a workflow is described as undocumented, that means absent from these pages, not prohibited.