Skip to content

Latitude.sh BYOIP Integration Overview

BYOIP SUPPORTER
ASN 262287, 396356
IPv4 support
IPv6 support
LOA support
ROA support
Process Semi-automatic
Locations supported
Other: Japan, Singapore, Germany, Netherlands, United Kingdom, Mexico, United States, Argentina, Brazil, Chile, Colombia, Australia

This page outlines the technical and procedural information required for integrating Bring Your Own IP (BYOIP) with Latitude.sh’s global bare metal cloud and programmable network. Latitude.sh operates as a carrier-grade, BGP-enabled infrastructure platform.

Customer prefixes are introduced into Latitude.sh’s network as “Your own IP (BYO-IP)” and then exposed as assignable addresses for bare metal servers. In practice, BYOIP with Latitude.sh is achieved through two closely related models:

(1) Latitude.sh originated IP prefixes, where Latitude.sh ASNs announce your IPv4/IPv6 space, and you attach addresses to servers as first-class IP resources;

(2) BYOIP with custom ASN and BGP, where your own ASN participates in routing decisions while still leveraging Latitude.sh’s automated platform, anycast capabilities, and DDoS-protected edge.

Provider Details

FieldInformation
Provider NameLatitude.sh (Bare Metal Cloud & Programmable Network)
Website Latitude.sh Network & BYOIP overview | Network pricing — bandwidth, IPs, “Your own IP (BYOIP)” | IP addresses documentation (management & additional IPs) | Latitude.sh CLI (“lsh”) documentation | Terraform provider documentation
ASN(s) Primary Latitude.sh ASNs used to originate and carry customer and Latitude-owned prefixes:
AS262287 (Latitude.sh LTDA) — core network with global scope and strong presence in Brazil and Latin America.
AS396356 (LATITUDE-SH) — global edge ASN used in multiple peering locations (for example Dallas, New York, Los Angeles, Sydney, Tokyo, Santiago, Mexico City) for worldwide reach and peering density.
Depending on design, BYOIP prefixes may be originated by Latitude.sh ASNs, by the customer’s ASN via BGP, or via a combination of both.
Regions Supported Latitude.sh operates a global carrier-grade network with data centers across North America, South America, Europe and APAC, interconnected via BGP and peering with thousands of ASNs. Current public bandwidth regions and key countries include:
Americas: United States, Brazil, Argentina, Chile, Colombia, Mexico.
Europe: Germany, Netherlands, United Kingdom.
APAC: Australia, Japan, Singapore.
BYOIP is available in locations that expose programmable networking, BGP and “Your own IP (BYOIP)” in the network pricing matrix. Exact city-level support and anycast footprints should be confirmed with Latitude.sh during onboarding.
Support Contact Contact sales (commercial design, BYOIP scoping, custom builds) | Developer resources & contact support (requires account login for ticketing) | Email: support@latitude.sh for technical/account support, sales@latitude.sh for sales, legal@latitude.sh for abuse and legal issues.
Tech Article & Date Network overview — BGP, Custom ASN, “Bring your own IP (BYOIP)” — describes the programmable network, BGP, custom ASN, and explicitly lists “Bring your own IP (BYOIP)” as a first-class network feature.
Network pricing for bandwidth, IPs & BYOIP — documents IP feature matrix, including “Your own IP (BYOIP)” minimum sizes (/24 v4, /48 v6), BGP & Anycast support, and the one-time setup fee.
Introducing lsh, the Latitude.sh CLI — highlights the CLI used to automate deployment and ongoing IP/server changes.
Terraform provider docs & Terraform provider changelog entries — show infrastructure-as-code workflows that also apply to BYOIP-backed deployments.
BYOIP Scope Latitude.sh’s BYOIP capability is focused on bare metal servers and programmable networking, not on attaching prefixes to virtual NICs in a classic cloud VPC:
1) Latitude.sh-originated BYOIP prefixes (“Your own IP (BYOIP): You bring customer-owned IPv4 and/or IPv6 prefixes (minimum /24 for IPv4, /48 for IPv6). Latitude.sh validates ownership and introduces those prefixes into its carrier-grade network, originating them from Latitude.sh ASNs as agreed. Address space is then sliced into usable addresses that can be assigned to bare metal servers in your projects, just like provider-owned public IPs, while preserving your ownership and enabling global or regional anycast.
2) BYOIP with custom ASN and BGP: For advanced customers, Latitude.sh supports BGP and custom ASN usage. In this model, your own ASN participates in routing, with BGP sessions between your infrastructure and Latitude.sh. Latitude.sh still provides the global network, DDoS protection and automation, while you retain additional control over routing policies, anycast design and propagation of your BYOIP space.
Supported Versions Latitude.sh supports both IPv4 and IPv6 in the context of BYOIP:
IPv4: “Your own IP (BYOIP)” requires a minimum /24 IPv4 prefix.
IPv6: “Your own IP (BYOIP)” requires a minimum /48 IPv6 prefix.
Prefixes can be equal or larger than these minimums and must be globally routable (no private address space). Once onboarded, IPv4 and IPv6 addresses from your prefixes can be attached to servers alongside Latitude.sh-managed addresses and participate in BGP and anycast configurations.
Supported Services BYOIP concepts apply to Latitude.sh bare metal servers and the Latitude.sh network stack, including:
– Standard and GPU bare metal server plans across all supported locations.
– Programmable network features such as BGP, custom ASN, private networks, and anycast.
– Edge and connectivity services (for example, Cloud / Global Gateway and DDoS protection) where public IP space and routing policies are relevant.
Typical use cases include maintaining long-lived IP reputation when migrating workloads, globally anycasted APIs or gaming endpoints, VPN and secure access concentrators, and low-latency content delivery from customer-owned IP space.

