# ipranges keeps a daily copy of every cloud provider's address space > ipranges is a CC0 licensed collection of IPv4 and IPv6 CIDR lists for Google Cloud, GoogleBot, Bing, AWS, Microsoft, Oracle, DigitalOcean, GitHub, Facebook, Twitter, Linode, Telegram, OpenAI, Cloudflare, Vultr, Apple Private Relay, ProtonVPN and others, refreshed daily from public sources and published in both parsed and merged form. **lord-alfred/ipranges** — 🔨 List all IP ranges from: Google (Cloud & GoogleBot), Bing (Bingbot), Amazon (AWS), Microsoft, Oracle (Cloud), GitHub, Facebook (Meta), OpenAI (GPTBot) and other with daily updates. - Repository: https://github.com/lord-alfred/ipranges - Website: https://t.me/Lord_Alfred - Stars: 1,201 · Forks: 172 - Language: Shell - License: CC0-1.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/lord-alfred-ipranges ## Every provider's address space, refreshed daily ipranges does one job: it lists the IP ranges belonging to a set of large internet providers, and it keeps them current. The README describes it as listing all IP ranges from Google, covering both Cloud and GoogleBot, Bing or Bingbot, Amazon, Microsoft, Oracle Cloud, DigitalOcean, GitHub, Facebook or Meta, Twitter, Linode, Telegram, OpenAI or GPTBot, Cloudflare, Vultr, Apple Private Relay and ProtonVPN, with daily updates. The provenance is stated in one line, and it is the most important line in the repository for anyone using it: all lists are obtained from public sources. Nothing is scraped from a private feed and nothing is inferred, which means the accuracy of the data is the accuracy of the provider's own published ranges. That framing matters because the address space of a cloud provider is the one thing an operator cannot guess. A rule that says allow traffic from Amazon Web Services is only as good as your knowledge of what Amazon's addresses are, and providers change them, and they publish the changes as machine readable files that nobody wants to parse and merge by hand. The topic list on the repository gives a hint at the second audience, since it includes network security, osint, bug bounty, pentesting and cidr ranges. The same list serves a network engineer building an allowlist and a researcher narrowing down who operates an address. The licence is CC0-1.0, which is the most permissive thing a data project can be. There is no attribution requirement, which is what you want when the data is going to end up inside a firewall rule set that nobody will document. ## Two list types, and the merged one is the useful one There are two kinds of file for each address family, and the distinction is the reason the repository is more than a dump of text files. The first is ipv4.txt or ipv6.txt, described as the list of addresses, IPv4 or IPv6, which is the result of parsing one or more sources. That is the raw material: whatever the provider published, parsed into CIDR ranges. The second is ipv4_merged.txt or ipv6_merged.txt, the list of addresses after combining them into the smallest possible list of CIDRs. That second form is what a firewall rule wants. A provider publishing a thousand separate ranges that are actually adjacent produces a thousand rules where four would do, and every rule is a line of configuration somebody has to review. Merging collapses the adjacent ranges into the smallest equivalent set, which reduces the rule count and the chance of a stale gap in the allowlist. The merging also has a security consequence worth thinking about. Merging does not widen the data: the merged file covers the same addresses as the parsed one, only in fewer, larger CIDRs. That makes it shorter to review, not a broader allowlist surface. Both forms are published for every provider that has both address families, and the file naming convention is consistent, which is what makes the repository usable from a script rather than by hand. ## The Google and GoogleBot split is the case that needs both The one usage instruction in the README is about Google, and it is worth reading closely because it shows the intended use of the data. Google is published twice. The google/ directory holds Google Cloud and GoogleBot, and the googlebot/ directory holds the crawler specifically. The instruction is: to allow GoogleBot, block all Google IP addresses and then allow the GoogleBot addresses. That is an ordering requirement, and it is the reason a crawler list is worth separating from the general one. If you allow the GoogleBot ranges first and then block Google, the block wins and the crawler is blocked with everything else. The correct sequence is block the broad set, then punch the narrower set back through, and the two directories exist so that the second step has a source of truth for the narrow set. This is also the general shape of using the repository. The lists are inputs to an ordering decision, not a finished policy, and the finished policy is whatever your firewall or proxy makes of them. The per provider structure is consistent. Each provider has a directory with ipv4.txt, ipv4_merged.txt and, where the provider publishes them, ipv6.txt and ipv6_merged.txt. The repository root shows the full set of directories, and among them are all/ for the combined lists, utils/ for the scripts, and smaller ones for DuckDuckBot, duckassistbot, Perplexity, Pingdom, StatusCake and Vultr. ## The lists are plain text, and the URLs are stable The distribution model is the simplest one available. All addresses are stored in .txt files with CIDRs, where each range is on a new line, and each file is served from a raw URL on the main branch: ```bash https://raw.githubusercontent.com/lord-alfred/ipranges/main/google/ipv4.txt https://raw.githubusercontent.com/lord-alfred/ipranges/main/google/ipv4_merged.txt ``` There is no packaging, no index file and no API. A consumer fetches a URL, gets one range per line, and does whatever it does with them. The choice of raw.githubusercontent.com over a release asset is deliberate in effect even if the README does not say so, because a file on a branch is always the current version, so a cron job that fetches the same URL every morning gets the refreshed list without any version tracking. That is also the mechanism behind the daily updates. The primary language of the repository is Shell, and the utils/ directory holds the scripts, so the refresh is a set of shell scripts that pull the public sources, parse them into the ipv4.txt and ipv6.txt files, and produce the merged variants. The layout also makes the repository usable as a git dependency. A firewall configuration that vendors these lists can pin a commit and get a reviewable diff when the lists change, which is the difference between an allowlist you can audit and one you cannot. What the repository does not have is versioned releases. There are no GitHub releases, so a consumer that wants a fixed snapshot has to pin a commit hash rather than a tag, and the README does not document a stable endpoint other than the branch URLs. ## Which providers publish IPv6, and where the gaps are The IPv4 and IPv6 coverage is not uniform, and anyone building a dual stack allowlist needs to know where the gaps are before they rely on it. The providers with both address families in the repository include Google, GoogleBot, Amazon, Microsoft, DigitalOcean, GitHub, Facebook, Twitter, Linode, Telegram, Cloudflare and Vultr, each with ipv4.txt, ipv4_merged.txt, ipv6.txt and ipv6_merged.txt listed. The providers with IPv4 only in the repository are Bing, Oracle, OpenAI, ProtonVPN and Perplexity. For a company that has decided its OpenAI traffic must leave through a specific egress, that gap is the whole question, and the answer has to come from OpenAI's own published ranges rather than from this repository. The ProtonVPN entry is also a special case, described as the exit nodes rather than the provider's full address space, and Apple's is described as Private Relay, which is a specific service rather than every address Apple owns. Both are narrower sets than the name might suggest to someone who has not read the line, and the directory names reflect that, with apple-proxy/ and protonvpn/ rather than apple/ and protonvpn-provider. The general rule that follows is simple. Treat each directory as the publisher's own published set, filtered to what that publisher makes available, and go back to the source when a provider publishes something this repository does not carry. ## What a range list cannot tell you It is worth being explicit about the limits of the data, because the topic list suggests it will be used for attribution as well as for access control. A CIDR list tells you which addresses a provider says are theirs. It does not tell you who is using an address inside that range. A cloud provider's ranges contain customer workloads, scanners, bots, and anything else that has been allocated to them, so a list entry answers a question about ownership of the address, not about the identity of the operator behind it. If you need the operator, the list is a starting point rather than an answer. It is also a snapshot of what was published when the script last ran. The daily update is a claim about freshness that depends on the upstream source being updated, and the merge step means a small upstream change can alter a larger merged range. For a firewall that is usually fine, because the risk of a slightly stale allowlist is a legitimate request being dropped, which fails visibly. For a blocklist the failure mode is different, because a stale block range can block traffic that should have been allowed, silently. The last limitation is the one the README states for you. The lists are obtained from public sources, and a provider that does not publish its ranges publicly will not appear here. Absence from the repository is not evidence that a range is unused, it is only evidence that nobody published it in a form the scripts could parse. The alternative approach, and the one most organisations end up with, is to consume the provider's own machine readable file directly and skip the aggregation layer. The difference in approach is that this repository does the parsing and the merging once, for every provider it covers, on a schedule, and hands you a uniform format. If you only need one provider, reading its published file yourself is fewer moving parts. ## CC0, a shell pipeline, and daily commits The licence deserves a second look, because for a data project it is the whole deal. CC0-1.0 is a public domain dedication, so the lists can be used in a firewall configuration, in a script, in a commercial product or in a report, with no attribution requirement and no obligation to share anything derived from them. That matters more here than it would for a code project. The data is a compilation of other people's published ranges, and the compilation carries the parsing and the merging work. CC0 puts the compilation into the public domain while the underlying data stays with whoever published it, and a careful organisation will still read the provider terms, but the repository itself asks for nothing in return. The maintenance picture is simple and, for a data pipeline, healthy. The repository is not archived, the last push was on 2026-10-15, and the updates are described as daily. There are no GitHub releases, which is consistent with a repository whose tracked output is a set of text files that change every day, and with a Shell implementation whose whole job is a scheduled refresh. For a consumer, the operational consequence is that you pin a commit if you need reproducibility and you refresh on a schedule if you need freshness, and the choice between those two is a policy decision rather than a technical one. The topics on the repository place it firmly in the reconnaissance and network security side of open source, and the homepage listed is a Telegram channel, which suggests the author also distributes the lists there. ## Conclusion ipranges suits a network or security team that maintains allowlists for cloud provider traffic, or a researcher who needs to know which address space belongs to which provider, and who wants the lists as plain text they can pipe into a firewall or a script. It does not suit anyone who needs a guarantee about who is on the other end of an address, because the lists are only as good as the upstream sources, and several providers publish IPv4 only. Verify first that the provider you care about publishes both address families in this repository, and that your firewall tooling can consume a file with one CIDR per line rather than a formatted rule set. ## FAQ ### What is the ipranges repository? It is a collection of IPv4 and IPv6 CIDR lists for providers including Google, GoogleBot, Bing, AWS, Microsoft, Oracle, DigitalOcean, GitHub, Facebook, Twitter, Linode, Telegram, OpenAI, Cloudflare, Vultr, Apple Private Relay and ProtonVPN, with daily updates obtained from public sources. ### What is the difference between ipv4.txt and ipv4_merged.txt? The ipv4.txt file is the list of addresses as a result of parsing one or more sources, while ipv4_merged.txt is the same list after combining the ranges into the smallest possible list of CIDRs. ### How do I allow GoogleBot traffic while blocking other Google traffic? The README states that you should block all Google IP addresses first and then allow the GoogleBot addresses, using the google/ directory for the broad set and the googlebot/ directory for the crawler ranges. The order matters, since the broad block would otherwise cover the crawler. ### Which providers in ipranges publish IPv6 ranges? The README lists IPv6 files for Google, GoogleBot, Amazon, Microsoft, DigitalOcean, GitHub, Facebook, Twitter, Linode, Telegram, Cloudflare and Vultr, while Bing, Oracle, OpenAI, ProtonVPN and Perplexity are listed with IPv4 only. ### What licence does ipranges use and how are the files distributed? The repository is licensed under CC0-1.0, and all addresses are stored in .txt files with CIDRs, one range per line, served as raw files from the main branch of the repository. ## Sources - [Issues](https://github.com/lord-alfred/ipranges/issues) - [License: CC0-1.0](https://github.com/lord-alfred/ipranges/blob/main/LICENSE) - [lord-alfred/ipranges on GitHub](https://github.com/lord-alfred/ipranges) - [Project website](https://t.me/Lord_Alfred) - [README](https://github.com/lord-alfred/ipranges/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lord-alfred-ipranges