Files.com offers Enterprise customers the ability to Bring Your Own IP (BYOIP), letting you use your own public IPv4 address range for both inbound and outbound traffic on your Files.com site. Files.com announces your range on the global internet and assigns addresses from that range to your site. Users connecting to your site reach your own addresses, and outbound connections from your site originate from them.

This feature is available exclusively to customers on Enterprise plans and requires approval and coordination with the Files.com team. Extra charges apply.

When to Use BYOIP

BYOIP is not the default way to get stable addresses, and most allowlist requirements do not need it. Adding a custom domain automatically provisions a pair of dedicated IP addresses for your site, giving your partners a stable pair to add to their allowlists. If stable addresses are all you need, that is the simpler path, and it is included on the Power and Enterprise plans.

BYOIP is the right choice when ownership of the addresses is itself the requirement:

Compliance rules or corporate policy require that traffic originate from company-owned address space.
External partners validate address ownership against your Regional Internet Registry (RIR) registration.
Equipment in the field or counterparty connections with hardcoded addresses cannot be updated cheaply, so the address needs to belong to you rather than to any provider, including us. This is the case that most often justifies the cost: when reconfiguring endpoints means dispatching technicians or contacting hundreds or thousands of counterparties, owning the address becomes an operational necessity.

Benefits of BYOIP

Bringing your own IPs to Files.com offers several advantages:

Firewall and allowlist compatibility. Your partners and internal systems allow traffic from addresses you already control, so your Files.com site fits security policies you have already written and distributed.
Independence from provider IP changes. The range belongs to you, so your site's addresses cannot change when a provider renumbers its address space. Files.com's own addresses moved to a new range in March 2026; a BYOIP range sits structurally outside changes like that.
Policy and brand continuity. Organizations with a policy that traffic must originate from company-owned address space can meet it without writing an exception for Files.com.
Reputation continuity. Address space you have operated for years carries an established routing history, and you keep it.

Supported Traffic Types

Files.com supports BYOIP for both inbound and outbound traffic. Inbound traffic covers users accessing your site over FTP, SFTP, FTPS, WebDAV, and HTTPS. They connect to your own IP addresses. Outbound traffic covers connections originating from your site, such as webhooks and outbound connections to FTP/SFTP servers, which can optionally originate from your IPs.

The result is predictable, transparent network traffic in both directions.

Requirements

To participate in the BYOIP program, your organization must meet the following criteria:

You must own a public IPv4 address range registered with a recognized RIR such as ARIN, RIPE, or APNIC.
You must provide a /24 subnet (256 IPs). Files.com announces /24 blocks. Anything smaller is not reachable everywhere, because networks filter out prefixes longer than /24 to keep the size of the global routing table under control. If your registered range is larger than a /24, you bring one /24 from it and the rest of the range keeps its current announcement. A single /24 covers every region you operate in.
You must be able to publish a Route Origin Authorization (ROA) through your RIR and add a certificate to your registry record for the range. Both are required before your range can be announced.
Your IP space must be eligible for BGP advertisement. If the range is currently announced elsewhere, you must be able to withdraw that announcement before Files.com begins advertising it. When two networks announce the same prefix, the internet receives conflicting routes and reachability becomes unpredictable.
You must dedicate the entire range to Files.com for as long as we announce it.
All participating sites must be on an Enterprise Plan, and BYOIP requires prior coordination and approval.

Authorizing the Announcement

Announcing your range requires two separate authorizations, and they do different jobs. A Route Origin Authorization establishes which networks are permitted to advertise the prefix. A certificate published in your registry record proves that you control the range. Both are mandatory.

Files.com walks your network team through both steps. We supply the ASNs and the maximum prefix length for the ROA; the key pair and certificate are generated on your side, and the private key never leaves your network team.

Route Origin Authorization (ROA)

A ROA is a cryptographically signed record that you create through your RIR's Resource Public Key Infrastructure (RPKI) service. It names the Autonomous System Numbers (ASNs) authorized to originate a specific prefix, along with an expiration date. For BYOIP, your ROA must authorize Amazon's ASNs (16509 and 14618) to advertise your range, and the maximum prefix length must be set to /24. Files.com confirms the exact values with you before you create it.

Networks that perform RPKI Route Origin Validation validate ROAs as part of route selection. If another network announces your prefix without authorization, those validating networks reject the route rather than accepting it and leaving the conflict to be noticed later. The protection applies to your address space generally, not only to its use with Files.com.

Three things to plan around:

A new ROA takes up to 24 hours to propagate before we can verify it.
If the range is announced today, either by you or on your behalf by a carrier or hosting provider, make sure a ROA already covers the ASN that originates it before you add the new ones. Publishing those on their own makes the current announcement RPKI-invalid, and validating networks will begin dropping it. The two ROAs coexist safely, because a route is valid if any covering ROA matches its origin. Authorizing two ASNs is not the same as announcing from two: the range is still advertised from one place at a time. If you are not certain which ASN originates your prefix today, establish that before you publish anything.
If the /24 comes out of a larger registered range, scope the ROA to the /24 rather than to the larger range. A ROA scoped to the /24 cannot affect the larger range's announcement, so no ROA for that range's current ASN is needed unless the /24 itself is being announced separately today. A ROA scoped to the larger range does cover that announcement, and would make it RPKI-invalid unless the ASN originating it is authorized as well.