Technical Requirements

RequirementDetails
Prefix Size Latitude.sh formalizes BYOIP at the level of customer-owned IPv4/IPv6 prefixes that are introduced into its backbone and then carved into usable addresses:
Latitude.sh-originated BYOIP (“Your own IP (BYOIP): Minimum /24 for IPv4 and /48 for IPv6. Larger blocks (for example /23, /22, /44) can be accepted and may be internally segmented for assignment to servers and regions.
BGP / custom ASN designs: When you run BGP with your own ASN, effective minimum sizes are driven by global routing practices and Latitude.sh policy. /24 for IPv4 and /48 for IPv6 are still the practical minimums for stable global reachability.
Prefixes must not be in bogon or private ranges, and they should have a clean or recoverable reputation with downstream services.
ASN Ownership Required No customer ASN is strictly required to use Latitude.sh-originated BYOIP. In that common model, Latitude.sh’s ASNs (AS262287/AS396356) originate your prefixes on your behalf.
If you want deeper routing control, you can use custom ASN and BGP:
– You provide a public ASN and routing policy; BGP sessions are established between your infrastructure and Latitude.sh in supported locations.
– Latitude.sh can originate your routes, carry them, or propagate routes originated by your ASN, depending on the agreed design.
This flexibility allows both enterprises without an ASN and network-savvy customers with their own ASN to adopt BYOIP.
IRR / Route Objects While not exhaustively documented in public docs, customers should expect to maintain accurate IRR route objects and registry data for the prefixes they bring:
– Route objects should reflect the intended origin ASN (Latitude.sh ASN or your own ASN) and be consistent with any BGP configurations.
– Updating IRR objects is a standard prerequisite for most networks when accepting and propagating third-party prefixes, and simplifies troubleshooting or abuse handling.
Latitude.sh may rely on IRR data, PeeringDB information and other routing databases as part of its validation and routing hygiene processes.
ROA or LOA To prove control over your prefixes and align with modern routing security practices, customers should be prepared to provide:
– A Letter of Authorization (LOA) explicitly allowing Latitude.sh to announce and use your prefixes in its network (and specifying which ASNs are allowed to originate them).
– Where available, RPKI ROAs that authorize either the relevant Latitude.sh ASN or your own ASN as the origin for the prefix; this is not only good practice but increasingly important for reachability and hijack protection.
Exact documentation and validation steps are confirmed during onboarding, and may differ by RIR and by design (Latitude.sh-originated vs customer-ASN-originated).
RIR Limitations Customer-owned IP space used for BYOIP must be globally routable public IPv4 or IPv6 space, correctly registered with an appropriate RIR (for example ARIN, RIPE, LACNIC, APNIC, AFRINIC). Customers must be able to:
– Prove organizational control of the prefixes via RIR records.
– Update WHOIS/RDAP data, IRR route objects and ROAs on request.
– Ensure there are no conflicting announcements of the same prefixes from other providers when Latitude.sh (or your ASN via Latitude.sh) becomes the primary origin.
RIR-specific policies (for example sub-allocation rules or transfer constraints) remain the customer’s responsibility.

Step-by-Step BYOIP Process

Estimated Setup Time: Typically ranges from several days to a few weeks, depending on commercial enablement, RIR/ROA and LOA changes, network design (single-region vs multi-region/anycast), and the number of external allowlists that must be updated.

Tested By Us: Not yet

A) Latitude.sh-originated BYOIP prefixes (“Your own IP (BYOIP)

  • Engage your Latitude.sh account or sales team to confirm that BYOIP is available for your account, discuss use cases (for example SaaS allowlists, VPN endpoints, gaming, APIs, anycasted services), select target regions, and understand pricing (one-time BYOIP setup fee and ongoing bandwidth charges).
  • Collect details of the IPv4 and IPv6 prefixes you plan to bring (minimum /24 for IPv4, /48 for IPv6 or larger) and verify that RIR records show your organization as the holder, that the space is globally routable, and that reputation is acceptable or a remediation plan exists.
  • Prepare routing artefacts for onboarding: ensure IRR route objects exist for your prefixes, and where practical create RPKI ROAs that authorize either a Latitude.sh ASN or your own ASN as origin. Prepare a Letter of Authorization (LOA) stating that Latitude.sh may announce and use the specified prefixes in agreed locations.
  • Open a Latitude.sh support ticket or work with your account team to initiate BYOIP onboarding, providing prefix details, intended regions, traffic profile, desired origin model (Latitude.sh ASN only or combination with your ASN), and anycast or DDoS-related requirements.
  • Latitude.sh networking validates ownership and routing data, introduces your prefixes into the Latitude.sh network, configures BGP and anycast as agreed, and exposes address ranges from your prefixes as assignable IP resources within your projects so they can be attached to bare metal servers similar to Additional IPs.
  • Using the Latitude.sh dashboard, REST API, CLI (lsh) or Terraform provider, attach BYOIP addresses to servers, update DNS and external allowlists, verify reachability and geolocation, and gradually migrate production traffic from legacy environments while monitoring logs, performance and IP reputation.

B) BYOIP with custom ASN and BGP

  • Confirm with Latitude.sh that BGP and custom ASN features are available in the regions where you plan to deploy and that your intended routing design (for example anycast services, traffic engineering with communities) aligns with Latitude.sh network policies.
  • Ensure that you control a public ASN and that your routing policy and upstream arrangements are compatible with announcing some or all of your prefixes from Latitude.sh locations. Decide which prefixes will be originated by your ASN versus being originated directly by Latitude.sh ASNs.
  • Work with Latitude.sh networking to design BGP sessions (for example on dedicated routers, appliances, or edge servers), exchanging technical parameters such as peer IPs, ASNs, MD5 keys, prefix limits, and BGP communities used for steering traffic or blackholing under attack.
  • Establish BGP peering in a staging environment first, announce test prefixes or more specific routes from your BYOIP space, and validate end-to-end paths, failover behaviour, anycast client distribution, and interaction with your existing upstreams or peers.
  • Once routing is stable, bind application services to addresses from your BYOIP prefixes on Latitude.sh servers, apply appropriate firewalls and DDoS controls, and integrate network monitoring so BGP session health, prefix visibility and latency are continuously tracked.
  • Document the BYOIP and BGP design, including which parties maintain ROAs, IRR route objects and LOAs, and schedule periodic reviews with Latitude.sh to align on new regions, additional prefixes, or changes in routing policy as your footprint grows.

