CoreWeave BYOIP Integration Overview
This page outlines the technical and procedural information required for integrating Bring Your Own IP (BYOIP) with CoreWeave Cloud. CoreWeave currently supports a provider-announced BYOIP model: your IPv4 prefixes are originated by CoreWeave (AS33425) and attached to workloads via CoreWeave networking (VPCs, public IPv4, CKS clusters).
Provider Details
| Field | Information |
|---|---|
| Provider Name | CoreWeave |
| Website | Bring Your Own IP (BYOIP) | Networking overview | Public IPv4 | Networking pricing (BYOIP) |
| ASN(s) | Primary cloud ASN: AS33425 (CoreWeave, Inc.) - origin for BYOIP prefixes. |
| Regions Supported | CoreWeave operates multiple Regions and AZs across the US and Europe (e.g. US-EAST-01, US-WEST-01 with multiple AZs). BYOIP is a networking feature tied to CoreWeave’s public IP/VPC fabric; concrete Region availability should be confirmed with CoreWeave account/support based on your deployment. |
| Support Contact | Contact Sales | Support via Cloud Console / email |
| Tech Article & Date | Bring Your Own IP (CoreWeave networking docs; accessed 2025-11) and Network Pricing (BYOIP section). |
| BYOIP Scope | Provider-announced: CoreWeave advertises your IPv4 /24+ prefixes from AS33425. BYOIP is used to map your space to CoreWeave workloads via public IPv4/VPC; no customer-run BGP sessions are involved in the BYOIP feature. |
| Supported Versions | IPv4 only for BYOIP. CoreWeave’s BYOIP requirements explicitly state that only IPv4 addressing is supported; IPv6 BYOIP is not currently documented. |
| Supported Services | BYOIP prefixes are consumed wherever public IPv4 is used on CoreWeave (e.g. services exposed via Public IPv4, load-balanced endpoints, and internet-facing workloads in VPCs and CKS clusters). Exact patterns are deployment-specific and configured via the Cloud Console / APIs. |
Technical Requirements
| Requirement | Details |
|---|---|
| Prefix Size | BYOIP currently supports IPv4 only. Minimum subnet size is a /24 (256 IPv4 addresses) per the BYOIP requirements. Smaller prefixes are not supported. |
| ASN Ownership Required | No customer ASN/BGP session is required for BYOIP. CoreWeave originates the prefixes from AS33425 on your behalf. The LOA template includes your ASN if you have one, but the routing is performed by CoreWeave’s ASN, not via your own BGP sessions. |
| IRR / Route Objects | Each subnet you request CoreWeave to advertise must have a route object in a mainstream IRR (e.g. ARIN, RIPE, RADB) that lists AS33425 as the origin. If you cannot update IRR yourself, CoreWeave can create the route object on your behalf upon request. |
| ROA or LOA | LOA: A Letter of Authorization is mandatory. It must be on your organization’s letterhead, explicitly authorize CoreWeave (AS33425) to announce the specified IPv4 block(s), include your organization details (and ASN if applicable), name/title of the signatory, date, and a handwritten (“wet”) signature. The LOA must be supplied as a PDF; image formats (JPEG/PNG) are not accepted. ROA (RPKI): If the block is RPKI-signed, you must update/add a ROA that includes AS33425 as a valid origin before CoreWeave can advertise the prefix. |
| RIR Limitations | Prefixes must be portable IPv4 space that is solely owned and controlled by you and registered in a RIR with accurate contact information. Each subnet: - Must not currently be present in the global Internet routing table when you hand it to CoreWeave. - Must have a clean reputation. CoreWeave may investigate and can reject or remove ranges if they contain IPs associated with abuse or malicious behavior. A maintained abuse contact email is required for the space. |
Step-by-Step BYOIP Process
Estimated Setup Time:Not explicitly documented by CoreWeave; practically, expect several business days for LOA review, IRR/RPKI validation, and internal provisioning, plus normal Internet BGP propagation time (often < 24 hours once advertisements start).Tested By Us:Not yet
Provider-announced BYOIP (CoreWeave originates your IPv4 prefixes)
Step 1
Verify that your IPv4 ranges are portable, solely owned by you, and meet CoreWeave’s BYOIP rules: IPv4 only, minimum /24, not currently advertised globally, and with a clean abuse/reputation history.
Step 2
Create or update IRR route objects for each subnet so that they list AS33425 as the origin; if the block is RPKI-signed, add or update ROAs to allow AS33425.
Step 3
Prepare a Letter of Authorization (LOA) on your organization’s letterhead authorizing CoreWeave (AS33425) to announce the specified prefixes, including organization details, (optional) ASN, abuse contact, signatory name/title, date, and a handwritten signature; export as PDF.
Step 4
Open a support request via the CoreWeave Cloud Console (Help portal) or coordinate with your account team, providing the LOA PDF, list of IPv4 prefixes, and details of the Regions / workloads where you plan to consume the addresses.
Step 5
CoreWeave validates ownership, IRR/ROA state, and reputation of the ranges.
After approval, they invoice and apply the one-time BYOIP setup fee per IP, then begin announcing your prefixes from AS33425 and mapping them into your networking configuration (public IPv4/VPC).
Step 6
Attach and test the new BYOIP addresses on your services (for example, public endpoints or load-balanced services in CKS).
Use external tools (e.g., route-views, RIPEstat, HE BGP Toolkit) to verify visibility and propagation across the Internet.
Cost and Limitations
| Item | Details |
|---|---|
| Fees | BYOIP setup fee: Each IPv4 address has a one-time, non-refundable setup fee of $4.00, payable upon CoreWeave’s acceptance of your LOA. Standard Public IPv4 monthly pricing applies where these addresses are bound as public IPs, plus normal compute/storage charges. |
| Bundled or Standalone | BYOIP is a networking feature integrated with CoreWeave’s VPC and Public IPv4 products. It can be used alongside services like Direct Connect (DX) for hybrid connectivity, but BYOIP onboarding itself is driven via support and not a self-service API toggle. |
| Traffic/Peering Restrictions | Prefixes must have a clean reputation. CoreWeave may investigate IP reputation and can reject or later remove ranges that contain abusive or malicious activity. All usage must comply with CoreWeave’s Terms of Service and Acceptable Use Policy. Routing/peering specifics follow CoreWeave’s upstream/backbone policies and are not customer-tunable via BYOIP. |
| Other Limitations |
|
Automation & Developer Access
- API Access: Yes - CoreWeave exposes networking resources (e.g. VPCs) via REST/gRPC APIs at api.coreweave.com with Bearer token authentication; see the VPC API reference. BYOIP onboarding itself is initiated via Support, not a public BYOIP API.
- CLI: CoreWeave Intelligent CLI (cwic) plus standard Kubernetes tooling (kubectl) for managing CKS clusters and attached networking resources.
- Terraform: Official <strong>coreweave/coreweave</strong> Terraform provider for managing CoreWeave Kubernetes Service (CKS) and other resources as code; BYOIP ranges themselves are configured via support but can be consumed by Terraform-managed infrastructure.
- SDKs & APIs: Public Protobuf/gRPC modules for networking (e.g., VPCService) exposed via Buf, plus S3-compatible APIs for Object Storage and an HTTP Object Storage API; all secured via CoreWeave API Access Tokens and access keys.
Abuse & Reputation Management
- Customer must provide a valid, maintained abuse contact email for the BYOIP ranges. CoreWeave may review the historical reputation of the IP address space before and during service.
- CoreWeave reserves the right to reject, withdraw, or remove announced routes if the IP space is suspected or found to be used for malicious or harmful purposes, notifying the abuse contact on file. Ongoing monitoring, delisting, and reputation management for the space remain primarily the customer’s responsibility.