There's no single best place in the world to host your servers, but there is a best place for your project. Here's how location shapes speed, compliance, and reliability, and how to pick the right one.
]]>So is there a single best location for hosting? The honest answer is no, and anyone who tells you otherwise is probably trying to sell you a specific region. The more useful answer is that the right location depends on a handful of factors you can actually reason about, and once you understand them, the choice gets a lot less mysterious.
Let's walk through what location really changes, then get practical about how to choose.
The reason there's no universal best spot is simple: hosting serves wildly different goals. A game server for players in Sydney has nothing in common with a compliance-bound database for a German company, which has nothing in common with a low-latency trading box that needs to sit next to a financial exchange in Tokyo.
Each of those has a clearly correct answer. None of them is the same answer. So instead of hunting for one perfect city, you're really matching a location to the thing you're trying to do. That reframing is the whole trick.
Four things shift when you move your servers around the map. Get a feel for these and most decisions make themselves.
Latency is the delay between a request leaving your user's device and a response coming back. The biggest single factor is distance, because data still has to physically travel, and even light in a fiber cable has a speed limit. As a rough rule, signals move through fiber at around two-thirds the speed of light, which works out to roughly 1 millisecond of latency for every 100 kilometers, each way.
That sounds tiny until you stack it up. A user in London hitting a server in San Jose is looking at a round trip of well over 130 milliseconds before the server even does any work. For a static page, fine. For a chatty application that makes dozens of sequential calls, or anything real-time, that delay compounds into something users feel.
The takeaway: the closer your server sits to the people using it, the snappier everything feels. Distance is the cost you pay in milliseconds.
Here's where a lot of people get caught out. Two cities can be the same distance from your users and still deliver very different performance, because what matters isn't the straight-line distance, it's the route the traffic actually takes.
A well-connected data center sits near major Internet Exchange Points and peers directly with lots of networks, so your traffic takes a short, direct path. A poorly connected one might route your packets halfway across a continent and back before they reach their destination. This is why cities like Amsterdam, Frankfurt, Tokyo, and Singapore show up again and again in hosting maps: they're dense interconnection hubs where networks meet, so traffic in and out tends to be fast and well-peered.
If you want to see this for yourself rather than take a provider's word for it, a looking glass lets you check the real network path and round-trip time from a given location back to your part of the world. It's one of the most honest ways to compare two facilities.
Where your data physically lives decides which laws apply to it. If you handle personal data from people in the European Union, the GDPR shapes how and where you can store it, and hosting inside the EU often makes compliance simpler. Other regions have their own rules about data residency, government access, and privacy.
This is the factor people forget until it bites them. Cost and latency can be optimized later; a legal requirement to keep certain data in a certain country is not negotiable. If you operate in a regulated industry or serve a specific market, sort this out before you think about anything else.
Prices vary by region, sometimes a lot, driven by local electricity costs, real estate, taxes, and how competitive the market is. A rack in one metro can cost noticeably more than an equivalent setup elsewhere. Hardware availability and the specific services on offer also differ from one location to the next. None of this should override a hard latency or compliance need, but when two locations are otherwise close, cost is a fair tiebreaker.
With those factors in mind, here's a practical way to land on a decision without overthinking it.
Run through those five steps and you'll usually find the choice was never really about the single best city. It was about the best fit for your specific traffic, rules, and budget.
Sometimes the honest answer is that no single location works, because your users are genuinely spread across the globe or you can't afford a regional outage to take you offline.
In that case, you spread out on purpose. A common pattern is to run servers in two or three regions, say one in North America, one in Europe, and one in Asia Pacific, and route each user to the nearest one. This cuts latency for everyone and gives you redundancy, so a problem in one region doesn't take down the whole service. Content delivery networks take this idea further by caching static assets at the edge, close to users, while your core application still lives in a chosen home region.
Multi-region setups add complexity around data synchronization and cost, so they're not the default for every project. But for global audiences or services that can't go dark, distributing across locations beats trying to crown one winner.
There's no single best location for hosting, and chasing one is a distraction. The better move is to match a location to your project: host near your users, respect the laws that apply to your data, favor well-connected facilities, and spread across regions when one site can't cover everyone. Decide in that order and the "best" location reveals itself.
Picking the right region only pays off if the infrastructure underneath it is solid. xTom runs facilities across Asia Pacific, North America, and Europe, with dedicated servers and colocation in major interconnection hubs, scalable NVMe-powered KVM VPS through V.PS, IP transit for networks that want their own routing, shared hosting for simpler projects, and a range of general IT services to round it out.
Ready to discuss your infrastructure needs? Contact our team to explore the right location and setup for your project.
Yes. The farther data has to travel between your server and your users, the higher the latency, and the slower pages feel. Network quality and peering matter too, but for most sites, hosting closer to your main audience is one of the easiest performance wins available.
In most cases, near your users, because distance is the biggest driver of latency. That said, a location close to a major interconnection hub often gives you both, since those hubs tend to sit in or near large population centers and offer excellent peering. When forced to choose, prioritize proximity to your audience.
Data sovereignty means the data you store is subject to the laws of the country it physically sits in. If you handle regulated or personal data, rules like the GDPR may require you to keep it within a specific region. Sort out these requirements before optimizing for speed or cost, since legal obligations aren't something you can engineer around later.
If your users are spread across multiple continents, or you can't tolerate a regional outage, then yes, a multi-region setup lowers latency for everyone and adds redundancy. For a project with a single regional audience, one well-chosen location is usually simpler and plenty.
There's no single winner, but cities like Amsterdam, Frankfurt, Tokyo, Singapore, and the major US metros are known for dense interconnection and strong peering. The practical way to compare is to test real round-trip times from your users' networks rather than relying on reputation alone.
]]>Getting your own IP addresses can mean going straight to a Regional Internet Registry for next to nothing, or paying to lease or buy space on the open market. Here's how each route works, what it costs, and which one actually fits your situation.
]]>It's a fair question, and the honest answer is that there's more than one path. You can go straight to the source and request space directly, which costs almost nothing but tends to take a while. Or you can pay for it on the open market, either by leasing addresses month to month or buying them outright. Each route trades off cost, speed, and how much control you walk away with.
Let's walk through all three, starting with the free and patient option, then moving into the paid routes.
Before picking a route, it helps to know who hands these things out. No single company owns the internet's address space. At the top sits IANA, the Internet Assigned Numbers Authority, which carves the global pool into large chunks and distributes them to five regional bodies called Regional Internet Registries, or RIRs.
Those five registries each cover a part of the world: ARIN for North America, RIPE NCC for Europe, the Middle East, and parts of Central Asia, APNIC for the Asia-Pacific region, LACNIC for Latin America, and AFRINIC for Africa. If you want a deeper look at how this whole system is structured, we've covered it in our guide to what a Regional Internet Registry is.
Which registry matters to you depends on where your organization is legally based. That's the front door for the free route, so let's start there.
The cheapest way to get your own addresses is to request them directly from your registry. There's a twist, though: this route behaves completely differently for IPv6 than it does for IPv4.
This is where the "free" part really holds up. To get space directly, your organization usually becomes a member of its RIR. In the RIPE region that membership makes you a Local Internet Registry, or LIR. It isn't literally free; RIPE NCC charges a one-time sign-up fee plus an annual service fee, which in 2026 works out to roughly €1,000 to join and €1,800 a year. But once you're in, your first IPv6 allocation, typically a /32, comes at no extra charge and with very little paperwork. RIPE generally just wants a simple statement that you plan to deploy it within the next year.
If full membership feels like overkill, end users can also get provider-independent IPv6 space through a sponsoring LIR, which is lighter and cheaper than running your own registry account.
The reason IPv6 is so painless is supply. There's an almost unimaginable number of IPv6 addresses, so registries are happy to hand them out. The catch is adoption: plenty of the internet still leans on IPv4, so IPv6-only deployments can hit compatibility gaps. If you're weighing the two, our breakdown of IPv4 vs IPv6 goes through the practical differences.
IPv4 is a different story. The world ran out of fresh IPv4 addresses years ago. ARIN's free pool ran dry back in September 2015, and the other registries followed. So you can't simply ask for a brand-new block and get one.
What you can do is join the IPv4 waiting list. When addresses get returned, reclaimed, or revoked for non-payment, registries redistribute them to organizations waiting in line. It costs nothing beyond your membership fees, but the constraints are real. The wait is long; at RIPE, members typically sit on the list somewhere between 12 and 24 months. The block is small, too: RIPE hands out a single /24, which is 256 addresses, while ARIN's waitlist tops out at a /22 and lets you elect a smaller size down to a /24. Eligibility is limited as well, since ARIN won't add you to the list if you already hold a /20 or more. And there's a holding period: addresses from ARIN's waitlist can't be transferred to anyone else for five years.
So the free route is genuinely cheap, but it rewards patience and suits organizations that can plan months ahead. If you need addresses now, you're looking at the paid market.
There are two flavors of paying for IPv4: renting it or owning it. Both pull from what's called the secondary market, since registries no longer sell from a fresh pool.
One thing both routes share is that getting the addresses is only half the job. To actually use them on the public internet, the routes to your block have to be announced using BGP, the protocol that tells the rest of the internet where your addresses live. That usually means having your own Autonomous System Number, or ASN, plus an upstream provider willing to carry your announcements through IP transit. If you lease through a hosting provider that already announces the space for you, this part is handled on your behalf.
Leasing means renting address space: you pay a monthly fee while someone else keeps ownership. It's the faster, lower-commitment option, which makes it popular with startups, short-term projects, and anyone bridging toward IPv6.
Lease rates have stayed steadier than purchase prices over the years. As of 2026, most blocks in the RIPE and ARIN regions lease for roughly $0.30 to $0.50 per IP per month, with APNIC space running higher, often above $0.60, because supply there is tighter. A /24 of 256 addresses tends to land somewhere in the rough neighborhood of $80 to $150 a month, though the exact figure depends on block size, region, and the reputation of the addresses.
Marketplaces like IPXO and IPv4.Global connect holders of unused space with people who want to lease it. Reputation matters more than people expect here; if a block was previously used by a spammer and landed on blocklists, your mail and traffic can suffer, so it's worth checking a block's history before you commit. You can look up who a block is registered to and its current status using an RDAP lookup, and we built a free RDAP client for exactly that.
The downside of leasing is that you never own the asset. Stop paying and the addresses go back. For a lot of businesses that's a perfectly fine trade for the flexibility.
Buying gives you the addresses outright. Since registries don't sell from a fresh pool anymore, a purchase is really a transfer: ownership of an existing block moves from the seller to you, recorded officially through your RIR's transfer process, such as ARIN's section 8.3 transfer.
In 2026, IPv4 sells for roughly $20 to $45 per address depending on block size and region. Larger blocks like a /16 have actually dropped below $20 per IP, while smaller and more in-demand /24s sit at the higher end. Buying a single /24 outright, then, runs somewhere in the rough range of $9,000 to $12,000 as a one-time cost.
What you get for that is permanent control, no recurring lease fees, and an asset you can resell or even lease out yourself later. What you take on is a significant upfront cost, responsibility for the block's reputation, and a transfer process where you'll need to meet your registry's policies and justify the need. Brokers handle the paperwork and escrow for a cut, which is worth it for most first-time buyers.
Buying makes the most sense when you have long-term, stable address needs and you'd rather own the space than carry an ongoing bill.
Pulling it all together, here's a sensible way to approach it.
Start by figuring out what you actually need. How many addresses, and IPv4, IPv6, or both? A handful of IPv6 addresses for a modern deployment is a very different ask from a /22 of IPv4 for a hosting fleet. Be honest about your timeline too, because that single factor often decides the route for you.
If you can wait and you mostly need IPv6, go straight to your RIR. Identify your region's registry, become a member or work through a sponsoring LIR, and request your allocation. You'll have IPv6 quickly, and you can park yourself on the IPv4 waiting list at the same time.
If you need IPv4 soon and want flexibility, lease it. Pick a reputable marketplace, or a hosting provider that includes address space, check the reputation of any block before you commit, and confirm how the addresses will be announced.
If you need IPv4 for the long haul and want to own it, buy through a broker or directly from a seller, and budget for the transfer process through your RIR.
Whichever route you take, make sure you can actually route the space. That means sorting out your ASN, BGP, and an upstream willing to carry your announcements before the addresses are any use. If you're getting the space bundled with hosting or transit, your provider usually takes care of all of that.
Obtaining your own IP addresses comes down to a trade between time and money. The free route through a Regional Internet Registry costs little beyond membership and gets you IPv6 quickly, but IPv4 means a long wait for a small block. Leasing gets you IPv4 fast without a big upfront spend, at the cost of ongoing fees and no ownership. Buying hands you permanent control and resale value, but it asks for real money up front and a bit of paperwork. None of them wins across the board; the right one depends on your timeline, your budget, and how much you want to own.
If you'd rather skip the registry queues and routing headaches altogether, xTom can provide the infrastructure with address space already sorted. We offer enterprise-grade dedicated servers and colocation, scalable NVMe-powered KVM VPS through V.PS, IP transit to carry your announcements, shared hosting, and a full range of general IT services to round things out.
Ready to discuss your infrastructure needs? Contact our team to find the right setup for your project.
More or less, for IPv6. Once you're a member of your Regional Internet Registry, your first IPv6 allocation comes at no extra charge beyond membership fees. IPv4 is harder; you can join your registry's waiting list at no extra cost, but you'll wait a year or two for a small block. Truly free IPv4 on the open market no longer exists.
As of 2026, most blocks in the RIPE and ARIN regions lease for roughly $0.30 to $0.50 per IP per month, with APNIC space running higher. A /24 of 256 addresses lands around $80 to $150 a month, depending on block size, region, and the reputation of the addresses.
About $20 to $45 per address in 2026, depending on block size and region. Larger blocks cost less per IP, while smaller /24s cost more. A single /24 works out to roughly $9,000 to $12,000 as a one-time purchase.
If you want to announce the space yourself on the public internet, then yes, you'll generally need your own ASN and a BGP setup, along with an upstream provider to carry your announcements. If you lease addresses through a hosting provider that announces them for you, you don't need your own ASN.
Leasing is renting: lower upfront cost, monthly fees, no ownership, and easy to scale up or down. Buying is owning: high upfront cost, no recurring fees, full control, and the option to resell later. Leasing suits short-term or uncertain needs; buying suits long-term, stable ones.
Look up its registration and history first. An RDAP lookup shows who a block is registered to and its status, and you can check whether the addresses appear on any blocklists.
The one covering where your organization is legally based: ARIN for North America, RIPE NCC for Europe and the Middle East, APNIC for the Asia-Pacific region, LACNIC for Latin America, and AFRINIC for Africa.
]]>IPv4 prices went through one of the sharpest corrections on record in 2025, and 2026 is showing the first real signs of a turnaround. Here's what the latest market data says an IP address actually costs this year, and what's driving the numbers.
]]>When people talk about paying for IP addresses, they're almost always talking about IPv4. IPv6 is so abundant that registries effectively give it away; once you're a member of your registry, an IPv6 allocation usually comes at no extra charge. There's no meaningful resale market because there's no scarcity. If you want the background on why the two protocols behave so differently, our explainer on IPv4 vs IPv6 covers it.
IPv4 is the opposite. There are only about 4.3 billion addresses, the free pools at the registries are exhausted, and roughly 3.9 million unallocated addresses are left worldwide, mostly sitting in the APNIC and AFRINIC regions. Practically speaking, the only way to get IPv4 now is the secondary market: buying or leasing existing space from whoever already holds it. That scarcity is the whole reason a price exists at all. So for the rest of this article, "IP address prices" means IPv4 prices.
Pricing depends heavily on the size of the block you're after, the region it's registered in, and the reputation of the addresses. As a rough guide, here's where the market sits in 2026 based on data from IPv4.Global, the largest IPv4 marketplace, alongside lease figures tracked by platforms like IPXO.
| Block size | Addresses | Approx. purchase price per IP | Approx. lease per IP / month |
|---|---|---|---|
| /24 | 256 | $28 to $40 | $0.38 to $0.50 |
| /22 | 1,024 | $22 to $30 | $0.38 to $0.48 |
| /20 | 4,096 | $21 to $30 | $0.35 to $0.45 |
| /16 | 65,536 | $13 to $22 | $0.30 to $0.40 |
A couple of things stand out. First, the per-address price drops as blocks get larger, which is normal, but the gap has stretched to an unusual degree (more on that in a moment). Second, leasing has stayed remarkably stable while purchase prices swung wildly.
To put that in real money: buying a single /24 outright runs somewhere around $7,000 to $9,000 as a one-time cost, while leasing the same block lands near $100 to $130 a month. A /20 leases for roughly $1,500 to $1,800 a month. If the slash notation is unfamiliar, our guide to IPv4 vs IPv6 block sizes breaks down how many addresses each prefix holds.
Region matters too. ARIN-registered space has historically commanded a 5 to 15% premium over RIPE addresses, mostly because of where buyers want their traffic to appear, while APNIC purchase prices tend to run lower. Leasing flips that for APNIC, where tight supply pushes lease rates above $0.60 per IP per month. The differences come down to which Regional Internet Registry governs the block.
The 2026 numbers only make sense against the backdrop of what just happened, and it's a genuinely dramatic arc.
Rewind to late 2023. At that point, big blocks were the expensive ones. IPv4.Global data showed /16 and larger blocks trading near $52 per address, while smaller /20 to /24 blocks changed hands closer to $36. That 44% premium for large blocks was historically odd, and the reason was specific: hyperscale cloud operators were hoarding large, contiguous blocks to expand their infrastructure, and their appetite dragged prices up to levels that couldn't last.
That demand held until around July 2024, then the floor gave way. By the second half of 2024, the premium had evaporated entirely and blocks of every size were trading at roughly the same $33 per address. The convergence surprised plenty of people who'd treated the large-block premium as permanent.
It didn't stop at convergence. Through 2025, large blocks fell off a cliff. A /16 that started the year near $33 per address dropped below $13 by the fourth quarter, with some bulk deals clearing under $10. That's a contraction of more than 60% in a single year, and a ten-year low. In May 2025, the /16 slipped under $20 per address for the first time since 2019, which became the headline marker of how far things had fallen. Mid-size blocks followed the slide, with /17 to /19 ending the year near $16 and /20 to /21 near $21.
Here's the part that matters most, though: demand never actually broke. Transaction volume stayed strong throughout the decline. In July 2025, IPv4.Global recorded 98 transactions in the month against a typical average of 73, a 32% jump, even as prices were sinking. When price falls but volume rises, that's not a market collapsing. It's a market repricing to a new level, with a broader base of buyers stepping in.
Small blocks, the /22 to /24 range, told a completely different story through all of this. They dipped, but only modestly, and by mid-2025 they were trading at more than double the per-address rate of /16s. The old pattern, where buying big got you a steep discount, didn't just narrow; it reversed into an extreme.
The reason is who's buying. Small blocks have a wide, steady, practical buyer base: regional ISPs, hosting providers, and businesses that need a targeted slice of addresses for a specific project. That demand shows up month after month regardless of what the giant blocks are doing. On top of that, cloud platforms like AWS and Azure now charge for IPv4 usage, which pushes companies to buy their own space on the secondary market and bring it to the cloud through BYOIP programs. That's a structural floor under small-block prices that simply doesn't exist for /16s.
One of the clearest lessons in the 2025 data is how differently leasing and buying behaved. While purchase prices for large blocks were losing 60% of their value, lease rates barely moved, holding in a $0.38 to $0.50 per IP per month band across most RIPE and ARIN blocks. That stability is exactly why a lot of businesses treat leasing as the lower-risk option.
The trade-off is straightforward. Leasing means predictable monthly costs, no big upfront spend, and the freedom to scale up or down, but you never own the asset. Buying means a large one-time cost and responsibility for the block's reputation, in exchange for permanent control and an asset you could resell or lease out later. The wild swings on the purchase side are precisely what make leasing feel safe, and the steadiness of leasing is part of what puts a floor under small-block purchase prices.
Whichever way you go, owning or leasing the addresses is only useful if you can route them. That means having an Autonomous System Number, announcing the space with BGP, and an upstream provider carrying your routes through IP transit, unless you're getting the space bundled with hosting that handles all of that for you.
A handful of forces are shaping the numbers this year. On the supply side, legacy holders like universities, telecoms, and restructured companies spent 2024 and 2025 monetizing address space they weren't using, which flooded the large-block market and drove those prices down. At the same time, the hyperscale cloud buyers who'd propped up large-block pricing largely stepped back.
On the demand side, a new category showed up: AI infrastructure. GPU clusters and the data centers behind them need IPv4 for management networks, API endpoints, and customer-facing services, and that demand barely existed during the last big buying cycle. Broadband buildouts are adding pressure too; the US BEAD program, a roughly $42 billion push to expand rural coverage, is expected to lift IPv4 demand by 10 to 20% as providers build the networks that deliver those connections. Reputation also moves prices at the margins, with clean, well-documented blocks commanding a 10 to 15% premium over space with a spotty history. Before you commit to any block, it's worth checking its registration and reputation, which you can do with an RDAP lookup.
Hanging over all of it is IPv6. Adoption keeps creeping forward, and every network that goes IPv6-native is one that needs a little less IPv4. That doesn't crater prices overnight, but it does cap how high they can realistically climb over the long run.
Based on the first four months of 2026, the market looks like it found its floor. January brought record transaction volume and a wave of new buyers. February held steady and even ticked up for some block sizes. March delivered a measurable price increase across the board, and April confirmed it with broad demand spread across block sizes rather than concentrated in one corner.
IPv4.Global's own projection, published in June 2026, expects a gradual recovery through year-end: large /16+ blocks climbing from their $10 to $13 lows toward $15 to $22 per address, medium blocks landing in the $18 to $30 range depending on size, and small /22 to /24 blocks holding firm around $30 to $36, with ARIN space at the higher end. None of that is a return to the 2022 peak, and it's a projection rather than a promise, but the direction has clearly shifted from "how far will it fall" to "how fast will it recover." If AI infrastructure demand accelerates, the recovery could move faster than those figures suggest.
IPv4 prices in 2026 are best understood as a market coming out of a steep correction. Large blocks lost more than 60% of their value in 2025 before bottoming out near ten-year lows, small blocks held firm and now cost more per address than the big ones, and leasing stayed steady through all of it at roughly $0.40 per IP per month. Early 2026 data points to a measured recovery, driven by steady operational demand, a new wave of AI infrastructure buyers, and tightening supply. For anyone budgeting for address space this year, the headline is that timing and block size matter more than they have in a long while.
If you'd rather not navigate the secondary market and registry transfers yourself, xTom can provide the infrastructure with address space already handled. We offer enterprise-grade dedicated servers and colocation, scalable NVMe-powered KVM VPS through V.PS, IP transit to carry your announcements, shared hosting, and a full range of general IT services to round things out.
Ready to discuss your infrastructure needs? Contact our team to find the right setup for your project.
It depends on block size and region, but as a rough guide, expect roughly $28 to $40 per address for a small /24 block and $13 to $22 for a large /16. Per-address prices fall as blocks get bigger. A single /24 of 256 addresses works out to somewhere around $7,000 to $9,000 to buy outright, or about $100 to $130 a month to lease.
Large blocks fell more than 60% over the year, mainly because legacy holders started selling off unused address space at the same time that hyperscale cloud operators, who had been the biggest buyers of large blocks, stepped back from the market. More supply plus less demand at the top end pushed prices to ten-year lows.
Small blocks have a broad, steady base of buyers, including hosting providers and businesses bringing their own addresses to cloud platforms, so demand stays consistent. Large blocks depend on a much smaller set of big buyers, and when those buyers stepped back, large-block prices fell faster. By mid-2025, small blocks were trading at more than double the per-address rate of the largest blocks.
It depends on your time horizon. Leasing costs roughly $0.38 to $0.50 per IP per month and avoids a big upfront spend, which suits short-term or variable needs. Buying costs more up front but has no recurring fees and gives you a resellable asset, which suits long-term, stable requirements. Lease rates stayed steady even while purchase prices swung sharply, so leasing is often the lower-risk choice.
Yes. ARIN-registered addresses typically carry a 5 to 15% premium over RIPE space on purchases, while APNIC purchase prices tend to run lower. For leasing, APNIC often costs more, above $0.60 per IP per month, because supply there is tighter.
The early 2026 data suggests prices have bottomed out and begun a gradual recovery, helped by strong demand and new buyers from AI infrastructure. Most market observers expect modest increases through year-end rather than a sharp spike, though projections are not guarantees and prices vary widely by block.
No. IPv6 is plentiful enough that there's no real resale market, and a first IPv6 allocation usually comes at no extra cost beyond your registry membership fees. The pricing pressure that affects IPv4 simply doesn't apply to IPv6.
]]>A point of presence (PoP) is the physical spot where one network meets another and hands off traffic, and it quietly shapes how fast your sites and apps feel. Here's what a PoP actually is, what lives inside one, and how to check a provider's PoP footprint before you commit.
]]>PoPs are everywhere in networking, and they shape real things like latency, reliability, and how close your servers can get to the people using them. But the term gets used loosely, so it helps to slow down and look at what a PoP really is, what sits inside one, and why it matters when you're choosing where to host. Let's break it down.
At its simplest, a point of presence is a physical location where a network connects to other networks and to the wider internet. It's the spot where traffic gets handed off between different parties. If you connect to the internet through an ISP, the place where your traffic enters that ISP's network is a PoP. If a provider sells you transit or colocation, the facility where their routers live and interconnect with everyone else is also a PoP.
The term goes back further than the internet as we know it. After the court-ordered breakup of the Bell telephone system in the United States, a point of presence was the location where a long-distance carrier could hand traffic off into the local phone network. The core idea stuck around: a PoP is a boundary, a meeting point where one network ends and another begins. The technology underneath has changed a lot since the days of phone switches, but the concept has aged well.
These days, when a hosting or transit provider talks about their PoPs, they usually mean the cities and facilities where they have networking gear installed and connected. A provider with PoPs in Frankfurt, Tokyo, and San Jose has a physical footprint in all three, with equipment ready to carry your traffic and exchange it with other networks nearby.
A PoP isn't a single machine; it's a collection of networking hardware living inside a data center, often in leased rack space. The exact contents vary, but most PoPs share a similar cast of equipment.
You'll typically find routers, which are the devices that decide where traffic goes next and speak BGP to the rest of the internet. There are switches that move traffic around locally within the facility. There's cabling and cross connects, the physical links that join a provider's gear to other networks in the same building, including internet exchange points where many networks meet to swap traffic directly. And depending on the operator, there may be servers too, whether for caching, DNS, monitoring, or actual customer workloads.
The data center wrapped around all of this supplies the boring but important stuff: power, cooling, physical security, and fire suppression. A PoP only works because the facility keeps the lights on and the temperature steady around the clock.
One thing worth clearing up early: a PoP and a data center aren't quite the same thing. A data center is the building. A PoP is a network's presence inside that building. A single large facility can host PoPs for dozens of different networks, all sitting in their own cages and cabinets, interconnecting with each other. So when xTom announced its point of presence at Global Switch in Singapore, that meant installing networking equipment inside that facility and lighting up connectivity there, not building the data center itself.
To see why PoPs matter, it helps to picture how your data travels. When you load a page, your request leaves your device, reaches your ISP's nearest PoP, and from there hops across one or more networks until it arrives at the server holding the content. Each of those hops adds a little time. The fewer and shorter the hops, the snappier everything feels.
This is where a provider's PoP footprint starts to matter for you directly. If a network has PoPs close to your users, traffic can stay local instead of taking a long detour across continents. Networks that interconnect at a lot of locations can also lean on peering and IP transit to find efficient routes, which tends to mean lower latency and fewer surprises during congestion.
It's the same logic that makes a content delivery network (CDN) effective. A CDN spreads cached copies of your content across many PoPs, often called edge locations, so a visitor in Sydney gets served from somewhere nearby rather than from an origin server on the other side of the world. The PoP is the building block that makes that closeness possible.
PoPs also feed into redundancy. A network with presence in multiple cities can keep traffic flowing if one site or one upstream link has trouble, because there are other paths available. A single PoP is a single point of failure; several well-connected PoPs are a safety net.
If you're picking where to host servers or buy transit, the PoP question is worth a few minutes of homework. Here's a practical way to go about it.
Start by finding out where the provider's PoPs actually are. Most serious operators publish a list of their locations, and you want those locations to line up with where your users or your other infrastructure live. A provider with great coverage in Europe doesn't help much if your audience is in Southeast Asia.
Next, check the provider in PeeringDB, a free public directory that lists networks, the facilities they're present in, and the internet exchanges they connect to. It's one of the most honest signals you'll find, because networks maintain their own records there and other operators rely on them. A network that peers at well-known exchanges like DE-CIX in Frankfurt, AMS-IX in Amsterdam, or LINX in London is interconnecting where a lot of traffic already flows.
Then test the path yourself. A quick traceroute (or tracert on Windows) from your location to the provider's network shows you the hops your traffic takes and roughly how long each leg adds. Many providers also run a public looking glass, a web tool that lets you run pings and traceroutes from their PoPs back toward you, so you can measure latency from the other direction before you sign up.
Finally, think about redundancy and not just raw speed. Ask whether the provider has more than one PoP in the regions you care about, and whether they buy transit from multiple upstreams. Multihoming across providers is standard practice for anything you can't afford to have go dark.
Put those steps together and you get a clear picture: where the network lives, who it connects to, how fast it reaches you, and how well it holds up when something breaks.
A point of presence is a small idea with a big footprint. It's just the spot where networks meet, but those meeting points decide how close your infrastructure can get to your users, how many hops your traffic takes, and how gracefully things hold up when a link fails. Once you start noticing PoPs, you start seeing them behind almost every conversation about latency, transit, and reach.
If you're choosing where to put your infrastructure, having a provider with a well-connected PoP footprint makes a real difference. xTom offers enterprise-grade dedicated servers and colocation across global data centers, along with IP transit for networks that need direct, well-peered connectivity. For scalable compute, V.PS provides NVMe-powered KVM VPS hosting built for production workloads, and if you want to get started quickly there's shared hosting too. You can browse the full range of xTom services to see what fits.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
A data center is the physical building that supplies power, cooling, and security. A point of presence is a particular network's gear and connectivity inside that building. One data center can hold PoPs for many different networks at once, so the two terms describe different layers of the same setup.
More or less, yes. A CDN edge location is a point of presence where the CDN caches content close to users. The wider term PoP covers any network meeting point, while edge location is the CDN-specific flavor of the same idea.
A PoP close to your visitors shortens the physical distance their traffic has to travel and reduces the number of network hops along the way. Both of those cut latency, so pages and apps feel faster. A provider with PoPs near your audience, and good peering at those PoPs, will generally outperform one that routes everything through a distant hub.
Most providers publish a list of their locations on their site, and you can cross-check that against PeeringDB to see which facilities and internet exchanges they connect to. Running a traceroute to their network, or using their public looking glass, lets you measure the actual latency and routing from your own location before committing.
It depends on your reach and your tolerance for downtime. A single PoP can be plenty for a regional project on a budget, but if your users are spread across regions, or you can't afford outages, presence in multiple well-connected locations gives you both lower latency for distant users and a fallback path when something fails.
]]>Losing data on a Linux server is painful, and it's almost always preventable. This guide walks you through setting up automatic Linux backups using tools like rsync, cron, and tar, so your data is protected without you having to think about it.
]]>rm -rf, a failed drive — any of these can wipe out hours, days, or even months of work in seconds. The fix isn't complicated, though: a well-designed automatic backup strategy means that when something goes wrong (and eventually, something will), you're restoring from last night's backup rather than starting from scratch.
This guide covers how to set up automated Linux backups using tools that come standard on most distros. No paid software required, no vendor lock-in, just solid, time-tested methods you can set up in an afternoon.
The problem with manual backups is simple: people forget to do them. Or they do them inconsistently. Or they back up the wrong directories. Automation removes the human element from a task that really shouldn't depend on humans remembering to do it.
Beyond just running the backup, automation also lets you schedule backups during off-peak hours, rotate old backups to save disk space, and get notified if something fails. That's a lot harder to pull off reliably if you're doing it by hand.
Before jumping into scripts, it helps to know which tools you're working with and why they're suited for the job.
rsync is probably the most widely used backup tool on Linux. It copies files efficiently by only transferring what has changed since the last run, which makes incremental backups fast even over a network. It supports SSH out of the box, so you can back up to a remote server securely without any extra setup.
tar is the traditional Unix archiver. It bundles files and directories into a single archive (usually compressed with gzip or bzip2), which makes it easy to move backups around or store them as snapshots. Unlike rsync, tar creates a complete copy of everything in one file rather than a mirrored directory structure.
cron is the Linux job scheduler. It's what ties everything together by running your backup scripts on a schedule, whether that's nightly, hourly, or weekly.
Duplicati and BorgBackup are worth mentioning as well. Both are open-source tools that handle deduplication, encryption, and remote storage more elegantly than raw rsync or tar scripts. If you want a more feature-complete solution, either of these is worth exploring. But for this guide, we'll focus on the built-in tools since they work everywhere.
Here's a practical rsync command that backs up a directory to a remote server over SSH:
rsync -avz --delete /var/www/ user@backup-server:/backups/www/
Breaking that down: -a enables archive mode, which preserves permissions, timestamps, symlinks, and ownership. -v is verbose output so you can see what's happening. -z compresses data during transfer. --delete removes files on the destination that no longer exist on the source, keeping the backup in sync.
If you're backing up locally (for example, to a second drive mounted at /mnt/backup), just swap the destination:
rsync -av --delete /var/www/ /mnt/backup/www/
For remote backups, it's worth setting up SSH key authentication so the script can connect without prompting for a password. Without that, automated scripts will fail silently.
Rather than running rsync directly from cron, it's cleaner to write a shell script that handles the logic, logging, and any error handling you want.
Here's a starting point:
#!/bin/bash
# Configuration
SOURCE="/var/www /etc /home"
DEST="user@backup-server:/backups/$(hostname)"
LOG="/var/log/backup.log"
DATE=$(date +"%Y-%m-%d %H:%M:%S")
echo "[$DATE] Backup started" >> "$LOG"
for DIR in $SOURCE; do
rsync -az --delete "$DIR" "$DEST" >> "$LOG" 2>&1
if [ $? -ne 0 ]; then
echo "[$DATE] ERROR: Failed to back up $DIR" >> "$LOG"
fi
done
echo "[$DATE] Backup complete" >> "$LOG"
Save this as something like /usr/local/bin/backup.sh and make it executable:
chmod +x /usr/local/bin/backup.sh
Test it manually before adding it to cron:
/usr/local/bin/backup.sh
Check the log file afterward to make sure everything ran correctly.
Once your script is working, cron handles the scheduling.
Open the crontab editor as root:
crontab -e
To run the backup every night at 2 AM, add:
0 2 * * * /usr/local/bin/backup.sh
Cron syntax follows the format: minute, hour, day of month, month, day of week. The asterisk means "every" for that field. If you want to run it more frequently, say every six hours, you'd write:
0 */6 * * * /usr/local/bin/backup.sh
Crontab Guru is a handy tool for generating and verifying cron expressions if you're not confident in the syntax.
Running the same rsync command every night works, but you'll eventually end up with only one copy of your data, and it'll always reflect the most recent state. If a file gets corrupted or accidentally deleted and you don't notice for a few days, your backup will be corrupted too.
Backup rotation solves this by keeping multiple dated snapshots. Here's an approach using tar to create timestamped archives alongside your rsync backup:
#!/bin/bash
BACKUP_DIR="/mnt/backup"
SOURCE="/var/www"
DATE=$(date +"%Y-%m-%d")
ARCHIVE="$BACKUP_DIR/www-$DATE.tar.gz"
# Create a compressed archive
tar -czf "$ARCHIVE" "$SOURCE"
# Delete archives older than 30 days
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +30 -delete
The find command at the end handles cleanup automatically. You can adjust +30 to however many days of history you want to retain, keeping in mind the disk space implications.
File backups alone aren't enough if you're running a database. MySQL/MariaDB and PostgreSQL both need to be dumped properly to get a consistent, restorable backup.
For MySQL/MariaDB:
mysqldump -u root -p"$DB_PASSWORD" --all-databases | gzip > /backups/mysql-$(date +%F).sql.gz
For PostgreSQL:
pg_dumpall -U postgres | gzip > /backups/postgres-$(date +%F).sql.gz
These commands can be added to the same backup script and scheduled via cron alongside your file backups. Store the database password securely, ideally in a restricted file with chmod 600, rather than hardcoding it in the script.
Knowing a backup ran is as important as actually running it. You can configure cron to email you on failure by adding a MAILTO variable at the top of your crontab:
MAILTO=you@yourdomain.com
0 2 * * * /usr/local/bin/backup.sh
This only works if your server has a mail transfer agent configured (like Postfix). For a simpler approach, you can add a curl call inside your backup script to hit a webhook service like Healthchecks.io, which will alert you if a scheduled job stops checking in.
Keeping backups on the same server you're backing up isn't a real backup strategy; if the server fails, you lose both. At minimum, backups should go to a separate machine, a different location, or a cloud storage bucket.
rsync works great over SSH to a remote server. If you want to push to cloud storage, tools like rclone act as a bridge between your Linux server and services like AWS S3, Backblaze B2, or even SFTP destinations, using the same rsync-style syntax you're already familiar with.
A common pattern is the 3-2-1 rule: keep three copies of your data, on two different media types, with one copy offsite. It's a good target to work toward as your backup setup matures.
A backup that you've never restored from is just a backup you hope works. Schedule regular test restorations, even if it's just restoring a single file to verify the archive isn't corrupted. For tar archives:
tar -tzf /backups/www-2025-06-01.tar.gz | head -20
This lists the contents without extracting, letting you confirm the archive is intact. For a full test, restore to a temporary directory:
tar -xzf /backups/www-2025-06-01.tar.gz -C /tmp/restore-test/
Doing this even once a month will save you from the unpleasant surprise of discovering your backups were quietly failing for weeks.
Automated backups don't have to be complicated. With rsync, tar, and cron, you can have a working backup system in place within an hour, one that runs silently in the background and gives you real peace of mind. Start simple, test your restores, and add rotation and offsite storage as you go.
Whether you're running a small project or managing production infrastructure, xTom has the right solution to keep your workloads running reliably. We offer enterprise-grade dedicated servers, colocation services, IP transit, shared hosting, and a full range of IT services and solutions. For fast, scalable VPS hosting with NVMe storage, V.PS is a great fit for any workload, from dev environments to production deployments.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
There's no single answer, but rsync is a great default for most use cases because it's fast, handles incremental transfers well, and works over SSH without any additional software. For more advanced needs like deduplication and encryption, BorgBackup is worth considering.
It depends on how much data you can afford to lose. For production servers, nightly backups are a reasonable baseline; for databases or frequently changing files, hourly or even more frequent snapshots might make sense. The key is matching your backup frequency to your recovery point objective (RPO).
Yes, and it's a good idea. Using rsync over SSH, you can push backups from your VPS to any remote server you have SSH access to. Just set up SSH key authentication first so the process can run unattended.
At minimum, back up /home, /etc, /var/www (or wherever your web files live), and your database dumps. The /etc directory is especially important since it holds your system and application configuration. You generally don't need to back up /tmp, /proc, /sys, or /dev.
Check your log files after each run and, more importantly, do test restores regularly. Listing the contents of a tar archive or restoring a file to a temporary directory confirms the backup is intact and restorable, not just present on disk.
Use backup rotation: automatically delete archives older than a set number of days using a find command with -mtime. Combine this with rsync for live mirrors and tar for point-in-time snapshots, and you'll keep storage manageable while retaining meaningful history.
A content delivery network (CDN) is a globally distributed system of servers that delivers web content to users faster by serving it from a location close to them. This article explains what CDNs are, how they work under the hood, and when you actually need one.
]]>CDNs are one of those foundational pieces of internet infrastructure that most people interact with dozens of times a day without realizing it. If you've ever streamed a video, downloaded a software update, or loaded a news article quickly from the other side of the world, you've almost certainly been served by a CDN. Understanding how they work isn't just useful trivia; it's practical knowledge for anyone building or managing anything on the web.
A CDN is a geographically distributed network of servers that work together to deliver internet content, such as web pages, images, videos, JavaScript files, and stylesheets, to users more efficiently.
The core idea is simple: instead of every visitor fetching content from a single origin server (say, one located in Dallas), a CDN places copies of that content on servers spread across many locations worldwide. When someone in Tokyo requests your website, they get it from a server in Tokyo, not one in Dallas. That cuts down the physical distance the data has to travel, which directly reduces latency and improves load times.
Those distributed servers are called edge servers or Points of Presence (PoPs). The closer a PoP is to the end user, the faster the content arrives.
The main mechanism behind a CDN is caching. When a user requests a piece of content, the CDN checks whether it already has a cached copy on the nearest edge server. If it does, it serves that copy directly. If it doesn't, the edge server fetches the content from the origin server, caches it locally, and then delivers it to the user. Subsequent requests for the same content from nearby users get served from the cache, without touching the origin server at all.
This is controlled by cache headers, specifically Cache-Control and Expires headers sent by your origin server. These tell the CDN how long to hold onto a cached copy before refreshing it from the source.
CDNs use intelligent routing to direct users to the best available edge server. The two most common methods are:
Anycast routing assigns the same IP address to multiple servers in different locations. When a user makes a request, the network automatically routes them to the topologically closest server. This is how many large CDN and DNS providers operate.
DNS-based routing uses the CDN's own DNS resolver to return different IP addresses depending on where the user is located. When your browser looks up a domain, the CDN's DNS responds with the IP of the nearest PoP.
CDNs are excellent at serving static content, which includes anything that doesn't change between users: images, fonts, CSS files, JavaScript bundles, videos, and downloadable files. These can be cached indefinitely (or until you update them) and served at full speed from the edge.
Dynamic content is trickier. Personalized pages, API responses, and anything generated on the fly can't simply be cached and reused. Modern CDNs have evolved to handle this through techniques like edge computing, where lightweight logic runs directly on the CDN's edge servers to handle some dynamic requests without going all the way back to your origin.
One underappreciated benefit of a CDN is how much traffic it absorbs before it ever reaches your origin server. If your site gets a spike in traffic, or even a DDoS-style flood of requests, the CDN's edge layer takes the brunt of it. Your origin server only needs to handle cache misses and dynamic requests, not every single page view.
When a CDN sits in front of your site, it handles the TLS handshake at the edge. This means the encryption and decryption overhead happens close to the user, reducing connection setup time, especially for visitors far from your origin.
Most CDNs support modern protocols like HTTP/2 and HTTP/3 (QUIC), even if your origin server only speaks HTTP/1.1. This translates to multiplexed requests, header compression, and faster connection establishment for end users.
CDNs act as a shield between the public internet and your origin. Because they're built to handle enormous volumes of traffic across many servers, they can absorb and filter out distributed denial-of-service attacks more effectively than a single server ever could. This isn't their only purpose, but it's a significant operational benefit.
Many CDN providers bundle WAF capabilities, allowing you to filter malicious traffic, block known attack patterns, and enforce rate limits before requests reach your application.
Getting started with a CDN doesn't require deep infrastructure changes. Here's how the process generally works:
1. Choose a CDN provider. Major options include Cloudflare, Fastly, Amazon CloudFront, and Bunny.net, among others. Each has different pricing models, PoP coverage, and feature sets.
2. Point your DNS to the CDN. You'll update your domain's DNS records to route traffic through the CDN's network. With some providers this is as simple as changing your nameservers; with others you add a CNAME record pointing to the CDN's hostname.
3. Configure your cache rules. Tell the CDN what to cache, for how long, and what to pass through to your origin. Most providers have sensible defaults, but you'll want to tune these for your specific application, especially if you have a mix of static assets and dynamic pages.
4. Set cache-control headers on your origin. The CDN reads these to know how long cached content is valid. For static assets that rarely change, a long max-age (days or weeks) is fine. For HTML pages, a shorter TTL or conditional caching might make more sense.
5. Invalidate the cache when you deploy. When you push a new version of your site or update static files, you need to tell the CDN to clear its cached copies. Most providers offer instant cache purging via API or dashboard.
Not every project needs one on day one, but there are clear signals that it's time to consider adding a CDN to your stack.
You should think about a CDN if your users are geographically spread out and you're seeing latency complaints from certain regions. If your site serves a lot of large static assets, the bandwidth savings alone can justify the cost. If you're running a site that gets irregular traffic spikes (e-commerce launches, media coverage, etc.), the offload protection is genuinely valuable. And if uptime is a priority, a CDN adds a redundancy layer that helps absorb failures at the origin.
On the other hand, if you're running a small internal tool used by people in a single city, or a prototype not yet in production, a CDN is probably overkill at that stage.
A CDN doesn't replace a well-configured origin server; it complements one. How your underlying infrastructure is set up still matters a great deal. A slow, underpowered origin will still cause slowdowns on cache misses and for any dynamic content that bypasses the cache entirely.
This is where your hosting foundation comes in. Whether you're running a VPS, a dedicated server, or a colocated setup, the performance characteristics of your origin directly affect the user experience that your CDN delivers. A CDN can dramatically reduce how often users hit your origin, but when they do, you want that origin to be fast.
It's also worth noting how CDNs interact with IP transit. CDN providers maintain their own high-capacity network backbones and private peering agreements. When you use a CDN, your content often travels across private networks rather than the public internet, which contributes to the speed and reliability improvements users experience. Understanding IP transit can help you reason about why this matters if you're building infrastructure at scale.
Third-party CDN services are the default choice for most teams, and for good reason: they're quick to set up, managed for you, and backed by global infrastructure that took years and serious capital to build. But there's a subset of use cases where running your own CDN-like infrastructure makes sense, and it's worth understanding what that actually involves.
If you're running a large platform with significant, predictable traffic, the per-bandwidth costs of commercial CDN providers can add up fast. At scale, owning your delivery infrastructure can be more economical. Similarly, if you have strict data sovereignty requirements, specific compliance needs, or want full control over how your content is cached and routed, a self-hosted setup gives you options that a third-party provider might not.
Media companies, large SaaS platforms, game distribution networks, and telecommunications providers often operate their own CDN infrastructure for exactly these reasons.
Building a CDN-like system from scratch means assembling several components yourself. At a high level you need:
Geographically distributed servers. The whole point is edge proximity, so you need servers (or VMs) in multiple regions. This typically means either leasing space in data centers around the world or using a colocation provider with a footprint in your target regions.
A caching layer. Software like Varnish Cache or Nginx with its proxy caching module are the most common choices for handling caching at the edge. Both are well-documented and widely used in production.
A routing mechanism. You need a way to send users to their nearest edge node. Anycast routing (which requires BGP and your own IP address space) is the cleanest approach, but it has real operational complexity. A simpler alternative is GeoDNS, where your authoritative DNS server returns different records depending on the user's location. Services like PowerDNS support this natively.
An origin pull mechanism. Your edge nodes need to know how to fetch content from your origin when they don't have a cached copy, and how long to hold onto it.
Cache invalidation and management. When content changes, you need a way to purge cached copies across all your edge nodes. This is usually handled via an API call that triggers a purge across your fleet.
Monitoring and health checks. A CDN that silently fails at an edge node and routes users to a cold origin defeats the purpose. You need visibility into cache hit rates, node health, and latency across locations.
Running your own CDN isn't just a one-time setup task; it's ongoing infrastructure you're responsible for. That means patching, monitoring, capacity planning, and dealing with edge node failures. You also won't have the same global PoP coverage as a major commercial provider unless you're willing to invest significantly in server deployments across many regions.
For most teams, the answer is to use a commercial CDN and focus engineering effort elsewhere. But for the teams where cost, control, or compliance make self-hosting worth it, the tooling is mature and the path is well-trodden. Starting with a handful of strategically placed edge nodes in your highest-traffic regions, rather than trying to match a commercial provider's footprint from day one, is usually the pragmatic way to approach it.
Web hosting is where your actual website files and application logic live, typically on an origin server. A CDN is a separate layer that sits between your origin and your users, caching and delivering content from edge locations closer to them. Most sites use both; hosting provides the origin, the CDN accelerates delivery.
Yes, with some nuance. Static assets on a dynamic site (images, CSS, JS) are still cached and served efficiently by a CDN. Truly dynamic, user-specific content usually can't be cached, though modern CDNs offer edge computing features that can handle some dynamic logic at the edge without reaching the origin.
Indirectly, yes. Google uses page speed as a ranking signal, and CDNs can significantly reduce load times, particularly for users far from your origin server. Faster pages also reduce bounce rates, which matters for engagement metrics.
Most CDN providers are built for high availability across many redundant edge nodes. A failure at one PoP typically fails over to another automatically. However, if a provider has a major outage (it happens), traffic can fall back to your origin, which may become overwhelmed if it isn't sized to handle the full load. This is worth factoring into your architecture planning.
They overlap but aren't the same. A reverse proxy sits in front of your origin server and forwards requests to it, optionally caching responses. A CDN is essentially a globally distributed reverse proxy network. All CDNs act as reverse proxies, but not all reverse proxies are CDNs.
Yes, and some organizations do exactly that. The typical approach involves deploying caching servers (usually Nginx or Varnish) in multiple geographic locations, using GeoDNS or Anycast routing to direct users to the nearest node, and building a cache invalidation mechanism to push updates across the fleet. The tradeoff is operational overhead: you're taking on the responsibility of managing, patching, and monitoring that infrastructure yourself. It tends to make sense for large platforms with high, predictable traffic volumes where per-bandwidth CDN costs are significant, or where data sovereignty or compliance requirements make third-party providers a poor fit.
Cache invalidation is one of the genuinely tricky parts of CDN management. When you update content on your origin, cached copies on edge servers don't automatically refresh until their TTL expires. Most CDN providers offer cache purge APIs so you can manually invalidate specific URLs or entire directories immediately after deploying changes. For static assets, a common pattern is to append a version hash to filenames (e.g., app.a3f4bc2.js) so each new version is treated as a completely new file and the old one expires naturally.
CDNs are one of the most practical tools in modern web infrastructure. They reduce latency for users around the world, take load off your origin servers, improve resilience under traffic spikes, and add a useful security layer in front of your application. Understanding how they work, from edge caching to request routing to TLS termination, helps you configure them properly and make smarter decisions about your overall stack. And if you're at the scale where building your own CDN infrastructure starts to make sense, the same principles apply; you're just operating the edge nodes yourself.
If you're building out infrastructure to support a CDN-backed architecture, or exploring self-hosted edge caching with servers in multiple regions, xTom has you covered. xTom offers enterprise-grade dedicated servers, colocation services, and IP transit for teams that need serious network performance and control. For scalable, NVMe-powered VPS hosting, V.PS is built for production workloads of all sizes. If you need shared hosting to get started quickly, that's available too at vps.hosting. You can browse the full range of xTom services here.
Ready to discuss your infrastructure needs? Contact the xTom team to explore the right solution for your projects.
]]>Regional Internet Registries are the organizations responsible for allocating IP addresses and Autonomous System Numbers across the globe. Understanding how they work is useful for anyone managing infrastructure, requesting IP space, or thinking about internet routing.
]]>Whether you're a network engineer, a sysadmin spinning up infrastructure, or just someone curious about how IP addresses are handed out, understanding RIRs gives you a clearer picture of the internet as a system, not just a service you plug into.
The internet runs on addresses. Every device that communicates online needs a unique IP address, and someone has to be responsible for making sure those addresses are handed out in an orderly, non-overlapping way.
That responsibility ultimately sits with IANA, the Internet Assigned Numbers Authority, which is operated by ICANN. IANA manages the global pool of IP address space, but it doesn't deal directly with individual organizations or networks. Instead, it delegates large blocks of addresses to a tier of regional bodies: the Regional Internet Registries.
From there, RIRs distribute address space to Local Internet Registries (LIRs), such as ISPs and hosting providers, who then allocate it further to their customers or use it internally.
Think of it as a hierarchy: IANA at the top, RIRs in the middle, and LIRs and end users at the bottom.
There are five RIRs in total, each serving a specific part of the world.
ARIN (American Registry for Internet Numbers) covers the United States, Canada, and many parts of the Caribbean. It's one of the older registries and manages a large portion of the IPv4 space that was allocated during the early commercial internet era.
RIPE NCC serves Europe, the Middle East, and parts of Central Asia. RIPE is short for Réseaux IP Européens, and its NCC (Network Coordination Centre) is headquartered in Amsterdam. It's also one of the most active registries in terms of policy development.
APNIC covers the Asia-Pacific region, which includes a massive and fast-growing portion of the world's internet users. Given the size of that footprint, APNIC was actually the first RIR to exhaust its IPv4 free pool, back in 2011.
LACNIC handles Latin America and the Caribbean (the parts not covered by ARIN). It's headquartered in Montevideo, Uruguay.
AFRINIC manages IP resources for Africa. It's the newest of the five RIRs, having been founded in 2004, and it still holds some of the remaining IPv4 address space in the global pool, though allocations continue to tighten.
RIRs don't just hand out IPv4 and IPv6 addresses. They manage a few key internet resources:
IPv4 address blocks. These are the classic 32-bit addresses (like 192.0.2.0) that most people picture when they think of an IP address. The global free pool of IPv4 space is largely exhausted, which has pushed organizations to either transfer addresses, move to IPv6, or use both.
IPv6 address blocks. IPv6 uses 128-bit addresses, which gives an astronomically larger pool. RIRs actively encourage and facilitate IPv6 adoption, and getting IPv6 space is generally much more straightforward than fighting over legacy IPv4 blocks.
Autonomous System Numbers (ASNs). An ASN is a unique identifier assigned to a network that runs the Border Gateway Protocol (BGP). If you want to announce your own IP prefixes on the internet, you'll need an ASN. Networks with ASNs are called Autonomous Systems, and BGP is how they exchange routing information with each other. If you're interested in a deeper look at how that works, you'll want to read this article.
WHOIS and route registry data. RIRs maintain public databases where you can look up who holds a given IP range or ASN. This is useful for troubleshooting, abuse reporting, and verifying route origins. The RIPE Database and ARIN's WHOIS tool are commonly used examples.
The path from the global pool to your server rack follows a fairly consistent process.
IANA allocates large blocks, typically /8s or similar, to RIRs. The RIR then breaks those down and allocates smaller chunks to LIRs, which are usually ISPs or hosting providers who are members of the registry. Those LIRs can then either use the addresses themselves or sub-allocate them to their customers.
When a business or operator wants address space directly from an RIR, they typically need to justify their request with documentation showing current usage and projected need. The specific policies vary between registries, but most require that you demonstrate you have a plan for the address space rather than just sitting on it.
For most companies, the practical path is to work with a provider that's already an LIR and can either assign addresses from their own allocation or help sponsor a direct assignment from the RIR.
IPv4 exhaustion is one of the most significant practical consequences of how IP addressing has developed. With only about 4.3 billion possible IPv4 addresses, and the internet growing far beyond what its designers anticipated, regional free pools started running dry starting around 2011.
Today, most RIRs operate under what's called "final /8 policy" or similar restrictions, meaning they can only issue very small allocations from whatever remains. ARIN, for example, moved to its IPv4 Waiting List for new requests, where applicants wait for returned or revoked space to become available.
This scarcity has driven a secondary market for IPv4 transfers, where organizations that hold address blocks they no longer need can sell or transfer them to others, subject to each RIR's transfer policies. Prices for IPv4 space have risen significantly over the past decade as a result.
IPv6 is the long-term answer to this, and RIRs have made it progressively easier to get IPv6 allocations. The challenge has been adoption, since getting IPv6 space is one thing; getting every network, device, and application in the ecosystem to support it is another.
If you're at the point where you need your own address space or want to run your own ASN, here's a general picture of how that works.
Working through an LIR. For most organizations, the simplest path is working with an ISP or hosting provider that's already an LIR member of the relevant RIR. They can sponsor a PI (Provider Independent) assignment, which means the addresses are assigned to you and don't disappear if you change providers.
Becoming an LIR. Larger organizations, especially those managing multiple networks or operating at scale, sometimes apply to become LIRs themselves. This requires becoming a member of the relevant RIR, paying annual fees, and agreeing to their policies. In return, you get a direct allocation and more flexibility in how you distribute and use the space.
Getting an ASN. If you want to run BGP and announce your own prefixes, you'll need an ASN. Applications go through your regional RIR and typically require that you have at least two BGP peers and a legitimate reason to operate an Autonomous System. The process varies by registry but isn't particularly complicated for qualifying networks.
IP transfers. If you need IPv4 space quickly and can't wait, the transfer market is an option. RIRs have defined transfer policies that allow address blocks to move between organizations, sometimes within the same region, sometimes across regions. This usually involves a broker and can be expensive depending on the size of the block.
For companies running internet infrastructure, being an LIR or working closely with one has real operational implications. Provider Independent (PI) space means your addresses are yours regardless of which upstream provider carries your traffic. That matters a lot for multihoming, where you're connected to multiple transit providers for redundancy, and for portability if you change providers.
Having your own ASN also lets you participate directly in the routing ecosystem, giving you more control over how your traffic is routed and making it easier to implement things like BGP communities or traffic engineering policies.
For organizations with significant traffic or complex routing requirements, these aren't just technical details; they directly affect performance, resilience, and cost.
An RIR is a policy and administrative body that allocates internet resources like IP addresses and ASNs to networks within its region. An ISP is a commercial company that provides internet connectivity to customers. ISPs often become LIR members of an RIR so they can receive address allocations and assign them to their customers.
It's possible, but most small organizations work through an ISP or hosting provider instead. Getting space directly from an RIR typically requires becoming a member, paying fees, and meeting minimum size thresholds. For most use cases, working through a provider is simpler and more cost-effective.
A WHOIS lookup queries a registry's database to find out who is responsible for a given IP address or domain. RIRs maintain these databases for the IP space and ASNs they manage. They're commonly used for network troubleshooting and abuse reporting.
Yes, the free pool of unallocated IPv4 space at the global IANA level was exhausted in 2011. Regional pools have followed suit at different times since then. IPv4 addresses are still available through transfers on the secondary market, but they come at a cost. IPv6 adoption is the long-term path forward.
Provider Independent (PI) space is assigned directly to your organization, meaning it belongs to you regardless of which ISPs or providers carry your traffic. This is in contrast to Provider Aggregatable (PA) space, which comes from your ISP's allocation and would typically need to be returned if you change providers.
Each RIR develops its own policies through a community-driven process, so there are differences between them. However, they all operate within the broader framework set by IANA and ICANN, and they coordinate through a group called the Number Resource Organization (NRO).
An IP address block is a range of addresses used to identify devices on the internet. An ASN (Autonomous System Number) is a unique identifier for a network that uses BGP to exchange routing information. You need an ASN if you want to announce your own IP prefixes to other networks, but having IP addresses doesn't automatically mean you need an ASN.
Regional Internet Registries are an often-overlooked but foundational part of how the internet operates. They're the organizations that make sure IP address space and routing identifiers are distributed in a way that keeps the global network functioning, and understanding how they work is genuinely useful if you're managing any kind of infrastructure at scale.
Whether you're thinking about getting your own IP space, running BGP, or just want to understand how your provider's addresses are sourced, the RIR system is worth knowing.
At xTom, we operate as a registered LIR with allocations from multiple RIRs, which means we can offer IP transit with real network depth, alongside dedicated servers, colocation, and scalable NVMe KVM VPS through V.PS. We also offer shared hosting for simpler workloads, and you can see the full range of what we do at our services page.
Ready to talk infrastructure? Get in touch with our team and let's find the right setup for your network.
]]>GeoDNS lets you route users to the server closest to them based on their location, cutting latency and improving reliability. Here's how it works and when you should use it.
]]>This article breaks down what GeoDNS is, how it works under the hood, and when it makes sense to use it for your own infrastructure.
Before getting into GeoDNS specifically, it helps to understand what the Domain Name System (DNS) actually does. In short, DNS is the system that translates human-readable domain names like example.com into IP addresses that computers use to connect to each other. Every time you type a URL into your browser, a DNS query happens behind the scenes.
Standard DNS is essentially location-blind. When someone queries your domain, your DNS server returns the same IP address regardless of where that person is located in the world. That works fine when you have a single server or when your audience is geographically concentrated, but it starts to become a problem when you're serving users across continents.
Network latency, the time it takes for data to travel from point A to point B, is directly affected by physical distance. A server in Amsterdam can respond to a user in the Netherlands almost instantly, but that same server might add 150 to 200 milliseconds of latency for a user in Sydney. For some applications, that delay barely matters. For others, like real-time platforms, APIs, or latency-sensitive games, it's a meaningful degradation in experience.
This is the problem GeoDNS was built to solve.
GeoDNS, sometimes called geographic DNS or geo-routing DNS, is a method of returning different DNS responses based on the geographic location of the person making the query. Instead of giving everyone the same IP address, your DNS resolver checks where the query is coming from and returns the IP address of the server that's geographically closest, or most appropriate, to that user.
Here's a simplified version of the flow:
A user in Singapore queries api.example.com. The GeoDNS resolver identifies that the query originates from Southeast Asia and returns the IP of your Singapore-region server. A user in Dallas queries the same domain, and the resolver returns the IP of your North American server instead. Both users think they're connecting to api.example.com, but they're actually hitting different physical servers tailored to their location.
The geographic identification typically relies on IP geolocation databases, which map IP address ranges to approximate locations. These databases aren't perfect, especially for users on VPNs or certain mobile networks, but they're accurate enough for the vast majority of real-world traffic.
GeoDNS is often mentioned alongside IP Anycast, and they're frequently confused or treated as interchangeable. They're not quite the same thing, though they sometimes work toward similar goals.
With Anycast, multiple servers around the world share the same IP address. Routing is handled at the network layer by BGP, and traffic is naturally directed to the topologically nearest node. DNS doesn't need to do anything clever; the routing happens in the network fabric itself. Anycast is actually what many large DNS providers use to make their own DNS resolvers fast and resilient.
With GeoDNS, the routing decision happens at the DNS layer. Different IP addresses are returned based on the origin of the DNS query. The servers themselves can have completely different IPs; the intelligence lives in the DNS configuration.
In practice, you can use both together. Many CDN and DNS providers layer GeoDNS policies on top of Anycast infrastructure to get the benefits of both approaches.
GeoDNS isn't just for massive companies with data centers on every continent. There are several practical scenarios where even mid-sized deployments benefit from it.
Traffic distribution across multiple data centers. If you run servers in two or more regions, GeoDNS lets you direct users to the most appropriate region automatically, rather than relying on a single origin and hoping latency is acceptable everywhere.
Compliance and data sovereignty. Some regulations require that certain user data stay within specific geographic boundaries. GeoDNS can help ensure that users from the EU, for example, always hit your EU-hosted infrastructure rather than being routed elsewhere.
Failover and disaster recovery. GeoDNS can be configured with health checks so that if your primary server in a region goes down, traffic fails over to a backup location automatically. This pairs well with a solid redundant hosting setup where you have standby capacity ready.
Content localization. If you're serving region-specific content, different languages, pricing, or product catalogs, GeoDNS gives you a clean way to route users to the server or application stack configured for their market.
Reducing bandwidth costs. Routing users to a geographically closer server often means fewer hops through expensive transit networks, which can reduce your bandwidth bills over time, especially at scale.
The specifics depend on which DNS provider or authoritative nameserver software you're using, but the general approach follows the same pattern.
Not every DNS host supports geographic routing out of the box. You'll need a provider or authoritative DNS server that supports geo-based record sets. Two popular options are AWS Route 53 and Cloudflare, but plenty of alternatives exist. If you're running your own nameserver infrastructure, software like PowerDNS supports geo-routing through its GeoIP backend.
GeoDNS only helps if you actually have infrastructure in the regions you want to serve. This might mean setting up dedicated servers or VPS instances in each target region, or it could mean leaning on an existing multi-region setup.
Once your provider supports it, you'll create multiple A (or AAAA for IPv6) records for the same hostname, each mapped to a different IP, and each associated with a geographic region. The exact interface varies by provider, but conceptually you're saying "return this IP for users in Europe, this one for Asia, and this one for North America."
Always configure a default record for users that don't match any specific region. This could be your largest server, your most central location, or simply your primary origin. Without a default, queries from unrecognized locations may fail entirely.
Use tools like DNSChecker.org or command-line tools like dig with specific DNS resolvers to verify your records are resolving correctly from different regions. Some providers also offer built-in health check and monitoring features you should enable to catch routing issues early.
Once you're live, pay attention to your traffic distribution. You may find certain regions are misclassified due to IP geolocation inaccuracies, or that your TTL (time to live) values need adjusting to balance DNS caching with failover speed. A shorter TTL, say 30 to 60 seconds, allows faster failover but increases the number of DNS queries hitting your nameservers.
GeoDNS isn't a silver bullet. A few things worth keeping in mind:
IP geolocation isn't perfect. VPN users, corporate proxies, and some ISPs can cause users to be routed to an unexpected region. In most cases this is a minor inconvenience, but it's worth factoring in if geographic precision is a compliance requirement rather than just a performance optimization.
DNS caching can delay routing changes. Resolvers and clients cache DNS responses for the duration of the TTL, so changes to your GeoDNS records don't take effect instantaneously everywhere. Plan for this during maintenance or failover events.
It adds DNS infrastructure complexity. More moving parts mean more things to monitor and maintain. Make sure your team has visibility into whether geo-routing is working as expected, not just whether your servers are up.
A Content Delivery Network (CDN) and GeoDNS both help reduce latency, but they work at different layers. A CDN caches and serves content from edge nodes distributed globally, handling the actual HTTP traffic. GeoDNS operates at the DNS layer and determines which IP address a user's browser connects to. They're complementary; many CDN setups use GeoDNS internally to direct users to the nearest CDN edge node.
Yes. GeoDNS works with AAAA records for IPv6 just as it does with A records for IPv4. If your infrastructure is dual-stack, you can configure geo-routing for both record types independently.
Absolutely, and this is one of its most practical uses. When combined with health checks, GeoDNS can automatically remove an unhealthy server from the rotation and route traffic to a healthy one in another region. The speed of failover depends on your TTL settings and how quickly your DNS provider detects the failure.
This is a balance. Lower TTLs like 30 to 60 seconds allow faster failover and quicker propagation of routing changes, but they mean more DNS queries hitting your nameservers. Higher TTLs reduce DNS query volume but slow down your ability to react to outages. For latency-sensitive or high-availability setups, a TTL of 60 seconds is a common starting point.
Not exactly. Traditional load balancing distributes traffic across multiple servers, often within the same data center or region, for redundancy and capacity reasons. GeoDNS is more about directing users to the right region first. That said, you can combine both: GeoDNS routes a user to the correct regional cluster, and then a load balancer within that cluster distributes requests across individual servers.
IP geolocation databases are generally accurate at the country or broad regional level, but less reliable for city-level precision. For most GeoDNS use cases, country or continent-level routing is sufficient. If you need finer-grained control or have compliance requirements that demand precise geographic enforcement, you may need to supplement with other methods or accept that a small percentage of users will be misclassified.
GeoDNS is a relatively straightforward concept once you understand how DNS and IP routing work, but its impact on latency, availability, and user experience can be significant. If you're running infrastructure in more than one region, or planning to expand to new markets, it's worth adding to your toolkit.
At xTom, we provide the infrastructure that makes multi-region setups like these practical to deploy and manage. Whether you need dedicated servers in specific locations, colocation for your own hardware, IP transit for your network, or flexible NVMe-powered VPS hosting through V.PS, we have options designed for teams that take performance seriously. We also offer shared hosting for lighter workloads, along with a full range of IT services to support your stack.
Ready to discuss your infrastructure needs? Contact our team to find the right solution for your setup.
]]>Git is the standard version control system for developers and sysadmins alike, and getting it running on Linux takes just a few minutes. This guide walks you through installation, basic configuration, and the everyday commands you'll actually use.
]]>Whether you're a developer pushing code to GitHub, a sysadmin versioning your server configs, or someone just getting started with Linux, learning Git is one of those things that pays off pretty quickly.
This guide will cover how to install Git on the most common Linux distributions, how to configure it for the first time, and how to use it day-to-day. No prior experience required.
Git is a distributed version control system originally created by Linus Torvalds in 2005 to manage the Linux kernel's source code. Instead of saving a single file that gets overwritten, Git keeps a full history of every change ever made to your project, who made it, and when.
What makes Git "distributed" is that every person working on a project has a complete copy of the entire history on their own machine. There's no single point of failure, and you can work offline just fine.
You might also hear Git mentioned alongside platforms like GitHub, GitLab, or Bitbucket. Those are hosting services built on top of Git, not Git itself. Git is the tool; those platforms are where you store and share your repositories remotely.
Git is available in the default package repositories of virtually every major Linux distribution, so installation is straightforward.
sudo apt update
sudo apt install git
sudo dnf install git
sudo pacman -S git
Once it's installed, verify it worked:
git --version
You should see something like git version 2.43.0. The exact version will vary depending on your distribution.
Before you start using Git, you need to tell it who you are. Git attaches your name and email address to every commit you make, so this matters even if you're only working locally.
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
You can also set your preferred text editor. By default, Git often falls back to Vim, which can be a surprise if you're not expecting it. If you'd rather use Nano:
git config --global core.editor nano
To check your current configuration at any time:
git config --list
These settings are stored in ~/.gitconfig in your home directory.
Before jumping into commands, it helps to understand a few key terms.
A repository (or "repo") is just a directory that Git is tracking. It contains your project files plus a hidden .git folder that stores all the version history.
A commit is a saved snapshot of your project at a specific point in time. Each commit has a unique ID, a message describing what changed, and metadata about who made it.
A branch is an independent line of development. You can create branches to work on features or fixes without touching the main codebase, then merge them back when ready.
The staging area (also called the index) is a middle step between your working files and a commit. You explicitly add files to the staging area before committing, which gives you fine-grained control over what goes into each snapshot.
To start tracking a project with Git, navigate to the project directory and run:
git init
This creates a .git folder and turns the directory into a Git repository. Nothing is committed yet; you've just initialized it.
If you want to download a copy of an existing project, use git clone:
git clone https://github.com/username/repository.git
This creates a new directory with the project name, downloads all the files, and pulls in the full commit history.
One of the most used commands you'll run is:
git status
It tells you which files have been modified, which are staged for the next commit, and which are untracked. Run it often, it's your sanity check.
Once you've made some changes, you need to stage them before committing. To stage a specific file:
git add filename.txt
To stage everything that's changed:
git add .
Then commit with a message:
git commit -m "Add initial configuration file"
Write commit messages that are brief but descriptive. Future you (and anyone else reading the history) will thank you.
To see a log of all commits:
git log
For a more compact view:
git log --oneline
This shows each commit on a single line with its short ID and message, which is a lot easier to scan through.
To create a new branch:
git branch feature-login
To switch to it:
git checkout feature-login
Or, combine both steps into one:
git checkout -b feature-login
When you're done with the feature and want to merge it back into your main branch:
git checkout main
git merge feature-login
To see all branches:
git branch
If you're working with a remote repository (say, on GitHub or a self-hosted GitLab instance), you'll need to push your local commits up and pull down changes from others.
First, add a remote if you haven't already:
git remote add origin https://github.com/username/repository.git
Push your commits:
git push origin main
Pull down changes:
git pull origin main
Git gives you several ways to backtrack.
To unstage a file you accidentally staged:
git restore --staged filename.txt
To discard uncommitted changes to a file and restore it to the last committed state:
git restore filename.txt
To undo the last commit but keep your changes staged:
git reset --soft HEAD~1
To undo the last commit and discard the changes entirely (use with care):
git reset --hard HEAD~1
Not everything in your project directory should be tracked. Log files, compiled binaries, environment files with secrets, and editor-specific folders are all things you'll typically want Git to ignore.
Create a .gitignore file in the root of your repository and list patterns for files and folders to exclude:
*.log
node_modules/
.env
__pycache__/
Git will then skip those files when staging and committing. GitHub maintains a collection of useful .gitignore templates for common languages and frameworks.
If you're frequently pushing to GitHub or GitLab, typing your password every time gets old fast. SSH key authentication solves this.
Generate a key pair if you don't already have one:
ssh-keygen -t ed25519 -C "you@example.com"
Then print your public key:
cat ~/.ssh/id_ed25519.pub
Copy the output and add it to your GitHub or GitLab account under Settings > SSH Keys. After that, use the SSH URL when cloning:
git clone git@github.com:username/repository.git
For a broader look at SSH and how it works on Linux, check out xTom's SSH guide.
Git itself doesn't require an internet connection or a third-party platform. You can use it entirely locally, or push to a server you control. If you want full ownership of your code and history, self-hosting GitLab is a solid option and it's more approachable to set up than you might expect.
Git is the version control software that runs on your local machine. GitHub is a cloud platform where you can host Git repositories online, collaborate with others, and manage projects. You can use Git without GitHub entirely, and there are several alternatives like GitLab and Gitea if you'd rather self-host.
Not necessarily, but in practice you'll almost always end up using it. Most projects you'll deploy via Docker are distributed as Git repositories, and versioning your configuration files with Git is widely considered a best practice for server management.
Absolutely, and it's a great habit. Tracking files like your Nginx configs, Docker Compose files, or /etc settings in a Git repo means you always have a history of what changed and can roll back if something breaks.
git pull and git fetch?git fetch downloads changes from the remote but doesn't apply them to your working branch. git pull does both; it fetches and then merges. Using git fetch first lets you review what's coming before integrating it.
To delete a local branch: git branch -d branch-name. To delete the remote branch as well: git push origin --delete branch-name.
No. Once something is committed to a Git repository and pushed to a remote, it's very difficult to fully remove. Never commit passwords, API keys, private keys, or other secrets. Use a .gitignore to exclude sensitive files and consider tools like git-secrets to catch accidental leaks.
Git is one of those tools that's worth investing time in early. Once the basic workflow clicks, version control starts to feel natural, and going back to working without it is genuinely uncomfortable.
Whether you're managing a single project or collaborating across a whole team, Git gives you a reliable record of your work and the freedom to experiment without fear.
Thanks for reading! If you're looking for reliable infrastructure to host your projects, xTom provides enterprise-grade dedicated servers and colocation services, along with IP transit and shared hosting options. V.PS offers scalable, production-ready NVMe-powered VPS hosting that's a great fit for anything from a personal Git server to a full GitLab instance. You can browse all available services here.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
]]>IP address blocks are the backbone of how networks are organized and routed across the internet, but the differences between IPv4 and IPv6 allocations can be confusing. This guide breaks down block sizes, CIDR notation, and what it all means in practice.
]]>This article covers how block sizes work in both IPv4 and IPv6, what CIDR notation means, and how the two protocols compare when it comes to address space and allocation.
Before getting into blocks, it helps to quickly recap what an IP address actually is.
An IPv4 address is a 32-bit number, typically written in dotted decimal notation like 192.168.1.1. That 32-bit structure gives IPv4 a theoretical maximum of about 4.3 billion addresses, which sounds like a lot until you consider that essentially every device on earth needs one.
An IPv6 address is a 128-bit number, written in hexadecimal groups like 2001:db8::1. The address space is so large it's almost hard to conceptualize, roughly 340 undecillion addresses (that's 3.4 × 10³⁸). For practical purposes, it's inexhaustible.
Both IPv4 and IPv6 use CIDR (Classless Inter-Domain Routing) notation to describe blocks of addresses. You'll see it written as an IP address followed by a slash and a number, like 10.0.0.0/8 or 2001:db8::/32.
The number after the slash is called the prefix length. It tells you how many bits are fixed (the network portion), with the remaining bits available for hosts or sub-allocation.
So in 192.168.1.0/24:
Smaller prefix numbers mean larger blocks. A /8 is vastly larger than a /24. This trips people up at first because it feels backward, but think of it this way: the prefix length is the number of bits that are locked in, so fewer locked bits means more room for addresses.
IPv4's 32-bit address space means blocks range from a single /32 (one address) all the way up to /0 (the entire internet). Here's a practical reference for common block sizes:
| CIDR | Total addresses | Common use |
|---|---|---|
| /32 | 1 | Single host, loopback |
| /31 | 2 | Point-to-point links |
| /30 | 4 | Small point-to-point (2 usable) |
| /29 | 8 | Small subnet (6 usable) |
| /28 | 16 | Small LAN (14 usable) |
| /27 | 32 | 30 usable hosts |
| /26 | 64 | 62 usable hosts |
| /25 | 128 | Half a /24 |
| /24 | 256 | Standard "class C" equivalent |
| /23 | 512 | Two /24s combined |
| /22 | 1,024 | Common ISP allocation |
| /21 | 2,048 | Larger ISP block |
| /20 | 4,096 | Regional allocation minimum |
| /19 | 8,192 | — |
| /18 | 16,384 | — |
| /17 | 32,768 | Half a /16 |
| /16 | 65,536 | "Class B" equivalent |
| /8 | 16,777,216 | "Class A" equivalent |
The /24 is by far the most common unit you'll encounter in practice. It's the smallest block that most internet exchange points and transit providers will accept as a BGP announcement, which is why it's become the de facto standard building block of IPv4 routing.
When an organization announces IP space to the internet via BGP, they're telling every router in the world "I have these addresses, route traffic here." The global BGP routing table currently has hundreds of thousands of prefixes, and to keep it manageable, most networks filter announcements more specific than a /24. If you announce a /25 or smaller, there's a good chance many networks won't accept it and your addresses will be unreachable from parts of the internet.
This is why even small hosting providers that only need a few dozen IPs will typically receive or purchase at least a /24.
The IANA exhausted its free IPv4 pool back in 2011, and regional registries like ARIN, RIPE NCC, and APNIC have since run out of most of their general-pool allocations as well. Today, organizations that need IPv4 space typically get it one of two ways: leasing it from a provider, or purchasing it on the transfer market, where a /24 (256 addresses) can go for several thousand dollars depending on the registry region and market conditions.
IPv6 uses the same CIDR notation, but the numbers have a very different feel because the address space is so much larger. The smallest allocation a typical end-user organization would receive is a /48, which contains 2⁸⁰ addresses. That's more addresses than exist in the entire IPv4 internet, given to a single organization.
Here's how the hierarchy typically works in IPv6:
| CIDR | Size description | Typical use |
|---|---|---|
| /128 | Single address | One interface/host |
| /127 | 2 addresses | Point-to-point links |
| /64 | 18.4 quintillion addresses | Standard subnet (one LAN) |
| /56 | 256 × /64 subnets | Some ISPs give to home users |
| /48 | 65,536 × /64 subnets | Standard end-site allocation |
| /32 | 65,536 × /48 blocks | Minimum ISP allocation |
| /29 | 8 × /32 blocks | Larger ISP/LIR allocation |
| /23 and larger | Regional allocations | RIR assignments to ISPs |
In IPv6, the /64 plays a similar role to the /24 in IPv4, but at the subnet level rather than the routing level. The IETF strongly recommends using /64 for all point-to-multipoint links (which covers virtually every normal LAN). This is because some IPv6 features, particularly SLAAC (Stateless Address Autoconfiguration), only work correctly on /64 subnets. With SLAAC, devices can automatically configure their own IPv6 address from the prefix without needing a DHCP server.
This might seem wasteful since a /64 contains 18.4 quintillion addresses, but given the overall size of IPv6, it's not a concern.
If you're running servers or infrastructure, here's roughly what you'd expect to receive:
From a VPS or cloud provider: Usually a single /128 per server, sometimes a /64 if you ask or pay for it.
From a colocation or dedicated server provider: Typically a /64 or /48 per customer, depending on their policies and your stated needs.
From an ISP or transit provider (for your own AS): At minimum a /48, and in many regions you can justify a /32 or larger by documenting your planned usage.
For home internet: Most ISPs that support IPv6 assign either a /64 or a /56 to the customer's router. A /56 allows you to create 256 separate /64 subnets at home, which is useful if you want separate network segments for different VLANs or IoT devices.
It helps to put the two protocols side by side when thinking about relative sizes:
| IPv4 | IPv6 equivalent (approx.) | Notes |
|---|---|---|
| /32 (single host) | /128 | Both are single addresses |
| /24 (256 addrs) | /120 | Rarely used in IPv6 |
| /24 | /48 (end-site) | Conceptually similar as "org allocation" |
| /20 | /32 (ISP minimum) | Conceptually similar as "provider block" |
| Entire IPv4 internet | /8 in IPv6 | IPv6 dwarfs all of IPv4 many times over |
One key takeaway: in IPv6, address space is not scarce, so the conventions around allocation are more generous and the hierarchy is more structured. Rather than squeezing subnets down to /30s and /29s to conserve space, the standard practice is to use /64 everywhere and hand out /48s freely to end sites.
Subnetting is the practice of dividing a larger block into smaller ones. The math works the same way in both IPv4 and IPv6.
Each bit you add to the prefix length cuts the block in half. So a /24 split into /25s gives you two equal halves. A /24 split into /26s gives you four quarters. And so on.
For example, the block 192.168.1.0/24 can be split like this:
192.168.1.0/25 (addresses .0 through .127)192.168.1.128/25 (addresses .128 through .255)Or into four /26s:
192.168.1.0/26192.168.1.64/26192.168.1.128/26192.168.1.192/26In IPv6, the same principle applies. A /48 allocated to your organization is typically divided into /64 subnets for individual network segments. Since a /48 contains 65,536 possible /64 subnets, you'll likely never run out.
Tools like IP Calculator / IP Subnetting are handy for working out subnet math quickly without doing it by hand.
Not all IP blocks are routable on the public internet. Both protocols have reserved ranges for private use.
IPv4 private ranges (RFC 1918):
10.0.0.0/8172.16.0.0/12192.168.0.0/16These are used heavily in home networks, corporate LANs, and data center environments. Traffic from these ranges doesn't route across the public internet; it stays within the local network or is translated via NAT.
IPv6 private equivalent (ULA, RFC 4193):
fc00::/7 (commonly fd00::/8 for locally assigned ULA space)ULA (Unique Local Addresses) serve a similar purpose to RFC 1918 in IPv4. They're not routable on the public internet but are stable and unique enough for internal use without the risk of collisions that comes with using 10.x.x.x everywhere.
There's also fe80::/10, which is the link-local range in IPv6. Every IPv6-enabled interface automatically assigns itself a link-local address, used for neighbor discovery and other on-link communication. These addresses are never routed beyond the local link.
For a deeper look at how IPv4 and IPv6 differ beyond just addressing, the xTom guide on IPv4 vs. IPv6 covers the protocol differences in more detail.
If you're planning to run your own Autonomous System (AS) and announce your own IP space, minimum prefix sizes matter a lot.
For IPv4, the general internet consensus is:
/24 is the smallest prefix most networks will accept/25, /26, etc.) may be filtered by many providersFor IPv6, the commonly accepted minimum is a /48 for end-site announcements, though many networks also accept /32 and shorter prefixes from ISPs and transit providers.
If you need IP transit to carry your announcements, the prefix you announce needs to fall within these accepted norms or your traffic simply won't reach parts of the internet. This is worth verifying with your upstream provider before purchasing or leasing address space.
For more on how IP transit works, read our article What Is IP Transit and How Does It Work.
Understanding IP block sizes isn't just academic. It affects how you plan subnets, whether your BGP announcements will be accepted, how much address space you need to request, and how efficiently you can organize a network. IPv4's scarcity has made block sizing a careful exercise in conservation, while IPv6's abundance shifts the focus toward clean, hierarchical design.
Whether you're managing a single server or building out an infrastructure with dozens of nodes, knowing the difference between a /24 and a /48 will save you confusion down the road.
xTom offers dedicated servers, colocation, and IP transit for organizations that need reliable, well-connected infrastructure. V.PS provides NVMe-powered scalable KVM VPS hosting if you're looking for a flexible place to run your workloads. For smaller-scale needs, shared hosting is also available. You can browse all available services at here.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
A /24 is an IPv4 block containing 256 addresses, and it's the standard minimum allocation for routing on the public internet. A /48 is an IPv6 block containing 65,536 possible /64 subnets, and it's the standard minimum allocation for an end-site organization in IPv6. They serve conceptually similar roles in their respective protocols, but the scale is completely different.
The number after the slash is the prefix length. It tells you how many bits of the address are fixed as the network identifier. The remaining bits are available for hosts or sub-allocation. A longer prefix (higher number) means a smaller block; a shorter prefix (lower number) means a larger block.
Most networks filter BGP announcements more specific than a /24 to keep routing tables manageable. A /25 is "more specific" than a /24, meaning it's a smaller block carved out of a larger one. Many internet routers will simply drop the announcement, making your addresses unreachable from those networks. If you need to route a block publicly, make sure it's at least a /24.
A /24 contains 256 total addresses. In IPv4, two are reserved: the network address (the first) and the broadcast address (the last). That leaves 254 usable host addresses. In IPv6, the concept of broadcast doesn't exist, so technically all addresses in a /64 subnet are usable, though /128 is used for individual host assignments.
For a single server or interface, you'd receive a /128. For a subnet, the standard is a /64. An end-site organization (like a business or a home customer) typically gets a /48 or /56 from their ISP, though this varies by provider. For your own BGP-routable block, you'd typically need at least a /48.
The /64 boundary in IPv6 is largely defined by SLAAC (Stateless Address Autoconfiguration), which allows devices to automatically generate their own addresses using the network's prefix plus a host identifier derived from the interface's MAC address. SLAAC requires exactly a /64 prefix to work correctly. Because SLAAC is a widely used and important feature, the IETF standardized /64 as the normal subnet size for IPv6, even though the address space would technically allow for much smaller subnets.
In IPv4, a /32 is a single host address. In IPv6, a /32 is a massive block containing 65,536 /48 sub-allocations, and it's considered the minimum allocation for an ISP or large organization. The same notation means very different things depending on which protocol you're working with.
Linux desktop market share is climbing fast, with fresh data from StatCounter, the Steam Hardware Survey, and Stack Overflow painting a clearer picture than ever. Here's what the numbers say halfway through 2026.
]]>Let’s break down what the latest data actually shows.
Before getting into the stats, a quick note: Linux isn’t technically a full operating system. It’s a kernel, the core layer that manages hardware and system resources. What most people call “Linux” is actually a Linux distribution (or distro), like Ubuntu, Fedora, or Arch Linux, which bundles the kernel with a desktop environment, package manager, and user-facing tools.
That distinction matters when looking at market share. The numbers below represent all Linux-based desktop systems combined, not any single distro.
No single source has a definitive read on Linux market share. The three most commonly cited are StatCounter, Valve's monthly Steam Hardware Survey, and the annual Stack Overflow Developer Survey. Each collects data differently, which is why the numbers vary so much between them.
Each measures a different audience:
None is a complete picture, but together they show clear directional trends.
According to StatCounter’s March 2026 desktop OS data, Linux holds 3.16% of the global desktop market.
For context:
The inclusion of a large “Unknown” category is important—it suggests actual Linux share may be slightly undercounted depending on detection methods.
Even with that caveat, Linux has steadily climbed from sub-3% levels just a few years ago, continuing a slow but consistent upward trend.
This is where things get genuinely interesting.
The March 2026 Steam Hardware Survey puts Linux at 5.33% of Steam users—the highest ever recorded.
This marks the first time Linux has crossed the 5% threshold in Steam’s data.
Within Linux:
However, its relative share is shrinking. Two years ago, Steam Deck users made up roughly 42% of Linux gamers on Steam. By March 2026, that dropped to ~24%, indicating that organic desktop Linux gaming adoption is growing beyond just handheld users.
There was some sampling noise in February due to regional effects (like Chinese New Year), but the broader upward trend predates that.
The 2025 Stack Overflow survey gives a much deeper look at how developers actually use operating systems.
Personal use:
Professional use:
Notably, Android slightly surpassed Ubuntu for personal use (29% vs 28%), but Ubuntu remains the dominant Linux-based desktop OS in both personal and professional environments.
Across Linux environments:
The key takeaway: Linux usage among developers is far higher than general consumer stats suggest, especially when including WSL.
The Steam data is outpacing general desktop adoption for a reason.
Compatibility used to be Linux’s biggest weakness. That’s changed dramatically with Proton.
That gap has effectively closed for most users.
On top of that, Valve’s continued investment in SteamOS and potential future hardware (like rumored living-room systems) could push adoption even further.
Linux desktop share has grown steadily over the past few years, with global estimates ranging from ~3% (strict web tracking) to ~4–5% (broader modeling including developers and enthusiasts).
Some regional highlights:
On servers, Linux is dominant. For example, according to W3Techs, 61.1% of websites with identifiable OS run on Linux (with more being identified as Unix).
If you’re considering Linux, the distro you pick matters more than people expect:
Most distributions can be tested via a live USB without installing anything.
Yes. Growth has been steady, with gaming adoption accelerating faster than general desktop usage.
Ubuntu leads in developer surveys and general usage. SteamOS is significant in gaming but declining as a percentage of Linux users.
Stability, flexibility, and zero licensing costs make it ideal for infrastructure. Desktop adoption has historically lagged due to software compatibility, though that gap is closing.
Not natively, but tools like Wine and Proton make many applications and games usable on Linux.
Most distributions are free and open source. Enterprise versions (like Red Hat) offer paid support.
Linux has gone from a niche choice for developers and server admins to a legitimately competitive desktop and gaming platform, and the data backs that up. Whether you're tracking it for curiosity or making infrastructure decisions based on it, the trajectory is clear.
If you're running Linux in production, or thinking about it, xTom provides enterprise-grade dedicated servers and colocation services built for serious workloads. V.PS offers scalable, NVMe-powered KVM VPS hosting that pairs well with any Linux stack. xTom also offers IP transit, shared hosting, and a full range of IT services to keep your infrastructure running.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
]]>Grep is one of the most useful command-line tools in Linux, letting you search through files and output for exactly the text you're looking for. This guide covers what it does, how it works, and the most practical ways to use it.
]]>grep mentioned somewhere, whether in a tutorial, a Stack Overflow answer, or piped at the end of some command you copy-pasted. It's one of those tools that shows up everywhere, and for good reason.
At its core, grep does one thing: it searches for text. But the way it does that, and how flexible it is, is what makes it so indispensable for anyone working on the command line.
grep stands for Global Regular Expression Print. It was originally written by Ken Thompson in 1974 as part of Unix, and it's been a staple of Unix-like systems ever since.
The basic idea is simple: you give grep a pattern and a file (or some input), and it prints every line that matches. That's it. But when you combine it with regular expressions, pipes, and various flags, it becomes something you'll reach for constantly.
The general structure of a grep command looks like this:
grep [options] pattern [file...]
So a simple, real-world example would be:
grep "error" /var/log/syslog
This searches the file /var/log/syslog and prints every line that contains the word "error." Case-sensitive by default, so "Error" or "ERROR" wouldn't match unless you tell it otherwise.
The most common use for grep is searching inside one or more files. Say you have a config file and you want to find a specific setting:
grep "listen" /etc/nginx/nginx.conf
You can also search across multiple files at once:
grep "listen" /etc/nginx/*.conf
Or search an entire directory recursively with -r:
grep -r "listen" /etc/nginx/
The -r flag is especially useful when you're digging through a project directory or a folder full of config files and you're not sure which file contains what you're looking for.
There are a lot of flags available for grep, but here are the ones that come up most often.
-i — case-insensitive search
grep -i "error" /var/log/syslog
This matches "error", "Error", "ERROR", and anything in between.
-n — show line numbers
grep -n "error" /var/log/syslog
Prints the line number alongside each match, which is handy when you need to jump to a specific line in an editor.
-c — count matches
grep -c "error" /var/log/syslog
Instead of printing the matching lines, this just tells you how many lines matched. Useful for a quick sanity check.
-v — invert the match
grep -v "error" /var/log/syslog
This prints every line that does not match. Great for filtering out noise.
-l — list matching files
grep -rl "listen" /etc/nginx/
With -l, grep just prints the names of files that contain a match rather than the lines themselves. Useful when you're searching many files and just want to know which ones are relevant.
-A, -B, -C — show context
Sometimes you don't just want the matching line, you want to see what's around it.
-A 3 shows 3 lines after the match-B 3 shows 3 lines before the match-C 3 shows 3 lines before and after (context)grep -C 3 "error" /var/log/syslog
-w — match whole words only
grep -w "fail" /var/log/auth.log
Without -w, searching for "fail" would also match "failure" or "failed." This flag restricts it to exact whole-word matches.
--color — highlight matches
grep --color "error" /var/log/syslog
Many distros enable this by default through an alias, but if yours doesn't, it highlights the matching text in color, which makes scanning output much easier.
One of the most practical ways to use grep is alongside other commands. Because Linux tools are built to pass output to each other, you can filter the output of almost anything with grep.
For example, if you want to see which processes are running that involve nginx:
ps aux | grep nginx
Or check if a specific package is installed on a Debian-based system:
dpkg -l | grep "nginx"
You can read more about how to list installed packages in Linux if you want to dig deeper into that.
Or search your command history for something specific:
history | grep "docker"
Piping grep into other grep commands is also valid if you want to narrow things down further:
cat /var/log/syslog | grep "error" | grep -v "trivial"
grep supports regular expressions (regex), which is where things get interesting. You don't need to be a regex expert to get value out of this, but knowing a few basics helps.
. — match any single character
grep "err.r" file.txt
Matches "error", "errxr", "err5r", etc.
^ — match start of line
grep "^error" file.txt
Only matches lines that start with "error."
$ — match end of line
grep "error$" file.txt
Only matches lines that end with "error."
.* — match anything
grep "error.*failed" file.txt
Matches any line containing "error" followed by anything and then "failed."
For more advanced patterns, you can use grep -E (or egrep) to enable extended regular expressions, which adds support for things like +, ?, |, and grouping with ().
grep -E "error|warning|critical" /var/log/syslog
This matches lines containing any of those three words, which is a quick way to scan logs for anything worth investigating.
You might come across egrep and fgrep as well, especially in older scripts or documentation.
egrep is equivalent to grep -E, enabling extended regular expressions. fgrep is equivalent to grep -F, which treats the pattern as a fixed string rather than a regex. This makes fgrep faster when you're searching for a literal string with no special characters, since there's no regex engine involved.
In modern Linux systems, both egrep and fgrep are technically deprecated in favor of grep -E and grep -F, but they still work and you'll still see them used.
If you're working with compressed log files, like the .gz archives that log rotation creates, regular grep won't work directly on them. That's where zgrep comes in. It works just like grep but handles gzip-compressed files transparently:
zgrep "error" /var/log/syslog.2.gz
It's a small thing, but it saves you from having to decompress files just to search them.
One common real-world scenario is troubleshooting failed login attempts on a Linux server. The auth log keeps track of all authentication events, and grep makes it easy to filter for what you care about.
grep "Failed password" /var/log/auth.log
You could also combine it with -c to get a count:
grep -c "Failed password" /var/log/auth.log
Or check for a specific IP address:
grep "Failed password" /var/log/auth.log | grep "192.168.1.100"
If you want to go further with protecting your server from brute force attempts, it's worth reading about securing SSH on a Linux server and setting up Fail2Ban.
Grep stands for Global Regular Expression Print. The name comes from a command in the ed text editor (g/re/p), which performed a similar "find and print" operation across a file.
Yes. By default, grep treats searches as case-sensitive. To make a search case-insensitive, use the -i flag.
grep searches for text within files. find searches for files themselves based on name, type, size, modification date, and similar attributes. They serve different purposes, though you can combine them, for example, using find to locate files and piping them into grep to search their contents.
Yes. You can pass multiple file paths to grep, use wildcards like *.log, or use the -r flag to search recursively through an entire directory.
grep -E enables extended regular expressions, which adds support for additional metacharacters like +, ?, |, and grouping. It's the modern equivalent of the older egrep command.
When grep encounters a binary file (like a compiled program or image), it doesn't print the matching lines and instead just notes that a match was found. If you want to force it to treat binary files as text, you can use the -a flag.
Strings that start with - can confuse grep because it might interpret them as flags. To work around this, use -- before the pattern to signal the end of options:
grep -- "-option" file.txt
For anyone working with Linux, whether you're a developer, a sysadmin, or just someone who self-hosts a few services, grep is a command worth knowing well. It's one of those tools that starts simple and reveals more usefulness the more you use it.
Thanks for reading! If you're looking for reliable infrastructure to run your Linux workloads, xTom offers enterprise-grade dedicated servers, colocation, IP transit, shared hosting, and a full range of IT services. For scalable, NVMe-powered VPS hosting, V.PS has you covered for any workload.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
]]>RDAP has taken over as the modern way to look up registration data for domains, IP ranges, and autonomous system numbers. xTom’s open source Rust client wraps that protocol in a fast CLI with readable output, smart query detection, and flexible JSON support. Learn more about it in this article.
]]>whois and thought, “this works, but it really feels like it belongs to another era,” RDAP is the answer.
RDAP, short for Registration Data Access Protocol, is the structured successor to WHOIS. It gives users a standard way to query registration data for domains, IP addresses, CIDR ranges, autonomous system numbers, nameservers, and entities, while also supporting machine-readable JSON, better HTTP semantics, and more predictable responses. ICANN has also moved generic TLD registration lookups over to RDAP, with WHOIS sunset for gTLDs on January 28, 2025.
That shift matters for sysadmins, network operators, security teams, and developers. It also explains why a good RDAP client is worth having on hand.
And that's exactly why we created our open source xtomcom/rdap project. It's a Rust-based RDAP client built for the command line, and it’s meant to make those lookups faster, cleaner, and easier to work with than the old habits many Linux users still rely on.
WHOIS was always a bit messy. Output formats varied, registries handled responses differently, and parsing the results for scripts often turned into a mess of brittle text processing.
RDAP improves that by using HTTP and JSON, along with a standard model for responses. It also supports bootstrap-based service discovery, which means a client can figure out the authoritative RDAP service for a given domain, IP block, or ASN instead of relying on a pile of hardcoded guesses. That bootstrap model is part of the RDAP standards and is tied to IANA’s published registries.
In practice, that means RDAP is better suited to both terminal use and automation.
A good RDAP client should help with a few things:
That’s exactly where this Rust client fits in.
The xtomcom/rdap project is a fork of Akaere-NetWorks/rdap, extended with more features and bug fixes. It’s written in Rust and can be used both as a CLI tool and as a library in Rust projects.
At a high level, it supports:
That already makes it more flexible than the way many people still use whois, which often means jumping between different services or manually changing syntax depending on what they want to inspect.
What stands out here is that the tool isn’t only about returning raw data. It also tries to make RDAP pleasant to use from a terminal. The default text output is colorized and formatted for readability, while JSON and pretty JSON output are there when you want to pipe results into another tool or service.
Rust is a good fit for networking utilities that need to be fast, efficient, and dependable.
This project uses asynchronous I/O with Tokio, efficient HTTP handling, and Serde for JSON parsing. That matters because RDAP is an HTTP-based protocol, and even simple lookups can involve redirects, referrals, bootstrap discovery, cache reads, and multiple remote queries.
For a CLI tool, the result is straightforward: fast startup, low overhead, and a small binary that’s easy to ship around.
For developers, the library side is just as useful. You can query RDAP programmatically, detect object types automatically, serialize responses to JSON, and build services on top of it without writing your own RDAP stack from scratch.
A lot of RDAP clients can fetch data. Fewer of them make the experience smooth.
This project adds a handful of practical features that matter in real use.
You can pass a value like a domain, IP, CIDR block, or AS number, and the client will detect the query type automatically. That makes the CLI feel natural:
rdap example.com
rdap 8.8.8.8
rdap 8.8.8.0/24
rdap AS15169
For day-to-day use, that’s exactly how most people want a lookup tool to behave.
One of the more useful additions is multi-layer RDAP querying for domains.
For domain names, registry-level data and registrar-level data can differ in presentation and detail. This client can follow registrar referrals, so you can inspect both layers rather than stopping at the first answer. That’s handy when you want a fuller picture of status codes, registrar details, nameservers, abuse contacts, and redacted registrant information.
RDAP discovery is better than the old WHOIS approach, but real-world naming infrastructure still has edge cases. The tool includes configurable TLD overrides for ccTLDs that may not behave exactly how users expect through the normal bootstrap flow.
It also supports a local configuration model with updateable downloaded files and persistent local override files. In other words, you can update the general config without wiping your own custom settings.
That is a small feature, but a very practical one.
For IP and ASN work, showing abuse contacts quickly is genuinely useful.
If you’re investigating suspicious traffic, checking ownership of an IP block, or trying to find the right point of contact for a network issue, having abuse details surfaced directly in the output saves time.
Some tools lean too hard in one direction. They’re either nice for humans and annoying for automation, or good for JSON workflows and miserable to read in a terminal.
This one handles both use cases well. You can use the default text mode when you’re working interactively, then switch to:
rdap -f json example.com
rdap -f json-pretty example.com
That makes it a decent fit for shell pipelines, dashboards, web services, and internal tooling.
The project supports a few different installation paths.
You can build it from source with Cargo:
git clone https://github.com/xtomcom/rdap.git
cd rdap
cargo build --release
sudo cp target/release/rdap /usr/local/bin/
There are also package options for Debian and Ubuntu, RPM-based distributions, and macOS through Homebrew. That matters because network tools are most useful when they’re easy to install on the systems where people already work.
For Linux admins, packaging support is always a plus. It means you can get the tool onto a workstation, jump box, or admin VM without treating it like a one-off experiment.
Debian (via extrepo):
sudo apt update && sudo apt install extrepo -y
sudo extrepo enable xtom
sudo apt update && sudo apt install rdap -y
One-Line Style:
sudo apt install -y lsb-release ca-certificates apt-transport-https curl gnupg dpkg
# Add xTom repository
curl -fsSL https://repo.xtom.com/xtom.key | bash -c 'gpg --dearmor > /usr/share/keyrings/xtom.gpg'
echo "deb [signed-by=/usr/share/keyrings/xtom.gpg] https://repo.xtom.com/deb stable main" | sudo tee /etc/apt/sources.list.d/xtom.list
sudo apt update
sudo apt install rdap
DEB822:
sudo apt install -y lsb-release ca-certificates apt-transport-https curl gnupg dpkg
curl -fsSL https://repo.xtom.com/xtom.key | bash -c 'gpg --dearmor > /usr/share/keyrings/xtom.gpg'
sudo bash -c 'cat > /etc/apt/sources.list.d/xtom.sources << EOF
Components: main
Architectures: $(dpkg --print-architecture)
Suites: stable
Types: deb
Uris: https://repo.xtom.com/deb
Signed-By: /usr/share/keyrings/xtom.gpg
EOF'
sudo apt update
sudo apt install rdap -y
# Add xTom repository
sudo curl -o /etc/yum.repos.d/xtom.repo https://repo.xtom.com/rpm/xtom.repo
sudo dnf install rdap
# Install Homebrew https://brew.sh/
brew tap xtomcom/brew
brew install xtomcom/brew/rdap
The nice thing about this client is that the basic usage is simple.
A domain lookup:
rdap example.com
An IP lookup:
rdap 192.0.2.1
A CIDR lookup:
rdap 8.8.8.0/24
An ASN lookup:
rdap AS8888
Verbose output:
rdap -v AS8888
And if you need to force a query type or server, you can:
rdap -t domain example.com
rdap -s https://rdap.verisign.com/com/v1 example.com
That mix of convenience and explicit control is what makes a CLI tool stick.
This isn’t just a neat GitHub project for protocol enthusiasts. There are real day-to-day use cases for it.
If you’re a sysadmin, it helps when you need to inspect domain registration data, IP ownership, or ASN details without relying on random web lookup sites.
If you work in abuse handling or incident response, it gives you a quicker path to network details and abuse contacts.
If you’re a developer, the Rust library means you can build RDAP lookups into your own services, customer tooling, dashboards, or automation scripts.
And if you work in hosting or network operations, it’s the kind of utility that ends up in your standard toolbox because you keep finding reasons to use it.
The CLI is only half the story.
Because the project is also a Rust library, you can add it directly to Cargo.toml and query RDAP from your own applications. That opens up a lot of possibilities:
The examples in the repository show how to create a client, auto-detect query types, work with domain and IP models, and serialize responses. There’s even an integration example using Axum for a simple web service.
That makes the project useful beyond the terminal. It can be the base layer for higher-level tooling.
The configuration system is one of the smarter parts of the project.
It uses a layered priority model, with local user overrides above downloaded configs, system-wide configs, and finally built-in defaults. That means you can have a usable zero-config experience out of the box, while still being able to customize behavior when needed.
The rdap --update command updates config files from GitHub and refreshes the IANA TLD list, while keeping *.local.json files intact. That split is a good design choice because it avoids the usual problem where an update stomps on local changes.
For people managing odd TLD edge cases or internal lookup workflows, that flexibility matters more than it might seem at first glance.
A lot of admins still default to whois because it’s familiar.
That isn’t irrational, but the internet’s registration data ecosystem has moved on. RDAP is now the standard path for structured registration data, especially for gTLDs, and its use of JSON, HTTP, referrals, and standardized responses makes it a better long-term fit for both human use and automation.
Compared with older habits, this client gives you:
That’s a meaningful upgrade.
This tool makes the most sense for:
sysadmins who want a better replacement for scattered whois usage, network engineers who need fast ASN and IP ownership lookups, developers building network-aware tooling in Rust, and security teams that need readable registration and abuse contact data.
It’s also a nice fit for anyone who wants a small open source CLI tool that feels modern instead of patched together.
RDAP is no longer the “next” protocol for registration lookups, it’s the current one. With WHOIS sunset for gTLD registration data and the broader move toward structured, machine-readable responses, having a good RDAP client is becoming less of a nice extra and more of a practical necessity.
The xtomcom/rdap project is a solid example of what that client should look like. It’s fast, readable, scriptable, flexible enough for real-world use, and useful both as a CLI and as a Rust library.
For teams running their own infrastructure, that kind of utility fits naturally alongside reliable dedicated servers, colocation, NVMe-powered scalable KVM VPS through V.PS, IP transit, shared hosting, and other IT services. xTom would love to help!
Ready to discuss your infrastructure needs? Contact the team to explore the right solution for your projects.
RDAP stands for Registration Data Access Protocol. It is the standards-based successor to WHOIS for looking up registration data related to domain names, IP addresses, autonomous system numbers, and related internet resources. RDAP uses HTTP and structured responses, usually JSON, instead of the loose text formatting common in WHOIS.
For generic top-level domains, yes. ICANN announced the WHOIS sunset for gTLD registration data on January 28, 2025, making RDAP the definitive protocol in that area.
It supports domain queries, TLD queries, IP address lookups, CIDR ranges, AS numbers, entity lookups, nameserver queries, and search queries based on the project documentation you provided.
Yes. The project works as both a command-line tool and a Rust library. It supports JSON output for scripting and includes examples for integrating it into Rust applications and web services.
A local RDAP client is faster to work with, easier to automate, and better suited to shell workflows, incident response, and internal tooling. It also lets you control output format, timeouts, referrals, and server selection directly from the command line.
Yes. It supports compact JSON and pretty-printed JSON, which makes it useful for scripts, APIs, dashboards, and data processing workflows.
The biggest strengths are the Rust implementation, auto-detection of query types, readable terminal output, multi-layer domain lookups, abuse contact display, configurable overrides, and the ability to use it as a reusable library instead of only as a CLI.
]]>GRE tunnels encapsulate one packet inside another so traffic can move between remote systems or networks over an IP path. In this article, we'll explain more about them.
]]>That simple concept makes GRE useful in several real-world scenarios. It can connect remote private networks, carry routing traffic between servers or routers, and forward traffic from a DDoS-protected edge network to backend infrastructure hosted somewhere else. GRE has been around for a long time, but it still matters because it solves a specific problem cleanly.
GRE stands for Generic Routing Encapsulation. It is a tunneling protocol defined in RFC 2784. GRE creates a virtual point-to-point link between two endpoints by encapsulating an original packet inside a new outer IP packet.
The intermediate network only needs to route the outer packet to the far end of the tunnel. Once it arrives, the receiving endpoint removes the outer packet and forwards the original traffic normally.
In simple terms, GRE makes two remote systems or networks behave more like they are directly connected, even when the real path between them crosses the public internet or another unrelated IP network.
A GRE tunnel has two endpoints. One endpoint encapsulates the original traffic, and the other decapsulates it.
At the sending side, the original packet is wrapped with a GRE header and a new outer IP header. The outer source and destination addresses belong to the real tunnel endpoints. The original packet stays intact inside the new packet.
At the receiving side, the outer IP header and GRE header are removed, and the original packet is forwarded on to its destination.
A simple way to picture it looks like this:
Original packet: [Inner IP header][Payload]
GRE tunnel packet: [Outer IP header][GRE header][Inner IP header][Payload]
That extra encapsulation is what allows traffic to move across networks that otherwise would not carry it in the same way.
GRE remains widely used because it is flexible and relatively simple. It is not trying to be a security suite or an application delivery platform. Its main role is moving traffic between two endpoints in a useful way.
One of the most common GRE tunnel use cases is connecting one private subnet to another over an IP network. This can be useful when infrastructure is spread across two data centers, two providers, or two geographic regions.
Instead of redesigning the whole network, a GRE tunnel can create a virtual link between the two sides. Once routes are added, the remote networks can communicate as though there is a more direct path between them.
GRE is also useful for carrying routed traffic between remote systems. It can make remote endpoints act more like directly connected peers, which is one reason it appears so often in routing-heavy environments.
For more background on related topics, see xTom’s guides on what BGP is and how it works and what IP transit is and how it works.
GRE tunnels are also used in some hosting and DDoS mitigation setups.
In this type of design, traffic first reaches a DDoS-protected provider or protected network edge. After filtering or scrubbing, that traffic is forwarded through a GRE tunnel to a backend server or backend subnet hosted elsewhere, sometimes at a provider without the same level of DDoS protection.
This lets the backend infrastructure benefit from the protected edge without requiring the full application stack to be moved there. It is a common approach when the origin server is already deployed somewhere else, when infrastructure is split across providers, or when a business wants to keep compute and storage in one location while using another network for protected ingress.
That said, GRE does not automatically hide or secure the backend. If the origin is still publicly reachable, attackers may be able to bypass the protected edge entirely. Proper firewall rules, routing policy, and origin lockdown are what make this setup effective.
GRE tunnels are often confused with VPNs, but they are not the same thing.
GRE is an encapsulation protocol. It wraps traffic and transports it between two endpoints. By itself, it does not provide encryption, authentication, or confidentiality.
VPN technologies such as IPsec are designed to secure traffic. That is why GRE is often paired with IPsec in real deployments. GRE handles the flexible tunnel and routing behavior, while IPsec adds encryption and authentication.
This distinction matters because a tunnel does not automatically mean privacy. A plain GRE tunnel should be treated as transport, not security.
GRE is one of several tunneling methods available.
IP-in-IP is simpler, but generally less flexible. IPsec focuses on secure transport. WireGuard is a more modern choice for encrypted point-to-point networking. VXLAN is more common in virtualized and data center overlay environments.
GRE still makes sense when the main goal is routing flexibility, packet encapsulation, or forwarding traffic between remote systems without needing GRE itself to provide encryption.
GRE remains useful because it offers a few practical advantages.
It is relatively easy to understand once the basic concept clicks. It is flexible enough for a variety of Layer 3 networking scenarios. It is also widely supported across Linux, routers, and network appliances.
On Linux, GRE tunnels can be configured with standard tools such as iproute2, which makes them approachable for many sysadmins and network operators.
GRE also comes with tradeoffs.
The biggest limitation is that GRE does not encrypt traffic on its own. For anything sensitive crossing an untrusted network, GRE usually needs to be paired with something secure.
There is also packet overhead. Because GRE adds extra headers, the effective MTU drops. If that is not accounted for, fragmentation and inconsistent traffic behavior can show up.
GRE also depends on correct routing and firewall configuration. A tunnel may look correct in configuration, but still fail if the endpoints are not reachable, if intermediate devices block GRE, or if the right routes are not in place.
One common mistake is assuming GRE uses a normal TCP or UDP port. It does not. GRE is IP protocol 47, which is handled differently by firewalls and security policies.
The exact setup depends on the Linux distribution and the network management stack in use, but the basic workflow is usually the same.
Assume this example:
203.0.113.10198.51.100.2010.10.10.1/3010.10.10.2/30On Server A:
ip tunnel add gre1 mode gre local 203.0.113.10 remote 198.51.100.20 ttl 255
ip addr add 10.10.10.1/30 dev gre1
ip link set gre1 up
On Server B:
ip tunnel add gre1 mode gre local 198.51.100.20 remote 203.0.113.10 ttl 255
ip addr add 10.10.10.2/30 dev gre1
ip link set gre1 up
Then routes are added so traffic for each remote subnet goes through the tunnel.
For example, if Server A needs to reach 10.20.0.0/24 behind Server B:
ip route add 10.20.0.0/24 via 10.10.10.2 dev gre1
And if Server B needs to reach 10.30.0.0/24 behind Server A:
ip route add 10.30.0.0/24 via 10.10.10.1 dev gre1
At that point, traffic for those remote subnets is sent through the GRE interface instead of the normal path.
For related Linux setup and troubleshooting, these xTom guides may also help: how to diagnose network issues using ping, traceroute, and MTR and how to set up UFW on Debian.
A GRE tunnel only works if the network path between endpoints supports it.
The public IP addresses of both tunnel endpoints must be reachable. Any firewall or filtering layer in front of them must allow GRE traffic. Routes on both sides must point the correct remote networks into the tunnel.
In protected edge to backend designs, the backend often needs to be restricted so that only the protected edge or approved sources can reach it. Otherwise, the backend may still be directly exposed even though GRE forwarding is in place.
Packet size is one of the most common GRE tunnel issues.
Because GRE adds encapsulation overhead, the usable MTU becomes smaller. If MTU is not adjusted, traffic may fragment or fail unpredictably, especially under real application load.
That is why many GRE deployments lower the MTU on the tunnel interface. The exact value depends on the rest of the network path and whether GRE is combined with additional encapsulation or encryption.
GRE tunnels are sometimes mentioned alongside proxying, especially in protected edge and backend origin setups, but GRE is not the same thing as a reverse proxy.
A reverse proxy works at the application layer, usually handling HTTP or HTTPS requests. GRE works at the network layer and tunnels packets themselves.
So while GRE can forward traffic from a protected edge network to backend servers, it is not terminating and reissuing web requests the way an application-layer reverse proxy would.
For readers looking at application-layer traffic handling, xTom also has a guide on setting up NGINX as a reverse proxy for Apache on Debian and Ubuntu.
GRE is a good fit when a deployment needs a simple virtual link between two endpoints, site-to-site routing between remote networks, or traffic forwarding from a protected network edge to backend infrastructure hosted elsewhere.
It is less suitable when the main requirement is encrypted transport with minimal additional configuration. In those cases, technologies such as IPsec or WireGuard may be a better fit.
GRE is still relevant because it handles a specific networking job well, especially in routing-focused and hosting-focused environments.
GRE tunnels are a straightforward way to move traffic between remote endpoints by encapsulating one packet inside another. That makes them useful for site-to-site networking, routed links between remote systems, and protected edge-to-origin forwarding when a DDoS-protected provider is sitting in front of backend infrastructure hosted elsewhere.
The key thing to remember is that GRE is about transport and flexibility, not encryption. When security matters, GRE should be paired with the right tools, and the rest of the deployment, including routing, MTU, firewall rules, and origin protection, needs to be planned carefully.
Thanks for reading! If infrastructure is needed for routing, tunneling, hosting, or broader network deployments, xTom offers dedicated servers, colocation, IP transit, shared hosting, and general IT services. For scalable NVMe-powered KVM VPS hosting, V.PS is available for production workloads, testing environments, and edge deployments.
Ready to discuss infrastructure needs? Contact the team to explore the right solution for any project.
A GRE tunnel is used to encapsulate traffic and move it between remote endpoints over an IP network. Common use cases include site-to-site connectivity, routed links between servers or routers, and forwarding traffic from a protected network edge to backend infrastructure.
No. GRE tunnels do not provide encryption on their own. If confidentiality and secure transport are needed, GRE is often paired with IPsec or replaced with another secure tunneling option.
Yes. GRE tunnels are sometimes used to send traffic from a DDoS-protected provider or protected edge network to backend servers hosted at another provider. This can help keep the backend behind a filtered ingress path, as long as the origin is properly locked down.
GRE does not use a TCP or UDP port. It uses IP protocol 47, which means firewall rules need to specifically allow GRE traffic.
Yes. Linux supports GRE tunneling through built-in networking features and standard tools such as iproute2, which makes GRE practical for many server and infrastructure setups.
GRE is mainly for encapsulation and routing flexibility. IPsec is mainly for security. In many deployments, GRE and IPsec are used together so GRE handles the tunnel behavior and IPsec secures the traffic.
Yes. GRE adds overhead to packets, which reduces the effective MTU. If MTU is not adjusted properly, fragmentation or unreliable connectivity can occur.
Yes. GRE tunnels are still used in routing-heavy environments, site-to-site network designs, and protected edge-to-origin hosting setups where straightforward packet encapsulation is needed.
]]>RAID can improve uptime, performance, and fault tolerance, but it doesn't magically make data safe from every kind of loss. Here's what RAID actually does, how each RAID level works, and where ZFS, software RAID, and hardware RAID fit in.
]]>RAID can help keep a system online when a drive fails, and in some setups it can also improve storage performance. What it can't do is protect you from every kind of data loss. If files are deleted, corrupted, encrypted by ransomware, or overwritten by mistake, RAID usually won't save you. That's why it's important to understand what RAID is actually for, what each RAID level does, and how it compares to things like ZFS, software RAID, hardware RAID, and backups.
In this guide, we'll break down RAID in plain English, compare the main RAID levels, explain when each one makes sense, and cover where ZFS fits into the conversation.
RAID stands for Redundant Array of Independent Disks. The idea is simple: instead of treating each drive as a separate device, RAID combines multiple drives into one logical storage unit.
Depending on the RAID level, the array may spread data across drives for speed, duplicate data for redundancy, or store parity information so the array can survive one or more failed disks.
That means RAID is usually built around one or both of these goals:
Performance, by splitting reads and writes across multiple drives
Fault tolerance, by keeping enough duplicate or parity information to recover from a failed drive
Different RAID levels make different tradeoffs. Some focus almost entirely on speed. Others focus more on redundancy. Some do a bit of both, but with more complexity.
RAID protects data by reducing the chance that a single drive failure takes down the entire system.
For example, if you use a mirrored setup and one disk dies, the other disk still has the same data. If you use a parity-based RAID setup, the array can rebuild the missing data from the remaining drives and parity information.
This matters for servers, virtualization hosts, databases, and storage systems where uptime matters. A failed drive doesn't have to mean immediate downtime or emergency recovery from scratch.
Still, this protection has limits.
RAID does not replace backups. It doesn't protect against accidental deletion, file corruption, malware, controller failure in some setups, fire, theft, or a bad command run by a human. If bad data gets written to the array, RAID usually protects that bad write just as faithfully as it would a good one.
So the better way to think about RAID is this: RAID helps with drive failure and availability. Backups help with actual disaster recovery.
This is the most important distinction in the whole article.
RAID is about keeping storage available when hardware fails. Backups are about restoring data after something goes wrong.
If a drive dies in a RAID 1 mirror, the server can keep running. Great. But if someone deletes a client folder and that deletion syncs instantly across the array, RAID has done exactly what it was supposed to do, and your files are still gone.
A real data protection strategy usually includes both:
RAID for uptime and drive failure tolerance
Backups for recovery from deletion, corruption, ransomware, and larger disasters
That combination is much safer than relying on either one alone.
RAID works through a few core techniques: striping, mirroring, and parity.
Striping means splitting data across multiple disks. This can improve performance because multiple drives can read or write parts of the same workload at the same time.
Mirroring means storing identical copies of data on more than one disk. This gives you redundancy, but reduces usable capacity because the same data is written multiple times.
Parity means storing calculated data that can be used to reconstruct missing information if a disk fails. This is more space-efficient than full mirroring, but it adds complexity and can slow down writes.
Every RAID level is basically a different combination of these ideas.
Not every RAID level is common in modern deployments, but it's still useful to understand the full landscape.
RAID 0 uses striping only. Data is split across two or more drives, which can improve read and write performance.
The catch is that RAID 0 has no redundancy at all. If one drive fails, the entire array is lost because parts of the data were stored across all disks.
RAID 0 gives you the full combined capacity of all drives. Two 2 TB drives in RAID 0 give you 4 TB usable. That's attractive for speed and space, but it's risky.
RAID 0 is best for temporary data, scratch space, or workloads where performance matters more than fault tolerance. It is not a good choice for important data.
RAID 1 uses mirroring. Every write is copied to at least two drives.
This means if one drive fails, the other drive still contains the full dataset. RAID 1 is simple, reliable, and easy to understand. It doesn't give you the same capacity efficiency as parity-based RAID, but it is a common choice for operating system volumes, boot drives, and smaller servers.
The tradeoff is usable space. Two 2 TB drives in RAID 1 give you only 2 TB usable, because one drive is effectively the mirror of the other.
RAID 1 is a good fit when simplicity and redundancy matter more than raw capacity.
RAID 2 is largely historical and almost never used in modern systems. It used bit-level striping and special error correction methods across multiple disks.
You usually won't see RAID 2 offered in real-world server deployments today.
RAID 3 uses byte-level striping with a dedicated parity disk. It can tolerate a single drive failure, but the dedicated parity disk becomes a bottleneck, especially for writes.
Like RAID 2, RAID 3 is mostly of historical interest now.
RAID 4 uses block-level striping with a dedicated parity disk. It improved on some of the limitations of RAID 3, but it still suffers from that dedicated parity bottleneck.
Modern systems generally prefer RAID 5 or RAID 6 instead.
RAID 5 uses block-level striping with distributed parity. Instead of storing parity on one dedicated disk, parity data is spread across all drives in the array.
This avoids the single parity-disk bottleneck found in RAID 4 and allows the array to survive one disk failure.
RAID 5 needs at least three drives. Usable capacity is roughly the total capacity minus one drive's worth. For example, four 2 TB drives in RAID 5 give you about 6 TB usable.
RAID 5 became very popular because it offers a decent balance of performance, redundancy, and space efficiency. But it has real downsides on larger arrays and bigger disks. Rebuilds can take a long time, and during that period the array is vulnerable. If a second drive fails before rebuild finishes, the array is gone.
For modern large-capacity disks, many admins are much more cautious about RAID 5 than they used to be.
RAID 6 is similar to RAID 5, but it stores double distributed parity instead of single parity. That means the array can survive two drive failures instead of one.
It requires at least four drives, and usable capacity is roughly total capacity minus two drives' worth. Four 2 TB drives in RAID 6 give you about 4 TB usable.
RAID 6 is often preferred over RAID 5 for larger arrays because the added protection is worth the extra capacity cost. The tradeoff is slower writes and less usable storage.
If you're working with big SATA drives and want parity-based redundancy, RAID 6 is often the safer choice.
RAID 10, sometimes written as RAID 1+0, combines mirroring and striping. It stripes data across mirrored pairs of drives.
This gives you strong read and write performance, along with better redundancy than RAID 0 and usually faster rebuild behavior than parity-based RAID. It requires at least four drives.
With four 2 TB drives in RAID 10, you get about 4 TB usable. Like RAID 1, half of the raw capacity is used for redundancy.
RAID 10 is widely used for virtualization hosts, databases, and production systems where performance and resilience both matter. The main downside is capacity efficiency. You give up more usable space than with RAID 5 or RAID 6.
RAID 50 combines multiple RAID 5 groups with striping across them. It can improve performance and fault tolerance compared to a single RAID 5 set, but it's more complex and usually found in larger enterprise storage setups.
It still inherits RAID 5's parity and rebuild concerns, just in a more layered design.
RAID 60 combines multiple RAID 6 groups with striping across them. Like RAID 50, it is generally used in larger storage environments where you want more scale and more fault tolerance.
This can survive multiple drive failures depending on where the failures occur, but complexity and overhead both increase.
| RAID level | Minimum drives | Fault tolerance | Performance | Usable capacity |
|---|---|---|---|---|
| RAID 0 | 2 | None | High | 100% |
| RAID 1 | 2 | 1 drive per mirror | Good reads, decent writes | 50% |
| RAID 2 | Varies | Historical | Historical | Rarely used |
| RAID 3 | 3 | 1 drive | Good sequential, limited by parity disk | Total minus 1 disk |
| RAID 4 | 3 | 1 drive | Better than RAID 3 in some cases, still parity bottleneck | Total minus 1 disk |
| RAID 5 | 3 | 1 drive | Good reads, slower writes | Total minus 1 disk |
| RAID 6 | 4 | 2 drives | Good reads, slower writes than RAID 5 | Total minus 2 disks |
| RAID 10 | 4 | Depends on which drives fail | Very good | 50% |
| RAID 50 | 6+ | Varies by subgroup | High | Better than RAID 10, less than RAID 0 |
| RAID 60 | 8+ | Higher than RAID 50 | High | Lower than RAID 50 |
One of the biggest practical questions is whether to use software RAID or hardware RAID.
Software RAID is managed by the operating system. On Linux, this is often done with tools like mdadm or with filesystems and volume managers that include RAID-like features.
The main advantage is flexibility. Software RAID is often easier to inspect, migrate, automate, and recover, especially in Linux environments. It also avoids dependence on a specific RAID controller model. Modern CPUs are usually more than capable of handling the overhead for many workloads.
Software RAID is also often cheaper because you don't need a dedicated RAID card.
Hardware RAID uses a dedicated controller card or onboard RAID chipset to manage the array independently of the OS.
This used to be much more appealing when CPU overhead mattered more and dedicated RAID cards brought features like battery-backed cache. In some enterprise environments, hardware RAID is still used for specific workflows and vendor-supported storage stacks.
But hardware RAID has downsides too. If the RAID controller fails, recovery may depend on finding a compatible replacement. Management can also be more opaque compared to software RAID, and lower-end "fake RAID" implementations can create more confusion than value.
For many modern Linux servers, software RAID is the more practical choice. It's transparent, portable, and usually easier to troubleshoot.
Hardware RAID can still make sense in some enterprise setups, especially where a specific platform is already standardized around it, or where controller-based caching and vendor support are part of the design.
In other words, this isn't about one option always being better. It's about choosing the simpler and more maintainable tool for the environment you're running.
ZFS is not traditional RAID, but it often comes up in the same conversation because it can do many of the things people want from RAID, while also adding filesystem-level features.
OpenZFS combines storage management and the filesystem in a way that lets it handle redundancy, snapshots, checksums, and data integrity together. Instead of thinking only about RAID levels, ZFS users often think in terms of vdevs and storage pools.
Common ZFS layouts include mirrors, RAIDZ1, RAIDZ2, and RAIDZ3.
RAIDZ1 is roughly comparable to RAID 5 in that it can tolerate one disk failure
RAIDZ2 is roughly comparable to RAID 6 and can tolerate two disk failures
RAIDZ3 can tolerate three disk failures
Where ZFS stands out is data integrity. ZFS checksums data and metadata, and it can detect silent corruption, often called bit rot. In redundant configurations, it can often repair corrupted data automatically by reading a good copy elsewhere in the pool.
That's a major reason people choose ZFS for storage servers, backup systems, and environments where data correctness matters as much as uptime.
Still, ZFS isn't automatically the right answer for every system. It has its own memory expectations, operational habits, and design choices. It also doesn't remove the need for backups. Snapshots are helpful, but snapshots are not the same thing as off-system backups.
RAID and ZFS are often discussed as if they are direct competitors, but that oversimplifies things.
Traditional RAID is usually focused on block device redundancy and performance. ZFS is a filesystem and volume manager with integrated redundancy options.
If you want a simple mirrored boot volume or an mdadm RAID 10 for a Linux host, traditional software RAID may be the straightforward option.
If you want end-to-end checksumming, snapshots, pooled storage, and self-healing behavior in redundant configurations, ZFS may be the better fit.
A lot depends on the workload, the operating system, your team's familiarity with the platform, and how much complexity you want to manage.
The right RAID level depends on what you're optimizing for.
If you care most about speed and don't care about redundancy, RAID 0 is the obvious answer, though it should be used very carefully.
If you want simple redundancy for a smaller setup or boot volume, RAID 1 is often enough.
If you want a good balance of capacity and protection for larger storage, RAID 6 is often safer than RAID 5.
If you want strong performance and fault tolerance for production workloads, RAID 10 is a common favorite.
If you're building a storage server and care about data integrity features beyond classic RAID, ZFS deserves a serious look.
The biggest mistake is choosing based on raw usable capacity alone. Saving extra space isn't very helpful if rebuild times, failure risk, or recovery complexity become a problem later.
The exact steps depend on your OS, controller, and storage stack, but the general process looks similar across most environments.
First, decide what problem you're solving. Are you trying to keep a hypervisor online after a drive failure? Improve database IOPS? Build a storage server? The answer affects whether RAID 1, RAID 6, RAID 10, or ZFS makes the most sense.
Next, use matching drives whenever possible. Mixing capacities and performance levels usually leads to wasted space or uneven behavior.
Then, decide whether you want software RAID, hardware RAID, or ZFS. For many Linux servers, software RAID is the cleaner option. For storage-focused setups, ZFS may be worth the extra planning.
After that, monitor drive health. RAID is not something you set once and forget forever. You want SMART monitoring, alerts, and a plan for replacing failed disks quickly.
And finally, back everything up anyway. This is the part people skip until they regret it.
One of the biggest myths is that RAID is a backup. It isn't.
Another common myth is that RAID 5 is always enough. It used to be the default recommendation for a lot of arrays, but today's larger disks and longer rebuild times make that more questionable in many scenarios.
It's also a mistake to assume hardware RAID is always better than software RAID. On modern Linux systems, software RAID is often easier to manage and recover.
And while ZFS has a strong reputation for data integrity, it still isn't magic. You still need sound backups, monitoring, and operational discipline.
RAID is one of those storage topics that sounds more complicated than it really is once you break it down. At its core, it's just a way to combine drives for better performance, redundancy, or both.
The important thing is knowing what kind of protection you're actually getting. RAID can help a server stay online when a disk fails, but it doesn't replace backups, and it doesn't protect against every kind of data loss. For many workloads, RAID 1, RAID 6, and RAID 10 are the most practical traditional choices, while ZFS is worth considering when data integrity and filesystem-level features matter just as much as redundancy.
If you're planning infrastructure for storage-heavy applications, virtualization, backups, or production hosting, the right setup depends on your workload, your recovery goals, and how much complexity you want to manage. xTom provides dedicated servers, colocation, IP transit, shared hosting, and general IT services for a wide range of projects, while V.PS offers scalable NVMe-powered KVM VPS hosting for lighter deployments and flexible cloud workloads.
Ready to discuss your infrastructure needs? Contact the team to explore the right solution for your projects.
RAID is a way to combine multiple drives into one storage setup to improve performance, add redundancy, or both. Different RAID levels handle that in different ways.
RAID helps protect against drive failure, but not all data loss. It usually won't protect against accidental deletion, ransomware, corruption, or site-level disasters. That's why you still need backups.
There isn't one best RAID level for everything. RAID 1 is simple and reliable, RAID 6 is often better for larger parity-based arrays, and RAID 10 is a strong choice when you want both performance and redundancy.
RAID 5 can still make sense in some smaller arrays, but many admins are more cautious about it now because rebuild times on large disks can be long, and the array only tolerates one drive failure.
For many production workloads, RAID 10 is often preferred because it offers better write performance and usually less stressful rebuild behavior. RAID 5 is more space-efficient, though, so it depends on whether performance or usable capacity matters more.
Not always, but software RAID is often the simpler and more flexible option on modern Linux servers. Hardware RAID can still make sense in some enterprise environments, especially where a specific controller platform is already part of the design.
ZFS isn't just a RAID alternative, it's a filesystem and volume manager with integrated redundancy options. It can be a better fit when you want snapshots, checksumming, pooled storage, and protection against silent corruption, but it still requires planning and it still doesn't replace backups.
No. RAID helps with uptime after disk failure. Backups help you recover data after deletion, corruption, malware, or larger disasters. You usually want both.
]]>Debian and Ubuntu are closely related, but they don't feel the same once you start running real workloads. Here's what actually changes, and when those differences matter.
]]>The answer is yes, there is, but it's not as dramatic as some people make it sound.
At a glance, Debian and Ubuntu share a lot. They both use .deb packages, both rely heavily on APT for package management, and both can make excellent choices for servers, cloud instances, development boxes, and self-hosted apps. That shared foundation is exactly why the comparison comes up so often.
But once you get past the package format and basic command-line similarity, the differences start to matter. Release cadence, software freshness, default behavior, commercial backing, package extras like Snap, and how much hand-holding you want all change the day-to-day experience. Debian maintains separate stable, testing, and unstable branches, while Ubuntu ships regular releases every six months and LTS releases every two years.
So, is there any real difference between Debian and Ubuntu?
Yes, there is. The better question is whether those differences matter for what you're trying to do.
Debian is usually the more conservative option. It leans toward stability, long-term consistency, and fewer surprises.
Ubuntu takes Debian's foundation and adds its own packaging decisions, release schedule, hardware support focus, cloud image ecosystem, and commercial support model through Canonical. Ubuntu also includes Snap as part of its software story, alongside traditional Debian packages managed through APT.
That means Debian often feels cleaner and a bit more minimal, while Ubuntu often feels more convenient out of the box.
Neither approach is automatically better. It depends on whether you care more about a steady base or newer defaults and a more opinionated experience.
Ubuntu is derived from Debian, so they start from a shared family tree.
That similarity shows up immediately in things like:
apt updateapt install.deb packagesIf you know your way around Debian, Ubuntu won't feel foreign. If you know Ubuntu, Debian won't feel alien either.
This is why many tutorials work across both, especially for common services like NGINX, Apache, MariaDB, PostgreSQL, Docker, SSH hardening, and basic firewall setup. In fact, if you're working through tasks like securing SSH or configuring a firewall, a lot of the same concepts apply across both systems. For related reading, xTom has guides on setting up UFW on Debian and securing SSH on a Linux server.
Still, similar isn't the same thing.
This is one of the biggest practical differences.
Debian Stable is known for being careful and predictable. Packages are usually older than what you'll see on Ubuntu, but that's by design. The point is to avoid unnecessary churn and keep a dependable base for long-running systems. Debian explicitly recommends Stable for production use.
Ubuntu moves faster. Its regular releases arrive every six months, and its LTS releases arrive every two years. Ubuntu 24.04 LTS is supported for five years under standard maintenance, with longer support available through Ubuntu Pro options from Canonical.
What does that mean in plain English?
On Debian, you're more likely to get older, well-settled software versions.
On Ubuntu, you're more likely to get newer kernels, newer packages, and newer platform features without doing as much work yourself.
For a server, that can matter a lot. If you're deploying something that values consistency over novelty, Debian is often attractive. If you need newer support for hardware, newer app dependencies, or a more current cloud-first experience, Ubuntu often gets there faster.
Debian tends to ask for less trust and give you more control.
Ubuntu tends to make more decisions for you.
That's not an insult to Ubuntu. In many cases it's the whole point. Ubuntu is often designed to get more users, including newer Linux users and enterprise teams, up and running quickly. Debian is more likely to say, in effect, "Here's a clean system, now build what you want."
That philosophical difference can shape how the system feels over time.
Debian often feels leaner and less opinionated.
Ubuntu often feels more pre-integrated.
If you like a distro that stays out of your way, Debian has a strong appeal. If you like a distro that smooths over rough edges and ships more ready-made choices, Ubuntu may feel easier.
This is another area where people notice a real difference.
Debian is centered around its package repositories and long-established packaging policies. Ubuntu also uses APT and .deb packages, but Canonical has made Snap a major part of the Ubuntu ecosystem, especially for some types of software distribution. Ubuntu's own server documentation describes software management in Ubuntu as involving both Debian packages and snaps.
Some admins like Snap because it can simplify packaging and distribution across environments.
Others don't like it because it adds another layer, another package format, and another set of defaults to think about.
On many servers, this won't be a deal-breaker either way. But it is a real difference, and for some Linux users it's one of the first things they point to when comparing Debian and Ubuntu.
Debian is community-driven.
Ubuntu is backed by Canonical, which gives it a commercial support path and a big enterprise footprint. Canonical also offers products and services around Ubuntu, including long-term security maintenance options.
For some businesses, that matters. A company may prefer Ubuntu because it fits better with vendor support expectations, cloud marketplace images, and established enterprise workflows.
For others, Debian's community-driven model is a plus, not a minus. Debian has a long-standing reputation for careful governance, strong documentation, and a stable production track.
On paper, both work well in hosting environments.
In practice, Ubuntu often gets first-class treatment from cloud providers, container ecosystems, and third-party software vendors. That's partly because Ubuntu is widely used in public cloud environments and has a very visible server presence.
Debian is also widely available and widely trusted, especially for VPS deployments, self-hosting, and classic Linux server roles. It just tends to feel a bit less commercial and a bit more stripped back.
If all you need is a clean Linux base for web hosting, reverse proxying, databases, or self-hosted apps, either can be a solid fit.
Both Debian and Ubuntu take security seriously, but they don't package and maintain things in exactly the same way.
Debian Stable is conservative about what changes after release. Security fixes and selected updates are handled with care, and the project documents that stable updates are reviewed case by case rather than treating a stable release like a rolling target.
Ubuntu also provides security maintenance, especially on LTS releases, while layering on Canonical's support model and longer optional support programs.
For most admins, the real takeaway is simple: both can be secure, but Debian usually changes less, and Ubuntu usually offers more structured commercial support around the base system.
For most people, Ubuntu is easier at first.
That's especially true if you're newer to Linux, using newer hardware, or following vendor documentation that explicitly targets Ubuntu.
Ubuntu usually has a more guided feel. Debian is more of a "know what you want and build it" experience.
That doesn't mean Debian is hard. It just tends to assume a little more comfort with Linux, especially if you want to tune the system beyond the basics.
If you're running a headless server and you're already comfortable with the shell, the ease gap gets much smaller.
A lot of Linux admins would say yes, but only with context.
Debian is often a great server OS because it's steady, lightweight in feel, and avoids unnecessary churn. That can make it especially appealing for web servers, databases, container hosts, internal services, VPN endpoints, and other systems where boring is a feature.
Ubuntu is also a very common server OS, especially in cloud environments. There are plenty of good reasons to use it, including fresher packages, strong cloud availability, and a wide support ecosystem.
So it isn't really "Debian for servers, Ubuntu for desktops." That's too simplistic.
A better way to say it is this:
Debian is often chosen when the admin wants maximum predictability.
Ubuntu is often chosen when the admin wants convenience, broader vendor alignment, or newer defaults.
That's a decent shorthand, but it leaves out too much.
Ubuntu starts from Debian, but it isn't just Debian with a new wallpaper.
Ubuntu has its own release engineering, repositories, support lifecycle, packaging choices, defaults, and ecosystem priorities. Canonical also develops Ubuntu-specific tooling, publishes release notes and support timelines, and maintains services around the platform.
So yes, Ubuntu comes from Debian.
No, that doesn't make them interchangeable in every real-world scenario.
If you're deciding what to deploy on a VPS or dedicated server, start with the workload, not the distro debate.
Ask yourself:
Do you want the steadiest possible base with fewer moving parts?
Debian is probably the better fit.
Do you want newer packages, broader out-of-the-box cloud familiarity, and a distro many vendors actively target?
Ubuntu may be the easier call.
Do you care about avoiding Snap in your workflow?
Debian will likely be more appealing.
Do you want a large ecosystem of Ubuntu-focused tutorials and commercial support options?
Ubuntu has an edge there.
For services like web hosting, reverse proxying, self-hosted apps, and common Linux infrastructure, either one can do the job well. What changes is how much updating, tweaking, and distro-specific decision-making you want to deal with over time.
Before you pick one, it helps to think through the setup you actually need.
Some apps are happy on older, stable packages.
Others need newer runtimes, kernels, or dependencies.
If the software stack needs newer components right away, Ubuntu may save time. If not, Debian may give you a cleaner long-term base.
Some software vendors document Ubuntu first.
That doesn't always mean Debian won't work, but it can mean less friction if you stick with the documented path.
This matters more than people admit.
If you like a distro that stays close to a minimal, stable core, Debian may simply feel better to manage.
If you prefer convenience and broader out-of-the-box compatibility, Ubuntu may be more comfortable.
Your Linux distro doesn't live in isolation.
If you're also deciding between web server stacks, database setups, or firewall tooling, it helps to choose a base that matches your comfort level. For example, if you're planning a web stack build, these xTom guides on NGINX vs. Apache and protecting a Linux server with Fail2Ban pair naturally with either Debian or Ubuntu.
Yes, there is a real difference, but it mostly shows up in philosophy and operations, not in basic Linux commands.
Debian is usually the calmer, more conservative choice.
Ubuntu is usually the more guided, faster-moving choice.
That means the difference is very real if you care about package freshness, default behavior, enterprise support paths, or Snap. If you just need a Linux server that can run common services well, the difference may feel smaller day to day.
In other words, Debian and Ubuntu are close relatives, but not twins.
Generally, yes. Debian Stable is specifically known for prioritizing a steady production base and careful updates. Ubuntu LTS is also stable, but Debian usually takes the more conservative path on package versions and change rate.
Not automatically. For many server workloads, performance differences are small. The more noticeable difference is usually package age, default services, and how much extra tooling is included rather than raw speed.
Yes. Ubuntu uses Debian-style .deb packages and APT, but it also supports snaps as part of its software ecosystem.
Either can be a good VPS operating system. Debian is a strong choice if you want a steady base with fewer moving parts. Ubuntu is a strong choice if you want newer packages, wider vendor targeting, or a more guided setup experience.
Usually because Debian feels less opinionated and more predictable over time. Many admins like the idea of installing a clean base system and adding only what they need.
Usually, yes. Ubuntu tends to be easier for newer Linux users because of its defaults, documentation footprint, and broader beginner-oriented ecosystem.
If you're trying to choose between Debian and Ubuntu, the good news is that there isn't really a wrong answer, at least not for most common hosting and server tasks.
Both are mature, widely used Linux distributions with a shared foundation. Debian tends to appeal to people who want a steady and minimal base system, while Ubuntu tends to appeal to people who want newer defaults, wider ecosystem support, and a more guided experience. The better choice depends less on distro loyalty and more on how you like to run your systems.
Thanks for reading! If you're planning your next deployment, xTom offers dedicated servers, colocation, IP transit, shared hosting, and general IT services. For smaller projects or scalable virtual infrastructure, V.PS provides NVMe-powered KVM VPS hosting that works well for Linux workloads, including both Debian and Ubuntu.
Ready to discuss your infrastructure needs? Contact the xTom team to explore the right solution for your projects.
]]>OpenClaw is an open-source, self-hosted AI agent that lets you chat with your own personal assistant through Telegram, Discord, Slack, WhatsApp, and more. This guide walks you through running it on your own machine or Linux server so your data stays yours.
]]>And one where your conversations and data never leave infrastructure you control.
That's essentially what OpenClaw is.
OpenClaw, previously known as Moltbot and originally Clawdbot, is an open-source AI agent that runs on your own machine or server and connects to messaging apps you already use. Instead of being another chat interface, it acts more like an assistant capable of executing tasks, maintaining memory, and interacting with external tools.
This guide explains what OpenClaw is, how it works, and how to get it running on your own system.
Most AI tools are reactive. You open an app, ask a question, and get a response.
OpenClaw is designed to go further.
First, it can be proactive. You can configure reminders, scheduled briefings, and automated notifications.
Second, it can execute tasks. Depending on your configuration, OpenClaw can:
Third, it maintains persistent memory across conversations. Instead of resetting context each session, it builds context over time.
OpenClaw itself does not include a model. Instead it connects to whichever backend you prefer, including:
The platform also supports integrations with messaging apps including Telegram, Discord, Slack, WhatsApp, Signal, and Matrix.
OpenClaw runs a gateway service that manages:
Messaging platforms connect to the gateway so conversations maintain context even if you switch platforms.
OpenClaw also supports extensions and tools that allow it to interact with external systems or run local commands.
To self-host OpenClaw you'll need a machine to run it on. This could be:
For lightweight setups, modest resources are enough. Running local AI models or heavy sandboxing may require more RAM and CPU.
You'll also need:
If you're deploying on a remote server, our guide on SSH can help.
If you're installing on Ubuntu or Debian, start by updating system packages:
sudo apt update && sudo apt upgrade -y
The easiest way to install OpenClaw is with the official one-line installer.
It works on macOS, Linux, and Windows and installs everything required automatically.
Run the following command:
# Works everywhere. Installs everything. You're welcome. 🦞
curl -fsSL https://openclaw.ai/install.sh | bash
Run the installer in PowerShell:
# Works everywhere. Installs everything. You're welcome. 🦞
iwr -useb https://openclaw.ai/install.ps1 | iex
The installer downloads dependencies, installs Node.js if needed, and launches the OpenClaw onboarding process.
Once installation finishes, open the dashboard in your browser:
http://127.0.0.1:18789/
From there you can:
Docker is optional.
Most users should start with the normal install flow above, especially when running OpenClaw on their own machine.
Docker is useful if you want:
Docker can also be used specifically for agent sandboxing, even if the OpenClaw gateway runs directly on the host.
If you prefer a containerized deployment, OpenClaw provides a Docker setup script.
Make sure you have Docker and Docker Compose installed.
From the OpenClaw repository directory, run:
./docker-setup.sh
The script will:
After setup completes, open:
http://127.0.0.1:18789/
Paste the generated token into the dashboard to finish pairing.
If you want to skip building the container locally and instead pull the official image, run:
export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
./docker-setup.sh
This will download the prebuilt container image from GitHub Container Registry.
OpenClaw can also use Docker for sandboxing.
When enabled, agent tools can run inside isolated containers rather than directly on your host system. This allows stricter control over filesystem access, networking, and permissions.
Sandboxing is particularly useful if your agents execute shell commands or modify files.
Telegram is often the easiest integration to start with.
Search for @BotFather and run:
/newbot
Follow the prompts and copy the generated bot token.
Add the token in the OpenClaw dashboard under Telegram integration settings.
Visit the Discord Developer Portal:
https://discord.com/developers/applications
Create an application, add a bot, generate an invite link, and add it to your server.
Then enter the bot token in OpenClaw.
Create a Slack app via:
Assign required scopes, install it to your workspace, and enter the credentials in OpenClaw.
Inside the OpenClaw dashboard, choose your AI provider.
If using hosted models, paste your API key and select a model.
If running locally, configure OpenClaw to connect to Ollama:
http://localhost:11434
Example model:
llama3
OpenClaw allows you to run a personal AI agent on infrastructure you control while connecting it to messaging platforms you already use.
For most users, the standard install flow is the simplest way to get started. Docker is available if you want containerization or sandboxing, but it's optional.
That flexibility makes OpenClaw easy to run whether you want it on your own machine, a home lab server, or a public VPS.
For larger always-on deployments, xTom provides enterprise-grade dedicated servers and colocation services. For smaller deployments, V.PS offers scalable NVMe-powered KVM VPS hosting suitable for running OpenClaw.
xTom also provides IP transit, shared hosting, and a full range of IT services to support your infrastructure needs.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
OpenClaw is a self-hosted AI agent that connects to messaging platforms like Telegram, Discord, and Slack and can execute tasks using external tools.
No. Docker is optional. The standard install flow works on macOS, Windows, and Linux without containers.
The installer installs Node.js, dependencies, and launches the OpenClaw onboarding process.
Yes. You can run the OpenClaw gateway directly on the host while using Docker only for sandboxed agent tools.
OpenClaw supports Telegram, Discord, Slack, WhatsApp, Signal, Matrix, and other integrations.
They are the same project under different names. The project started as Clawdbot, was renamed Moltbot, and is now OpenClaw.
]]>The internet connects billions of devices across the globe, but most people have no idea what's actually happening behind the scenes. This guide breaks down how data travels from one point to another, in plain English.
]]>Packets of data are flying across continents, routers are making split-second decisions, and dozens of systems are working together so you can watch a YouTube video or send an email.
Understanding how all of this fits together isn't just interesting, it's genuinely useful if you work with servers, networks, or anything web-related.
Let's walk through it from the ground up.
The internet isn't one single network owned by one company or government. It's a massive collection of interconnected networks, run by internet service providers (ISPs), universities, governments, corporations, and hosting providers, all agreeing to talk to each other using common standards.
At the physical layer, this means fiber optic cables running under oceans, copper wiring in neighborhoods, and wireless signals bouncing off towers. At the logical layer, it means protocols, which are basically agreed-upon rules for how data is formatted, addressed, and delivered.
The combination of these physical and logical layers is what lets a laptop in Tokyo communicate with a server in Amsterdam in milliseconds.
Most people picture the internet as something wireless, living in the cloud. In reality, the vast majority of international internet traffic travels through submarine cables, bundles of fiber optic strands laid along the ocean floor connecting continents to each other.
There are hundreds of these cables in operation today, stretching hundreds of thousands of kilometers across the Atlantic, Pacific, and Indian Oceans. A single modern cable system can carry dozens of terabits of data per second. When you send an email from New York to London, there's a very real chance the data physically traveled along the seabed to get there.
These cables are owned and funded by consortiums of telecoms, ISPs, and increasingly by large technology companies that have invested heavily in their own private cable infrastructure. They land at coastal cable stations, where the signal is amplified and handed off to terrestrial networks for the last stretch of the journey inland.
Submarine cables are also surprisingly vulnerable. They get damaged by ship anchors, fishing equipment, and occasionally earthquakes. When a major cable goes down, entire regions can see significant slowdowns or rerouting of traffic until repairs are made, which can take weeks given the logistics of sending a specialized repair ship to the middle of an ocean.
Once data arrives on land, it still needs to find its way from one network to another. That's where Internet Exchange Points (IXPs) come in.
An IXP is a physical facility where different networks come together to exchange traffic directly with each other, rather than routing it through a third-party transit provider. Think of it like a central post office where multiple courier companies drop off and pick up each other's parcels, instead of each one driving to every other company's depot individually.
Major IXPs like DE-CIX in Frankfurt, AMS-IX in Amsterdam, and LINX in London handle enormous volumes of traffic every day, often multiple terabits per second at peak times. By peering at an IXP, networks can exchange traffic more directly, which reduces latency, cuts down on transit costs, and keeps more traffic local rather than routing it across the world unnecessarily.
For end users, IXPs are largely invisible, but they have a real impact on the speed and efficiency of the internet. A well-connected city with a thriving IXP tends to have faster, cheaper internet than one where all traffic has to be routed through a distant hub.
Every device connected to the internet needs an address so that data knows where to go. That's what an IP address is. Think of it like a postal address, but for computers.
There are two versions in use today. IPv4 uses addresses like 192.168.1.1, expressed as four numbers separated by dots. The problem is that IPv4 only supports around 4.3 billion unique addresses, which sounds like a lot until you account for billions of smartphones, laptops, smart TVs, and servers all needing one. That's why IPv6 was developed, using a much longer format that supports a virtually unlimited number of addresses.
Most of the internet today runs on a mix of both, with IPv6 adoption growing steadily.
Humans aren't great at remembering strings of numbers. That's where the Domain Name System (DNS) comes in. DNS is essentially the internet's phonebook. When you type example.com into your browser, your computer asks a DNS resolver, "what's the IP address for this domain?" The resolver looks it up and returns something like 93.184.216.34, which your browser then uses to connect to the right server.
This lookup happens in milliseconds, and the results are often cached so it doesn't have to happen every single time you visit the same site.
DNS is one of the most foundational parts of how the internet works, and when it breaks, things go wrong fast.
When you send or receive data over the internet, it doesn't travel as one continuous stream. It's broken up into small chunks called packets. Each packet contains a piece of the data you're sending, plus addressing information so routers know where to deliver it.
The protocols that govern this are TCP/IP, which is really two separate things working together.
IP (Internet Protocol) handles addressing and routing. It decides how packets are labeled and where they should go.
TCP (Transmission Control Protocol) handles reliability. It makes sure packets arrive in the right order, and if any are lost along the way, it requests them again. This is why downloading a file doesn't result in a corrupted mess even if a few packets drop.
For things where speed matters more than perfect accuracy, like live video streaming or gaming, a lighter protocol called UDP is often used instead. UDP doesn't bother with re-requesting lost packets, which keeps latency lower.
Packets don't travel in a straight line from point A to point B. They hop through a series of routers, each one making a decision about where to send the packet next based on its destination address.
Routers maintain routing tables, which are essentially maps of the network. They're constantly updated using routing protocols. For traffic within a single network, protocols like OSPF are common. For traffic between different networks across the internet, the key protocol is BGP, or Border Gateway Protocol.
BGP is sometimes called the "glue of the internet." It's how large networks, called autonomous systems, advertise which IP addresses they're responsible for, so other networks know how to route traffic to them. IXPs are where much of this BGP peering happens in practice, with networks exchanging routing information and traffic directly across a shared switching fabric. When BGP goes wrong, large parts of the internet can become unreachable. It's happened before, and it's a reminder of just how interdependent the whole system is.
Once your browser has the IP address of the server you want to reach, it needs a way to actually request and receive web content. That's where HTTP (HyperText Transfer Protocol) comes in. Your browser sends an HTTP request asking for a specific page, and the server responds with the content.
Most of the web now uses HTTPS, which is HTTP with encryption layered on top via TLS (Transport Layer Security). This means the data traveling between your browser and the server is encrypted, so third parties can't easily intercept and read it. You'll see this indicated by the padlock icon in your browser's address bar.
Getting HTTPS set up on a server used to require purchasing certificates, but today tools like Certbot make it straightforward to get free certificates from Let's Encrypt.
When you request a webpage, something on the other end has to respond. That something is a server, usually sitting in a data center somewhere in the world. Data centers are purpose-built facilities with redundant power, cooling, and network connectivity designed to keep servers running around the clock.
The physical path your data takes to reach that server depends a lot on geography. A request from Singapore to a server in the same city might travel just a few milliseconds. The same request to a server in Europe might take 150ms or more, simply due to the physical distance the light and signals have to travel through cables, including, quite possibly, a submarine cable crossing an ocean.
This is one of the main reasons why businesses choose servers or hosting locations geographically close to their users.
Content Delivery Networks, or CDNs, solve the distance problem by distributing copies of content across many servers around the world. When you load a popular website, there's a good chance you're not getting the content from the origin server at all. You're getting it from a CDN node nearby.
CDNs are especially useful for static assets like images, CSS, and JavaScript files, things that don't change between users. By serving these from a location close to the visitor, load times drop noticeably.
Here's the full picture of what happens when you visit a website, simplified into a sequence:
All of that happens, usually, in well under a second.
The internet is a genuinely impressive feat of engineering, built on layers of open standards and cooperation between thousands of independent organizations, tied together physically by cables on the ocean floor and logically by exchange points where networks shake hands and share traffic. Once you understand the basics, things like DNS outages, latency issues, or TLS errors stop being mysterious and start making a lot more sense.
At xTom, we work with this infrastructure every day. Whether you're running applications in the cloud, connecting your business to the internet, or building something that needs reliable, low-latency connectivity, the quality of your underlying infrastructure matters. xTom offers dedicated servers, colocation, and IP transit services across global data centers, while V.PS provides NVMe-powered scalable KVM VPS hosting for teams that need fast, flexible compute. If you need something more accessible to get started, shared hosting is available too. You can explore the full range of xTom services here.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
The internet is the physical and logical network infrastructure, the cables, routers, servers, and protocols. The World Wide Web is a service that runs on top of the internet, specifically the system of websites and pages you access through a browser using HTTP. Email, FTP, and VoIP are also internet services, but they're not part of the Web.
There are over 600 submarine cable systems either in service or under construction as of the mid-2020s, totaling more than 1.4 million kilometers of cable. Ownership is typically shared between consortiums of ISPs and telecoms, though companies like Google, Meta, and Microsoft have increasingly funded and built their own dedicated cable systems to handle their traffic demands.
Traffic gets rerouted automatically through other available cables and paths, though this can increase latency and, in regions with limited cable redundancy, cause noticeable slowdowns. Repair vessels have to locate the fault and splice the cable back together, a process that can take several weeks depending on the location and sea conditions.
An IXP is a physical location where different networks interconnect and exchange traffic directly with each other. Without IXPs, traffic between two networks would have to travel through paid transit providers, adding cost and often extra latency. IXPs make the internet more efficient, more local, and generally faster for end users near them.
Your connection to your ISP might be fine, but speed depends on every link in the chain between you and the server you're trying to reach. Congestion on intermediate networks, a slow or overloaded server, or geographic distance, including how many submarine cable hops are involved, can all cause slowdowns that have nothing to do with your local connection.
Latency is the time it takes for a packet to travel from your device to a destination and back, usually measured in milliseconds. Lower latency means more responsive connections, which matters especially for gaming, video calls, and anything real-time. Even on a fast connection, high latency can make things feel sluggish.
If the DNS resolver your device is using becomes unavailable, you won't be able to resolve domain names into IP addresses, so websites will appear unreachable even if your internet connection and the target servers are both working fine. Using a reliable, redundant DNS resolver helps avoid this. Options like DNS.SB offer privacy-focused alternatives to default ISP resolvers.
An autonomous system (AS) is a large network or group of networks under a single administrative control, like an ISP, a major corporation, or a hosting provider. Each AS has a unique number (ASN) and uses BGP to advertise its IP address ranges to the rest of the internet. The internet is essentially a web of thousands of autonomous systems exchanging routing information with each other, often meeting up to do so at IXPs.
Technically the same protocols are used globally, but in practice the internet experience varies significantly. Some countries filter or block certain content at the network level. Connection speeds and latency differ based on infrastructure investment, and access to submarine cables and IXPs isn't equal across all regions. Countries or islands with fewer cable landing points tend to have less redundancy and can be more vulnerable to outages when a cable is cut.
]]>A looking glass is a web-based diagnostic tool that lets anyone query your network's routing tables and run traceroutes from your perspective. Learn what it does, why networks use them, and how to set one up yourself.
]]>A looking glass is a web-based tool that allows anyone to run network diagnostic commands like ping, traceroute, and BGP route queries directly from a network operator's infrastructure. Instead of testing connectivity from your own computer, you can see how things look from a data center in Tokyo, London, or anywhere else that hosts a looking glass server.
For network operators, hosting a looking glass shows what an end user could expect from your network, and helps troubleshoot connectivity issues. For everyone else, it's an incredibly useful diagnostic tool that provides insights into internet routing you simply can't get any other way.
In this guide, we'll explain what a looking glass is, why they're useful, and walk you through hosting your own.
At its core, a looking glass is a web interface that exposes read-only access to network diagnostic tools running on a server. Think of it as a window into a network's routing infrastructure.
When you visit a looking glass, you can typically perform several types of queries:
BGP route lookups show you how a specific IP prefix is advertised and what autonomous system (AS) path it takes through the internet. This is particularly useful for diagnosing routing issues or understanding peering relationships.
Traceroute reveals the path packets take from the looking glass server to a destination IP address, showing each hop along the way with latency measurements.
Ping tests check basic connectivity and measure round-trip time to a destination.
Some looking glasses also support additional queries like checking specific BGP communities, viewing the full BGP routing table summary, or running MTR (My Traceroute) which combines traceroute with continuous monitoring.
The key distinction is that all these commands run from the network operator's infrastructure, not your local machine. This gives you a completely different perspective on network topology and routing behavior.
Network operators host looking glasses for several practical reasons, though the primary motivation is usually customer support and transparency.
When a customer reports connectivity issues to a specific destination, support teams can use their own looking glass to verify routing and diagnose problems. Instead of asking customers to run commands and paste results, technicians can see exactly what's happening from the network's perspective in real-time.
Looking glasses also demonstrate routing policies and peering relationships. If you're evaluating a hosting provider or transit provider, their looking glass shows you concrete data about their network connectivity rather than just marketing claims. You can see which networks they peer with, what paths your traffic would take, and verify their presence in specific regions.
For networks with multiple points of presence (PoPs) around the world, looking glasses at each location help demonstrate their global reach and let potential customers test connectivity from regions they care about.
From a technical standpoint, looking glasses are relatively simple to implement and operate. The computational overhead is minimal since they're just executing standard networking commands that are already available on the server. The main considerations are security (preventing abuse) and rate limiting to avoid overload.
The technical implementation of a looking glass is straightforward. At the most basic level, it's a web application that accepts user input (like an IP address or domain), validates it, constructs a shell command with that input, executes it on the server, and returns the output formatted for display in a browser.
For security, proper input validation is critical. Since the looking glass executes system commands based on user input, it needs to sanitize everything to prevent command injection attacks. Most implementations use strict whitelisting of allowed characters and patterns, ensuring that only valid IP addresses, CIDR blocks, or domain names get processed.
Modern looking glass software typically runs commands with limited privileges and may use containerization or sandboxing to isolate the execution environment from the rest of the system. Rate limiting prevents abuse by restricting how many queries a single IP address can make within a given timeframe.
The web interface itself is usually quite minimal, consisting of a form to select the query type and enter the target, with results displayed in a preformatted text block that preserves the command-line output format. Some implementations offer additional features like query history, multiple server selection for networks with many locations, or API endpoints for programmatic access.
Under the hood, the application interfaces with the system's routing daemon (like BIRD, FRRouting, or Quagga) to query BGP information, and uses standard tools like ping and traceroute for connectivity tests.
Setting up a looking glass is relatively simple. We'll walk you through the process using LookingGlass, one of the most popular open-source implementations.
Before you begin, you'll need a server with:
For testing BGP features, you'll need a system that's actually running BGP and has routing tables to query. For basic ping and traceroute functionality, any internet-connected server works fine.
First, install the necessary dependencies. On Debian or Ubuntu:
sudo apt update
sudo apt install nginx php-fpm php-cli git traceroute mtr-tiny
On RHEL-based systems like AlmaLinux or Rocky Linux:
sudo dnf install nginx php php-fpm git traceroute mtr
Clone the LookingGlass repository to your web root:
cd /var/www
sudo git clone https://github.com/telephone/LookingGlass.git
sudo chown -R www-data:www-data LookingGlass
Create an NGINX server block for the looking glass. Create a new file at /etc/nginx/sites-available/lookingglass:
server {
listen 80;
server_name lg.example.com;
root /var/www/LookingGlass;
index index.php;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php-fpm.sock;
}
}
Enable the site and restart NGINX:
sudo ln -s /etc/nginx/sites-available/lookingglass /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx
For production use, you should absolutely set up HTTPS. You can get a free certificate using Let's Encrypt with Certbot.
Copy the example configuration file and edit it:
cd /var/www/LookingGlass
sudo cp LookingGlass/Config.php.example LookingGlass/Config.php
sudo nano LookingGlass/Config.php
The configuration file lets you customize various aspects of your looking glass. Key settings include:
rateLimit controls how many requests a user can make in a specific timeframe. The default is usually reasonable, but adjust based on your server's capacity and tolerance for abuse.
forbiddenNetworks lets you specify networks that shouldn't be queried, like private IP ranges or your internal management networks.
location and facility let you specify where this looking glass is hosted geographically.
customFooter can be used to add contact information or links to your main website.
If you're running BGP and want to expose routing information, you'll need to configure access to your BGP daemon. For BIRD, this typically means ensuring the BIRD socket is accessible to the web server user with appropriate permissions.
Never run your looking glass with excessive privileges. The web server user should only have access to the specific commands it needs to execute.
Implement strict input validation beyond what the software provides by default. Consider adding a Web Application Firewall (WAF) or using Fail2Ban to protect against brute force attacks and abuse.
Set up rate limiting at both the application level and potentially at your web server or firewall level. This prevents a single user from overwhelming your system with queries.
Consider implementing a CAPTCHA or similar challenge for excessive usage to discourage automated abuse while still allowing legitimate users to access your looking glass.
Regularly update the looking glass software and all dependencies to patch any security vulnerabilities that may be discovered.
Once everything is configured, visit your looking glass URL in a web browser. You should see a clean interface with options to select query types and enter targets.
Test basic functionality by running a traceroute to a well-known public IP address like 8.8.8.8 or 1.1.1.1. The results should display in your browser showing each hop along the path.
Try a ping test to verify connectivity checks work as expected.
If you've configured BGP access, test a route lookup for a common prefix to ensure the integration with your routing daemon is working correctly.
Check that rate limiting is functioning by making several rapid queries and verifying that you eventually get blocked temporarily.
While we used LookingGlass in this guide, several other implementations exist with different features and approaches.
ALICE Looking Glass is a modern PHP-based looking glass with a focus on simplicity and clean design. It supports multiple routers and includes built-in rate limiting.
Bird's Eye is specifically designed for networks running BIRD and offers extensive BGP query capabilities along with a RESTful API for programmatic access.
Hybula's Looking Glass is a a modern looking glass based on Bootstrap 5 and PHP 8.
bgp.tools isn't self-hosted software, but rather a comprehensive looking glass aggregator that lets you query multiple networks' looking glasses from a single interface. It's worth mentioning because it demonstrates how useful these tools are when combined.
The choice of looking glass software mostly depends on your specific needs. If you're running BGP and want extensive routing information exposure, Bird's Eye or ALICE might be better choices. For simple traceroute and ping functionality, the basic LookingGlass implementation we covered is perfectly adequate.
Network troubleshooting is the most obvious use case. When users report connectivity issues, you can use multiple looking glasses to see if the problem is isolated to a specific region or affects multiple paths. By comparing routes from different locations, you can identify where packets are getting dropped or taking suboptimal paths.
Service providers often use looking glasses to verify peering relationships and routing policies. If you're negotiating peering with another network, you can use their looking glass to see how they currently route traffic and verify that announced prefixes are being received as expected.
Security researchers use looking glasses to investigate network hijacking incidents and BGP anomalies. When suspicious routing changes occur, looking glasses provide historical data and multiple vantage points to understand what happened.
Systems administrators use looking glasses to verify that changes to routing policies or network configurations are propagating correctly across the internet. After announcing new IP space or modifying BGP communities, you can check multiple looking glasses to confirm everything is working as intended.
Website operators concerned about latency can use looking glasses to understand how traffic routes to their servers from different regions, helping inform decisions about where to deploy additional infrastructure or content delivery nodes.
A looking glass focuses on routing and network path information, showing you how packets travel through the internet. A speedtest measures bandwidth and latency for data transfers. Looking glasses run diagnostic commands like traceroute and BGP queries, while speedtests actually transfer data to measure throughput. Both are useful, but for different purposes.
Not really. A looking glass can verify that the IP address is reachable and show the network path, but it can't test if your web service is actually responding correctly. For that, you'd want uptime monitoring tools like Uptime Kuma. However, if your website is unreachable, a looking glass can help diagnose whether it's a routing issue or something else.
Network operators often restrict queries to private IP ranges, certain geographic regions, or specific command types for security and abuse prevention. Some looking glasses might not expose full BGP routing tables if they contain sensitive business information about peering relationships. Rate limiting and query restrictions prevent malicious users from using the looking glass for network reconnaissance or DDoS amplification.
No, you can host a basic looking glass that only offers ping and traceroute functionality without any BGP involvement. However, BGP route queries are one of the most valuable features of a looking glass, so if you're running a network with BGP peering, including that functionality makes your looking glass much more useful.
Absolutely. While modern monitoring tools provide extensive internal metrics, looking glasses offer an external perspective that's incredibly valuable for diagnosing routing issues, verifying internet connectivity from different locations, and understanding how your network appears to the outside world. They complement rather than replace other monitoring solutions.
A looking glass is one of those tools that might seem niche until you need it, and then you'll wonder how you ever managed without one. Whether you're troubleshooting connectivity issues, verifying routing policies, or just curious about how internet traffic flows, having access to multiple looking glasses across different networks provides insights you simply can't get any other way.
For network operators, hosting a looking glass demonstrates transparency and provides a valuable self-service diagnostic tool for customers. The setup process is straightforward, and the maintenance overhead is minimal once everything is configured properly.
If you're running any kind of network infrastructure, consider setting up a looking glass. It's a relatively small investment of time that pays dividends in troubleshooting efficiency and customer satisfaction.
xTom provides enterprise-grade dedicated servers, colocation services, and IP transit with looking glasses available at each of our global points of presence. V.PS offers scalable, production-ready NVMe-powered VPS hosting perfect for hosting your own looking glass or any other network tools you need. We also offer shared hosting and general IT services tailored to your infrastructure requirements.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
]]>The Linux kernel is the core component that manages hardware resources and system operations in Linux distributions. In this article, we'll explain more about it.
]]>The kernel acts as a translator between your software and hardware, managing resources like CPU time, memory, and disk access. Without it, your programs couldn't communicate with your computer's physical components, and nothing would function.
In this article, we'll break down what the Linux kernel is, how it works, and why it matters for anyone running Linux systems.
The kernel is the core component of any operating system. It's a piece of software that runs with full access to your computer's hardware and manages every interaction between your applications and the physical resources they need.
When you open a file, connect to a network, or run a program, your kernel handles the technical details behind the scenes. It allocates memory, schedules processor time, manages file systems, and controls input/output operations across all your hardware devices.
Linux uses a monolithic kernel architecture, which means the kernel handles all these tasks directly rather than delegating them to separate servers or processes. This design choice makes Linux particularly efficient, since system calls and hardware access don't require as much overhead.
The Linux kernel specifically was created by Linus Torvalds in 1991 as a free alternative to proprietary Unix systems. Since then, it's become one of the largest collaborative software projects in history, with thousands of developers contributing code from around the world.
Understanding how the kernel manages resources helps explain why Linux performs the way it does and how to optimize it for different workloads.
The kernel decides which programs get to use your CPU and for how long. Modern Linux kernels use the Completely Fair Scheduler (CFS), which tries to give each process a fair share of processor time based on priority levels and system load.
When you have multiple applications running, the scheduler rapidly switches between them, creating the illusion that they're all running simultaneously. This happens thousands of times per second, so you don't notice the individual switches.
You can influence scheduling behavior through nice values and scheduling policies. Lower nice values give processes higher priority, while different scheduling classes let you optimize for throughput, latency, or real-time performance.
Your kernel controls how RAM gets allocated to different processes and what happens when you run out of physical memory. It uses virtual memory to give each process its own isolated address space, preventing programs from interfering with each other's data.
When physical RAM fills up, the kernel can move less frequently used memory pages to swap space on disk. This lets you run more applications than would fit in RAM alone, though accessing swapped memory is much slower than physical RAM.
The kernel also implements memory caching strategies that keep frequently accessed files in RAM, which is why your system often feels faster the longer it runs. File system operations can be served from cache rather than reading from disk repeatedly.
If you want to learn more about managing memory when it runs low, check out our guide on what is Linux swap and how to set it up.
One of the kernel's most important jobs is providing a consistent interface to hardware devices. Instead of requiring each application to know the specific details of every piece of hardware, the kernel presents a standardized way to interact with devices.
Device drivers are modules that teach the kernel how to communicate with specific hardware. When you plug in a USB device or install a new graphics card, the kernel loads the appropriate driver and makes that hardware accessible through standard interfaces.
This abstraction layer is why you can move a hard drive between different Linux systems and it just works. The file system doesn't care about the specific disk controller or interface, it only needs to communicate with the kernel's block device interface.
The kernel manages all file system access, handling everything from reading files to managing permissions and tracking disk usage. Linux supports multiple file systems, and the Virtual File System (VFS) layer lets different file systems coexist and be accessed through the same interface.
When you save a file, the kernel coordinates writing that data to disk, updating metadata, and ensuring data integrity. It also implements caching strategies that buffer writes and group them together for better performance.
File permissions and access controls are enforced at the kernel level. Even if an application tries to access a file it shouldn't, the kernel blocks that access based on user IDs, group memberships, and permission bits.
Your kernel implements the entire TCP/IP network stack, handling everything from raw Ethernet frames up through application-level protocols. It manages network interfaces, routes packets, handles TCP connections, and implements firewall rules.
When you make a network connection, the kernel sets up the socket, performs the TCP handshake, manages the connection state, and handles data transmission and reception. All of this happens transparently to the application making the connection.
Network performance tuning often involves adjusting kernel parameters that control buffer sizes, connection handling, and protocol behavior. Understanding these parameters helps optimize performance for specific workloads and network conditions.
The Linux kernel follows a time-based release cycle, with new major versions appearing roughly every 2-3 months. Version numbers use the format major.minor.patch, where the first number indicates major releases, the second tracks incremental updates, and the third represents bug fixes.
Not all kernel versions receive equal support. Long Term Support (LTS) kernels get security updates and bug fixes for several years, making them ideal for production systems where stability matters more than having the absolute latest features.
You can check your current kernel version by running uname -r in the terminal. Most Linux distributions package specific kernel versions that they've tested and configured for their system, so the kernel version might lag behind the latest upstream release.
When deciding whether to upgrade your kernel, consider what you're gaining versus the risk of introducing new issues. Security patches should be applied promptly, but jumping to the newest kernel release purely for new features can sometimes cause hardware compatibility problems or break existing drivers.
The Linux kernel is modular, meaning you don't need to compile every possible driver and feature into one massive kernel image. Modules are pieces of kernel code that can be loaded or unloaded at runtime as needed.
When you plug in a USB device, the kernel automatically loads the appropriate module to support that hardware. This keeps the base kernel smaller and more efficient while still providing support for a wide range of devices.
You can view loaded modules with lsmod and manually load or unload them using modprobe and rmmod. Most of the time, the kernel handles this automatically through hotplug mechanisms and configuration rules in /etc/modprobe.d/.
Kernel parameters can be tuned either at boot time through bootloader parameters or at runtime through the /proc/sys/ filesystem. Common tweaks include adjusting network buffer sizes, changing swappiness values, or modifying how the kernel handles file system caching.
If you work with servers regularly, you'll often want to check system details like processor information. Our guide on how to check CPU information in Linux covers the tools for examining hardware details that the kernel reports.
If you're running servers or hosting infrastructure, kernel selection becomes especially important. Different kernels offer different performance characteristics, security features, and hardware support.
Older kernels lack modern security features like kernel page-table isolation (KPTI), which protects against certain CPU vulnerabilities. They might also miss performance improvements that can significantly impact application performance under load.
However, newer isn't always better for production environments. Cutting-edge kernels can introduce regressions or compatibility issues with specific hardware configurations. Many hosting providers standardize on LTS kernels specifically because they balance modern features with proven stability.
Your kernel choice also affects what virtualization technologies you can use. Features like KVM require specific kernel support, and different hypervisor technologies have different kernel requirements and performance characteristics.
Container technologies like Docker depend heavily on kernel features like cgroups and namespaces. Older kernels might not support the latest container features or might implement them less efficiently than newer versions.
Most users never need to compile their own kernel since distribution kernels work fine for typical use cases. However, custom compilation lets you optimize for specific hardware, enable experimental features, or strip out unnecessary components.
Building a custom kernel starts with downloading the source code from kernel.org and configuring which features to include. The configuration process involves selecting drivers, file systems, networking options, and hundreds of other parameters.
Compilation takes anywhere from a few minutes to several hours depending on your hardware and how many features you're including. Once built, you install the new kernel and update your bootloader configuration to make it available at startup.
Be careful when experimenting with custom kernels on production systems. Always keep a working kernel as a backup option in your bootloader menu. If your custom kernel fails to boot or causes problems, you can select the previous kernel from the boot menu to recover.
The Linux kernel sits at the heart of every Linux system, managing hardware resources and providing the foundation that everything else builds on. Understanding how it works helps you make informed decisions about system configuration, troubleshooting, and performance optimization.
Whether you're running a personal project or managing production infrastructure, the kernel version and configuration you choose affects stability, security, and performance. Most of the time, sticking with your distribution's default kernel is the right move, but knowing when and how to customize gives you flexibility when you need it.
If you're looking for infrastructure where the Linux kernel can truly shine, xTom provides enterprise-grade dedicated servers and colocation services, while V.PS offers scalable, production-ready NVMe-powered VPS hosting perfect for any Linux workload. We also offer IP transit, shared hosting, and general IT services tailored to your needs.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
The kernel is just the core component that manages hardware and system resources. A complete Linux operating system includes the kernel plus additional software like system utilities, libraries, a shell, and applications. When people say "Linux," they often mean the entire operating system, but technically Linux is just the kernel itself.
No, Linux applications depend on the Linux kernel's system calls and interfaces. However, Windows Subsystem for Linux (WSL) provides a compatibility layer that translates Linux system calls to Windows equivalents. For native performance and full compatibility, you need an actual Linux kernel running.
For security updates and critical bug fixes, apply them as soon as they're available through your distribution's package manager. For major version upgrades, consider your stability requirements. Production servers often stick with LTS kernels and only upgrade when changing distribution versions, while desktop users might update more frequently for hardware support and new features.
A kernel panic occurs when the kernel encounters an error it can't recover from. The system halts to prevent data corruption or further damage. After a panic, you'll need to reboot the system. Examining kernel logs after reboot can help identify the cause, which might be faulty hardware, driver issues, or filesystem corruption.
Yes, kernel updates require a reboot to take effect since the kernel loads during the boot process and runs continuously afterward. Some technologies like kexec and live patching can apply certain updates without rebooting, but these are mainly used in scenarios where downtime must be absolutely minimized. For most systems, a scheduled reboot is the standard approach.
]]>