Latitude.sh BYOIP Integration Overview
Location
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
| Field | Information |
|---|---|
| Provider Name | Latitude.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
| Requirement | Details |
|---|---|
| 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)
B) BYOIP with custom ASN and BGP
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
| Item | Details |
|---|---|
| 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 Limitations |
– Minimum 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
Abuse & Reputation Management
Related Resources
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