References: Latitude.sh Network & BYOIP overview, Network pricing & BYOIP feature matrix, IP addresses documentation, Latitude.sh CLI docs, Terraform provider docs, Developer resources & support.

Cost and Limitations

ItemDetails
Fees Latitude.sh publishes network and IP pricing, including BYOIP, on its public pricing pages. Key elements include:
One-time setup fee for “Your own IP (BYOIP)”: USD $200 per BYOIP onboarding (as listed in the IP feature matrix).
Monthly IP cost for BYOIP: Listed as Free; you do not pay per-address monthly fees for your own IP space.
Additional IPv4 from Latitude.sh: Charged monthly per IP (separate from BYOIP) if you also use provider-owned space.
Bandwidth: Charged per TB of egress by region (for example, lower per-TB pricing in US, UK, Netherlands, Germany and higher in some LATAM/APAC regions). Ingress is generally free; bandwidth packages can reduce effective per-GB costs.
Any custom routing, DDoS or connectivity features that go beyond the standard product may incur additional commercial terms negotiated with Latitude.sh.
Bundled or Standalone BYOIP is not a standalone transit or IP-hosting product. It is bundled into the Latitude.sh bare metal and network platform:
– “Your own IP (BYOIP)” is an add-on feature for projects that deploy servers and use Latitude.sh network services.
– Once onboarded, BYOIP scopes to your Latitude.sh projects and is consumed via servers, virtual networks and gateways, alongside managed IPs.
– The platform is designed so that BYOIP attributes (ownership, reputation) are preserved while you still leverage automation, observability and security features of Latitude.sh.
Traffic/Peering Restrictions – BYOIP prefixes are intended for use with Latitude.sh infrastructure. You cannot generally use Latitude.sh solely as a remote announcer of arbitrary third-party traffic without associated workloads on their platform.
– BGP and custom ASN usage is subject to Latitude.sh peering and routing policies, including sensible prefix limits, traffic engineering constraints and filtering of bogon or malformed routes.
– Latitude.sh maintains its own upstream and peering relationships; customers normally do not control external peering directly, but can influence routing via documented communities and design patterns agreed with the network team.
– Certain high-risk workloads (for example large-scale bulk email, open resolvers, abusive proxying) may be restricted or require explicit approval.
Other LimitationsMinimum sizes: /24 for IPv4 and /48 for IPv6 are the documented minimums for BYOIP. More specific routes may be filtered or discouraged depending on routing policy.
Abuse handling: Persistent abuse or poor hygiene on BYOIP prefixes can lead to routing restrictions or service suspension. Customers are expected to remediate issues quickly and maintain correct RIR data.
Region availability: While the Latitude.sh network is global, use of BYOIP in a specific city or facility may depend on connectivity design, DDoS protection capabilities and commercial discussions.
Operational responsibility: Latitude.sh operates the network and provides tooling; customers are responsible for higher-layer application behaviour, IP reputation, and coordination with external services that consume these IPs.