Creating a ROA requires RPKI to be enabled on your RIR account. Registrations that predate your RIR's current agreements often need a Registration Services Agreement (RSA) in place before RPKI features become available. There is no way around this step, so start it early.

Proof of Ownership in Your Registry Record

A ROA authorizes the announcement, but it does not establish which account may bring your range in. A second authorization covers that, and it is performed once during provisioning:

Your network team generates an RSA 2048-bit key pair and a self-signed X.509 certificate from it.
The certificate is published in the RDAP record for your address range. At ARIN this is the Public Comments field on the network object; at RIPE it is a descr field on the inetnum object; at APNIC it is the record remarks.
The private key signs an authorization message, which is submitted with the provisioning request and verified against the published certificate.

The certificate is only needed while provisioning is in progress. You can remove it from your registry record once your range is live.

A Note on Letters of Authorization

Authorizing a prefix announcement has historically meant sending a Letter of Authorization: a signed document that someone at the receiving network accepted on trust, with nothing validating it cryptographically. Our process is built on RPKI instead, so there is no LOA path and no document for us to send you to sign. If your internal process for authorizing prefix announcements is built around LOAs, the ROA and registry certificate above are what replace it.

Setup Process

The onboarding process for BYOIP involves close coordination with the Files.com team and proceeds as follows:

Contact Files.com Support. Reach out via your Account Manager or Support contact to request BYOIP onboarding. We'll discuss your use case, regions, and confirm eligibility.
Verification and review. We will verify your ownership of the IP range(s) and confirm they meet our technical criteria. You'll be asked to provide WHOIS or RDAP registration records, confirmation of current routing status, and ASN information (if applicable).
Authorization. You publish a ROA authorizing the ASNs we give you to originate your range, and publish a certificate in your registry record, which is used to verify the signed authorization message proving you control the range. We supply the ASNs and maximum prefix length; your network team generates the key pair and keeps the private key. We confirm the ROA is visible before going further. Allow up to 24 hours for a new one to propagate.
Deployment. Once authorization is confirmed, we provision your range, activate the addresses you have chosen, and configure your Files.com site to use them. Announcing the range is the last step, not the first. If your range is already carrying traffic somewhere else, everything up to that point happens without touching your current service. See If Your Range Is Already Announced Elsewhere.
Testing and monitoring. After deployment, we work with your team to verify connectivity and confirm the IPs are functioning as expected. Monitoring and support continue throughout your use of the service.

What Your Network Team Does

Most of the work on your side happens at your Regional Internet Registry rather than in Files.com, and it belongs to your network team rather than to your Files.com Site Administrator. This is the whole of it, in order.

Before you begin

Confirm RPKI is enabled on your RIR account. Registrations that predate your registry's current agreements may need a Registration Services Agreement in place first, which requires an authorized signer on your side. Start this early, because nothing else can proceed until it is done.
If your range is announced today, identify the ASN that originates it. This may be a carrier's ASN rather than your own, and the order of the next steps depends on knowing which it is.
Provide your registry records, your current routing status, and your ASN details.

At your registry

If the range is announced today and no ROA covers the ASN originating it, publish that ROA first. See the ordering note in Authorizing the Announcement.
Generate an RSA 2048-bit key pair and a self-signed X.509 certificate from it. The private key stays with your network team.
Publish the certificate in your registry record. This is a self-service change in your registry portal. If a third party maintains the record on your behalf, allow extra time, because records updated by hand can take days.
Publish the ROAs authorizing the ASNs we supply, with maximum prefix length matching the size of your range. Allow up to 24 hours for a new ROA to propagate.
Sign the authorization message with your private key. See Proof of Ownership in Your Registry Record.

Before the changeover

Move anything else using an address in the range off it. Once we begin announcing, every address in the range routes to Files.com whether or not we have activated it, so nothing can stay behind. See How Your IPs Are Assigned.
Test your site on its new addresses, across every access method your counterparties use.

At the changeover

Arrange for the existing announcement to be withdrawn. Ours begins after yours stops.

Afterwards

Remove the certificate from your registry record.
Record the ROA expiration date and name someone to own its renewal. An expired ROA takes your addresses off the internet.

Everything else belongs to Files.com: provisioning the range, activating your addresses, configuring your site, announcing the range, and confirming it is reachable.

How Your IPs Are Assigned

Your range is not provisioned as a subnet, and that is the single most useful thing to understand about how BYOIP behaves. Files.com advertises the prefix over BGP, then activates specific addresses from it and binds them to your site. Only activated addresses carry traffic; the rest of the block stays inert. There is no Layer 2 network, no gateway address, and no infrastructure addresses reserved out of your range: Files.com does not consume .1, .255, or anything else.

