Vultr BYOIP: announce your own IP addresses over BGP

You request BGP access, Vultr checks the prefix and has the registry contact confirm it, and your instance then announces the prefix to Vultr. It does not assign customer-owned addresses to instances any other way.

What Vultr accepts

From Vultr's documentation, on the day we checked:

• Size. IPv4 from /24 to /16, IPv6 from /48 to /32. At most five prefixes per customer, IPv4 and IPv6 together.
• Registry. Any regional internet registry; the request guide names ARIN, the RIPE NCC and APNIC as examples. Nothing on PA, PI or legacy space.
• Who originates. Your own ASN, with AS20473 in front of it on the internet, or AS20473 itself if Vultr assigns you a private ASN.
• Where. Any Vultr location, but "our locations are not linked": you announce a /24 from each location where you use the addresses, or one prefix from several locations as anycast. A prefix cannot be shared with another account.
• Who can ask. An account with at least one active Compute instance. Bare metal works too, with a support ticket naming the servers that will announce the prefix.
• Price. Vultr's Cloud Networking page says: "There is no additional cost for running BGP with us." The BGP and BYOIP documentation names no fee for bringing a prefix.
• Timing. 24 to 48 hours after the registry contact confirms, then 6 to 48 hours for transit providers' filters.

Before you start

A ROA. Vultr's policy recommends one to speed up acceptance, and its onboarding check rejects a wrong one. The ROA names your public ASN, or AS20473 if you use a Vultr private ASN: "any ROA signed with a different ASN will be rejected by Vultr's system as invalid" (RPKI and ROAs).

A route object, if you want your own. Without one, Vultr creates it in RADb. With a public ASN, Vultr also adds your ASN to RADB::AS20473:AS-CONE, from which most transit providers build their filters. Vultr accepts route objects from RADb, ARIN, the RIPE Database and APNIC.

A letter of authorization (LOA). Vultr's template authorizes "Vultr with AS20473 to announce the following IP address blocks" and is signed by a representative of the company that holds them. You upload it with the request.

A registry contact who reads mail. Vultr confirms the prefix by email to the point of contact in the registry record.

Step by step

01Request BGP access. In the Vultr Console, open Products, Network, BGP and click Get Started. Toggle I have my own IP space, enter your ASN, a BGP password and the prefix, and upload the LOA. Choose which routes Vultr sends you, describe your use and click Request BGP Setup.

02Clear the checks. Vultr checks Spamhaus listings and the ROA, among other things, and shows a warning in the console if one fails. The registry contact then clicks the link in Vultr's email, and the final checks take 24 to 48 hours.

03Reboot from the control panel any instance deployed before BGP was set up. A reboot over SSH is not enough.

04Bring up the session from the instance's main IP address, with the password and multihop 2. On a VPS the neighbor is 169.254.169.254 in AS64515; on bare metal it is 169.254.1.1 in AS20473. Vultr recommends BIRD. Its example, with documentation values and a static route for your block:

router id 192.0.2.10;

protocol device {
  scan time 5;
}

protocol static {
  ipv4;
  route 203.0.113.0/24 unreachable;
}

protocol bgp vultr {
  local as 64500;
  source address 192.0.2.10;
  ipv4 {
    import none;
    export all;
  };
  graceful restart on;
  multihop 2;
  neighbor 169.254.169.254 as 64515;
  password "your-bgp-password";
}

birdc show proto all vultr should report Established. Each instance's BGP tab in the console also has example BIRD and FRR configurations.

05Put addresses to work. Add an address to a dummy interface and let BIRD export it as a /32 (a protocol direct block for dummy*) next to the covering /24. Several instances in the same location can announce the same /32 for failover.

06Allow for the filters. Where transit providers filter from IRR data, as in Europe and the US, updates typically take 6 to 24 hours. Manual filters, as in India and Israel, can take more than 48 hours.

Mistakes that cost a day

• The private ASN in the ROA. With a Vultr private ASN, the ROA names AS20473, never the private number. Vultr checks RPKI nightly, and a ROA that turns invalid removes an active prefix automatically.
• The maximum length. "Invalid Prefix Length" in the console means the ROA's maximum length does not fit what you announce. Vultr's fix is a new ROA with the correct one, "such as 24 for IPv4".
• A stale registry contact. If nobody reads the mailbox in the registry record, onboarding stops at the confirmation email.
• Pages that disagree about the ASN. The request guide, updated 16 October 2026, pairs your own IP space with your own ASN and says that without one you use Vultr's IP space. The BGP guide of 15 April 2026, the onboarding page and the RPKI page allow a Vultr private ASN with your own space, with the ROA naming AS20473. Say which you want in the use-case field.
• Removing a prefix takes a support ticket.

If you lease the block

Vultr's RPKI page says only the owner of IP space can manage its ROAs, and "if you are leasing IP space, contact your provider" for RPKI. The holder does three things: creates the ROA for your ASN or for AS20473, signs the LOA as the company that holds the block, and clicks the confirmation link Vultr sends to the registry contact. Vultr sets no rule that the block be in your name, but it removes a prefix that it finds belongs to another entity, so keep the holder's LOA on file.

Where RTM Networks fits

We lease /24s and larger from our own RIPE NCC address space, and sell blocks in the RIPE NCC, ARIN and APNIC regions. For space leased from us, we create the ROA for your ASN or AS20473, sign the letter of authorization for Vultr, and confirm the request when Vultr writes to the registry contact (lease IPv4). If you want to announce from your own ASN and do not run an LIR, we sponsor AS numbers (ASN sponsorship). If you need fewer than 256 addresses, or would rather not run BGP, we announce a block and deliver it to your instance over GRE or WireGuard, down to a single address (GRE and WireGuard tunnels). Other providers: BYOIP guides.