Automation & Developer Access

  • API Access: Yes — Latitude.sh provides a fully documented REST API for managing projects, servers, bandwidth packages, IP addresses and virtual networks. Once your BYOIP prefixes are onboarded, IP assignment and lifecycle actions are driven through the same API resources as provider-owned IPs, enabling full automation.
  • CLI: The open-source lsh CLI allows you to deploy and manage servers, list and update IPs, and configure virtual networks directly from your terminal, making it easy to script recurring BYOIP changes or integrate them into existing operational runbooks.
  • Terraform: Latitude.sh offers an official, verified Terraform provider published in the Terraform Registry. You can define projects, servers, bandwidth packages and network resources as code, and incorporate BYOIP-backed endpoints into reproducible Terraform plans and CI/CD pipelines.
  • SDKs Examples: Latitude.sh publishes SDKs, a Postman collection and a public examples repository that includes Terraform, custom images and networking scenarios. These artefacts provide practical starting points for automating BYOIP deployments and for integrating Latitude.sh into your wider tooling ecosystem.

Abuse & Reputation Management

  • When you use Latitude.sh-owned IPs (management or additional IPs), Latitude.sh is responsible for the underlying ranges and overall routing hygiene, but you must still comply with Latitude.sh’s Terms of Service, acceptable use policies and any abuse notifications related to traffic originating from your servers.
  • For BYOIP prefixes, you retain ultimate responsibility for long-term reputation, blacklists, RIR data and routing security of your address space. Latitude.sh can provide logs, DDoS mitigation and guidance, but delisting, relationships with external RBL operators, and ongoing RPKI and IRR maintenance remain customer tasks; poor reputation can affect deliverability regardless of where the IPs are hosted.

