If your team is asking which gateway works with ChirpStack, the short answer is broader than many buyers expect. ChirpStack is designed to work with standard LoRaWAN gateways that support packet forwarding to the network server, so the real question is not whether a gateway is compatible in principle. It is whether that gateway fits your deployment model, frequency plan, backhaul requirements, and operational expectations.
That distinction matters. A gateway can be technically compatible and still be the wrong choice for a smart utility rollout, an industrial site with poor cellular coverage, or a municipal network that needs remote management at scale. For most organizations, gateway selection is less about basic interoperability and more about choosing infrastructure that will hold up under real deployment conditions.
Which gateway works with ChirpStack in practice?
In practice, ChirpStack works with a wide range of LoRaWAN gateways from established manufacturers, including indoor and outdoor models, provided they support the expected packet forwarder or gateway bridge path used in a ChirpStack deployment. Many gateways from vendors such as Kerlink, Milesight, and RAKWireless are commonly used in ChirpStack-based networks.
What buyers need to evaluate is the gateway's operating mode and how it connects upstream. Some gateways are easy to provision for a private network and offer straightforward integration with ChirpStack. Others may be sold with assumptions around a bundled cloud environment, or they may need additional configuration to point traffic to your own server stack. That does not make them incompatible, but it can change the amount of engineering effort required.
The safest approach is to treat ChirpStack compatibility as a baseline and then assess the gateway as a piece of field infrastructure. Receiver sensitivity, channel support, enclosure rating, power options, and remote administration will often have more impact on project success than the simple question of protocol support.
What ChirpStack needs from a gateway
ChirpStack does not require a proprietary gateway ecosystem. It works with standard LoRaWAN packet forwarders and common gateway interfaces, which gives infrastructure buyers flexibility. In a private network architecture, the gateway forwards LoRa packets to the ChirpStack services over IP, usually via Ethernet, Wi-Fi, LTE, or another WAN backhaul.
That means the gateway should be evaluated for a few practical factors. First, it must support the correct regional frequency plan for the US or Canada, typically US915 in many North American deployments. Second, it should allow configuration of the packet forwarder destination so it can send traffic to your ChirpStack environment. Third, the gateway should provide the level of fleet management your team needs, whether that is local access for a single site or centralized remote management for dozens of locations.
There is also a difference between support on paper and support in production. A low-cost gateway may connect to ChirpStack without issue in a lab. But if firmware maintenance is inconsistent, logging is limited, or backhaul stability is weak, troubleshooting can become expensive once devices are in the field.
Indoor vs outdoor gateways for ChirpStack
This is where gateway choice becomes specific.
Indoor gateways are often a good fit for pilot projects, office buildings, light industrial spaces, and sites where antenna placement and cable runs are manageable. They are usually faster to deploy, easier to power, and lower in upfront cost. For development teams building a proof of concept around ChirpStack, an indoor gateway can be the right starting point.
Outdoor gateways make more sense when coverage, durability, and installation flexibility matter more than initial simplicity. Smart city deployments, tank monitoring, district metering, campus coverage, and distributed industrial sites typically benefit from an outdoor unit with proper ingress protection, external antenna options, and support for pole or wall mounting. In those environments, using a basic indoor gateway just because it works with ChirpStack is often a false economy.
The trade-off is straightforward. Indoor models reduce setup complexity. Outdoor models usually improve RF performance and long-term reliability when the network needs to scale.
Manufacturer fit matters more than many teams expect
When evaluating which gateway works with ChirpStack, manufacturer choice is really about deployment confidence.
Kerlink gateways are often considered for enterprise and carrier-grade environments where hardened outdoor performance, remote operations, and long service life are priorities. They are well suited for municipalities, utilities, and industrial operators that need infrastructure built for continuous field use.
Milesight gateways are commonly selected when buyers want a strong balance of commercial-grade performance, straightforward management, and flexible indoor or outdoor options. They are a practical fit for many private LoRaWAN deployments using ChirpStack, especially where teams want dependable hardware without overcomplicating deployment.
RAKWireless gateways are frequently used in developer, integrator, and cost-sensitive deployments where flexibility is important. Depending on the model, they can be a strong choice for pilots, smaller private networks, or applications where customization and accessible configuration matter.
None of these categories is absolute. The point is that the gateway brand often signals the expected operating environment, support model, and management experience. For a production ChirpStack network, those differences are worth weighing early.
Common compatibility mistakes
The biggest mistake is focusing only on whether a gateway can forward packets to ChirpStack. That is necessary, but it is not enough.
A common issue in North America is buying the wrong frequency variant. A gateway designed for another region will not be appropriate for US915 operation, regardless of how well it supports ChirpStack. Another problem is underestimating antenna and installation design. Teams sometimes blame the network server when the real issue is poor gateway placement, excessive coax loss, or an antenna chosen without regard to the site.
There is also the matter of backhaul. A gateway at a remote water site, agricultural location, or utility asset may need LTE with reliable failover behavior and careful data planning. If your ChirpStack deployment depends on gateways in hard-to-reach places, the quality of the WAN connection and remote management tools becomes part of compatibility in a practical sense.
Finally, some buyers choose gateways that are inexpensive but operationally limited. If firmware updates are cumbersome, diagnostics are thin, or vendor documentation is weak, every field issue takes longer to resolve. That cost shows up after purchase, not before.
How to choose the right gateway for a ChirpStack deployment
Start with the network design, not the gateway catalog. Define the region, coverage objective, installation environment, power availability, and backhaul method. Then look at whether the gateway supports a clean path into ChirpStack and whether your team can manage it at the scale you expect.
If you are building a pilot or a single-site proof of concept, a simpler indoor gateway may be enough, provided it uses the correct band plan and supports the forwarding method your ChirpStack instance expects. If you are planning a multi-site rollout, especially outdoors, you should prioritize industrial-grade hardware, remote fleet visibility, and vendor consistency.
It also helps to think one phase ahead. Many networks begin with a few gateways and a limited device count, then expand quickly once the business case is proven. A gateway that works with ChirpStack today but lacks enterprise management features may create friction later. Replacing infrastructure after device onboarding is rarely ideal.
For that reason, organizations often benefit from working with a specialist that understands not just gateway specifications, but how those specifications affect deployment outcomes. LoRaWorld focuses on that layer of decision-making, where compatibility is only one part of the infrastructure question.
So, which gateway works with ChirpStack?
The practical answer is this: many standard LoRaWAN gateways work with ChirpStack, but the right gateway depends on your operating environment and the level of reliability you need. For an indoor lab, many options will do the job. For a citywide network, utility field deployment, or industrial site, the shortlist should narrow quickly to proven hardware with strong management and support.
That is why experienced buyers do not stop at compatibility charts. They look at field conditions, lifecycle management, and how the gateway will perform once the network moves beyond testing. If your ChirpStack deployment is expected to support real operations, choose the gateway the same way you would choose any other critical infrastructure - with the production environment in mind from day one.
A good gateway does more than connect to ChirpStack. It gives your network room to grow without turning every expansion step into a redesign.