If you are used to planning address space as subnets, this is the assumption to drop. You do not set aside addresses for network overhead and you do not give us a usable-host range. You tell us which specific addresses you want live, and we activate those.

Each activated address serves every service on the site it is bound to (FTP, SFTP, FTPS, WebDAV, HTTPS, and the API) exactly as a dedicated IP does. There is no per-service binding.

Two addresses is the common case, matching a standard dedicated IP pair. If you need more, tell us how many and which ones.

Addresses can be reassigned between your sites. If you eventually split one site into regional child sites, we move addresses across without anything changing on your end, so equipment configured against a specific address keeps working.

You do not need to subdivide your range by region. Files.com treats the block as a single global range, and the same addresses serve your site regardless of where your users connect from.

While the announcement is active, the range serves Files.com only. The whole range is announced as one block, so every address in it routes to Files.com infrastructure whether or not we have activated it, and you cannot point part of the range at systems elsewhere.

Migrating to Your Own IPs

There are two ways to bring your range into service.

Additive migration. Files.com adds your range alongside your existing dedicated IPs and keeps both in service. This is the more common approach, because external systems that reference your current addresses, such as partner firewalls, allowlists, and embedded configurations in field equipment, can be updated on your own schedule instead of in a single cutover. Files.com keeps the original addresses in service indefinitely and removes them when you ask.
Replacement migration. Files.com switches your site to the new range and retires the original dedicated IPs.

Files.com handles the address assignment on the backend. No DNS changes are required on your end, and your TLS certificate does not need to be reissued.

If Your Range Is Already Announced Elsewhere

Many ranges arrive already carrying production traffic, announced from your own data center or by a carrier or hosting provider on your behalf. Bringing one to Files.com does not mean taking it out of service first, and there is no outage while the range is validated.

Provisioning and announcing are separate steps, and only the second is visible on the internet. Files.com can provision your range, activate your addresses, and configure and test your site while your existing announcement stays up and serves traffic normally. The changeover at the end is the only timed event.

You publish your ROA and registry certificate, following the ordering note in Authorizing the Announcement. Your current announcement is unaffected.
Files.com provisions the range, and your ownership is validated against the ROA and certificate. Most provisioning finishes within about two hours, but it can take up to a week, so we start well ahead of any target date.
Files.com activates the addresses you have chosen and configures your site to use them. Nothing has changed on the internet yet.
Both teams test the site on its new addresses.
Changeover. Your existing announcement is withdrawn, and Files.com then begins advertising the range. These are sequenced rather than simultaneous: a range advertised from two places at once is not guaranteed to route predictably, and the changeover itself may not complete until the earlier announcement has stopped.

The only interruption is the time the internet takes to converge on the new route. Your addresses themselves never change, so anything connecting to them, including field equipment configured with a hardcoded address, needs no reconfiguration.

Files.com verifies reachability from multiple networks after the changeover, and treats it as complete only once the range is reachable broadly. Propagation completes unevenly, and a route that is already live from one vantage point can still be invisible from another without anything reporting an error, so a single check from your own network is not conclusive.

One piece of preparation governs the schedule more than any other: everything else using the block has to be moved off it before the changeover, not after. Because the entire range is announced as one block, every address in it routes to Files.com from the moment we begin announcing, as described in How Your IPs Are Assigned. Any other service still using an address from the block, such as a proxy, a VPN concentrator, or a mail server, loses reachability at that moment. Inventory the block early, and plan the changeover for after that work is complete.

If that cleanup will not be finished in time, the date does not have to move with it. Files.com can bring your site up on dedicated IP addresses now and add your range later as an additive migration, which separates your go-live from your network cleanup entirely.

Ongoing Usage and Management

ROA validity. Your ROA carries an expiration date, and keeping it current is your responsibility. An expired or non-compliant ROA takes your site's addresses off the internet: validating networks reject the route, and the announcement may be withdrawn. Renew well ahead of the expiration date and keep those ASNs authorized for as long as you want the range announced.
Exclusivity. While in use with Files.com, your IP range must not be advertised from any other provider or network.
Routing visibility. Your IPs are globally visible and reachable, integrated with our high-availability infrastructure.
Support. Files.com provides ongoing support for all announced ranges, including routing health, DNS, and protocol-specific integrations.

Continue to resolve your site by hostname rather than by address. Even with your own range in place, hardcoding IP addresses into client applications bypasses the DNS-based failover and Geo-DNS routing that Files.com relies on.

Reverting to Files.com-Assigned IPs

You can stop using BYOIP at any time.

If you kept your original dedicated IPs in service through an additive migration, those addresses are still assigned to your site and remain usable with no action required. If you fully replaced them, contact Support to coordinate the transition back to Files.com-assigned addresses before the announcement is withdrawn.

In either case, tell us when you want us to stop announcing your range. We typically cease announcements within 48 hours. Once we withdraw the announcement, the range is yours to route elsewhere.

Get Started

To request BYOIP, contact your Account Manager or Files.com Support. We confirm eligibility, review your range, and coordinate the registry steps with your network team.