Latitude.sh Homepage
Network overview & BYOIP feature description
Network pricing, bandwidth and IP feature matrix
IP addresses documentation (Management IPs, Additional IPs)
Developer resources & support
Latitude.sh CLI (lsh) documentation
Terraform provider docs
Using Terraform with Latitude.sh guide
Latitude.sh Terraform provider on Terraform Registry
Latitude.sh examples repository
Contact sales & general enquiries

FAQ

BYOIP, or Bring Your Own IP, is a service that enables organizations to bring their own public IP addresses—whether owned outright or leased from an IP provider—into a service provider’s network infrastructure. Instead of relying on IP addresses assigned by the provider, BYOIP allows businesses to retain control over their IP resources. This ensures continuity, particularly for organizations with established IP-based reputations, branding, or dependencies on specific address blocks. IP providers can assist in streamlining this process, making it easy to integrate your IPs into the desired network environment.

BYOIP offers several compelling advantages. By using your own IPs, you can maintain continuity in your network’s identity, reduce the risk of disruptions to email deliverability or service recognition, and avoid reputational concerns associated with shared IPs. Additionally, BYOIP provides enhanced flexibility and control over your IP resources.

BYOIP is ideal for organizations that either own public IP addresses or lease them from a trusted IP provider with explicit BYOIP support. This includes enterprises, cloud providers, content delivery networks (CDNs), and businesses with compliance requirements or IP reputation needs. Working with a reputable IP provider ensures that leased IPs can be seamlessly integrated into another provider’s infrastructure without ownership concerns.

You must either legally own the IP addresses or have explicit authorization from a leasing IP provider to route and manage them. IP providers who offer BYOIP-ready IP addresses simplify this process, providing documentation and support to ensure compliance with regional internet registry (RIR) policies and service provider requirements. This collaboration ensures smooth implementation without any legal or operational issues.

To use BYOIP, you’ll typically need to present documentation verifying your authority over the IP block. This can include official records from a regional internet registry (RIR) such as ARIN, RIPE NCC, or APNIC. If you are leasing IPs, the IP provider should supply proof of their ownership and grant you permission for BYOIP. Providers that specialize in IP leasing often handle this paperwork for you, reducing administrative burden and ensuring compliance.

Yes, BYOIP is designed to be a secure and reliable solution. Reputable service providers and IP providers implement robust safeguards to prevent unauthorized use or hijacking of IP addresses. Security measures include BGP filtering, route validation, and advanced protocols like Resource Public Key Infrastructure (RPKI). By collaborating with a trusted IP provider, businesses can benefit from additional layers of protection, ensuring that only authorized traffic is routed through their IP blocks.

The setup process for BYOIP varies by provider, typically taking anywhere from a few hours to a few days. Factors include the complexity of your network, the verification process for IP ownership or authorization, and the time needed for global BGP route propagation. IP providers often expedite the preparation and validation stages, ensuring a smooth and timely integration into the desired infrastructure.

Absolutely. Many providers, in partnership with IP providers, support routing IPs across multiple data centers or geographic regions. This feature optimizes performance for global businesses by reducing latency and improving service availability. When working with an IP provider, you can also ensure that your leased or owned IPs are aligned with your geographic requirements for compliance and efficiency.

If you choose to discontinue BYOIP with a provider, your IP addresses will be released from their network, and routing will cease. You can then reallocate these IPs for use with a different service provider or project.