The Halo Journal

Designing an API that scales to a million captive portals

Mon, 07 Sep 2026 00:00:00 GMT

A phone joins a network it cannot use yet, opens a strange little browser, and asks us who it needs to be. That happened more than seven million times in the last twelve months, across four continents, against the five regions of Halo Cloud, and every one of those moments lives in a genuinely odd corner of distributed systems: the captive portal, where the assumptions that underpin normal web API design fail one by one.

Seven of them, by our count. This post walks through each in the order a guest meets them, and it ends where those failures eventually pushed us: writing our own captive portal engine, HaloChilli, because the open-source one the whole industry starts on could not survive the seventh.

The constraint that shapes everything: we are the cloud

One piece of context first, because it explains why we meet these assumptions harder than most. The typical WiFi vendor serves the captive portal from a box in the venue's rack: an on-premise controller that hosts the splash page, terminates the login, runs DHCP, and anchors the session. The portal is a LAN hop from the guest. Latency is a rounding error and scale is bounded by the size of the building.

We made the opposite bet. HaloWiFi is a cloud-managed platform, which means the portal loads from our cloud and the authentication decision, RADIUS, is answered from our cloud too. There is no controller in the rack, on purpose; the reasons live under assumption seven. The consequence is that every design question becomes a latency-and-reliability question. A guest in Kampala or Toronto is not talking to hardware ten metres away; they are talking to infrastructure we run. So we run it close, five regions, guests routed to the nearest, and that flattens the geography. The seven assumptions are what remains.

Assumption one: the client is a browser

It is not. The captive portal's client is the OS's captive network assistant, the mini-browser iOS and Android summon when their connectivity probes fail. It is a hostile runtime: stripped-down, impatient, without the persistence guarantees of a real browser, liable to be dismissed by the user with one swipe, and quick to conclude that the network is broken and give up on the guest's behalf.

And everything it does, it does on a network that is, by design, not working.

Assumption two: the network underneath you works

Ours deliberately does not. The guest is pre-authentication, inside a walled garden that permits exactly one conversation: the one with the portal. Underneath that sits congested venue RF, the worst network path the guest will use all day. Every request you add to the login flow crosses that path, inside a browser that is looking for an excuse to leave.

The design conclusion is blunt, and it governs everything downstream: the number of network round trips between "phone joins SSID" and "guest is online" is the metric. Everything else in this post serves it.

The reflexive first move, then, is to get the heavy static assets close to the guest. Push it all to a CDN. Which runs straight into the next broken assumption.

Assumption three: static assets are the CDN's problem

For a captive portal they cannot be, and understanding why explains half of our serving architecture.

The walled garden is a firewall allowlist on the access device: pre-auth guests can reach the portal's endpoints and nothing else. Modern CDNs are close to un-allowlistable. Their edges live on vast, rotating IP ranges; their certificates and IPs are shared across thousands of co-tenants; the "location" of an asset is deliberately fluid. You can chase their published ranges, but then your garden gate is only as stable as someone else's network topology. And it is worse than fragile: allowlisting a shared CDN edge quietly allowlists everything else served from it. A pre-auth guest who can reach a whole CDN has a tunnel out of your garden, and free-riders have been exploiting exactly that hole in poorly built portals for years.

So we serve every byte of the portal ourselves, from our own regional origins, on a small, stable, allowlistable set of endpoints that the access hardware and the cloud agree on. That decision costs us the world's edge caches, which means we get our performance the older way: by shipping almost nothing. Assets are trimmed to what the theme actually needs and the payload is treated like it is 2005 and every kilobyte is billed. When you cannot lean on somebody's edge, weight is architecture.

A light page still has to talk to an API, though. So the next thing we rationed was the talking.

Assumption four: round trips are cheap

On this path they are the most expensive thing there is, so the API design follows: ask once, receive everything, work locally.

When a portal instance loads, it makes a single bootstrap request, and the response carries as much as the flow could plausibly need: venue identity and theming, the enabled login methods and their parameters, policy the flow must respect, localisation, and the state of this particular client's journey so far. From there the flow runs client-side. Screen transitions, validation, method selection, all of it happens without touching the network again. The network is bothered when something real happens: credentials submitted, a code redeemed.

The same principle killed multi-step logins in our defaults. Every additional step in a portal flow is not just UX friction; it is another opportunity for the mini-browser to time out or the user to swipe away. The default flows are engineered to be one honest interaction long.

Which holds beautifully, right up until the code running that interaction is not ours.

Assumption five: the code calling your API is yours

Frequently, it is not. We do not force our portal flows on anyone: venues and partners can build fully custom login experiences against our engine, their brand, their steps, their logic, and they do, elaborately. Which means the most latency-critical screen in our system regularly runs code we did not write, by developers who have not read the guidelines, because nobody reads the guidelines.

You cannot fix that with documentation. You fix it with the shape of the handover. Before custom code takes over, the engine hands it a complete, structured context: everything the bootstrap knows, already validated, already typed, already localised, the client's state machine position included. The custom flow starts life holding everything it needs, so its most common mistakes, re-fetching what it already has, guessing at state, improvising extra chatter, are mistakes it never gets pushed toward. The pit of success is carved so that lazy code lands in it.

We think of it as designing for the API consumer's worst day, not their best one. The integrations that make us proudest are the ones that misbehave gracefully. But however well anyone's flow behaves, ours or theirs, none of it is real until RADIUS says so.

Assumption six: the client can wait while you do the bookkeeping

Not at the gate, it cannot. The access device asks our cloud "may this client pass," and the Access-Accept that comes back is the moment the walled garden opens. That request is the most latency-sensitive packet in the entire platform, and our rule for it is: the authorization decision must be cheap, and everything expensive must be somewhere else.

The RADIUS fast path does the minimum work to answer the only question that matters, against state that is already prepared for it. Session records, accounting, analytics, the bookkeeping that makes dashboards useful, all of that is decoupled and can land a few hundred milliseconds later without any guest noticing, because the NAS holds the client's session state locally the moment access is granted. The cloud closes the loop; it does not sit in the data path. A design that makes a guest wait on a database write it did not need to wait on has its priorities inverted.

Granting access this way leaves the session state living on the access device that granted it. Which raises the question that ended up reshaping our whole product: what happens to that state when the guest walks?

Assumption seven: the session lives somewhere

At single-AP scale, it does, and nothing above is remarkable. The problems arrive with size: a resort, a campus, a venue with dozens of access points, where a guest authenticates once at reception and then moves.

The industry's standard answer is the on-premise controller. It anchors the guest session, often runs DHCP, and because every AP hangs off it, roaming is "solved" by centralising everything through one box. It is also an extra cost the customer pays before the first guest connects, a sizing decision made on day one that the deployment will outgrow, and a single point of failure sitting in a closet. We refused to build our architecture around selling one.

The alternative we chose is solution architecture over hardware: let the fleet itself carry the knowledge. Every Halo device, APs, cloud switches, shares authorized-client state with its peers. When a guest who authenticated at the lobby AP appears at the pool AP, that device already knows this client is authorized and admits them automatically. No portal re-splash, no second login, no detour to anywhere before the guest's music resumes. The session follows the human, and adding the fortieth AP is the same operation as adding the fourth. Easier life for the customer, considerably more complicated engineering for us, which is the correct direction for that trade to flow.

This is the assumption that broke our tooling. We started, like almost everyone in this space, on CoovaChilli, the venerable open-source captive portal daemon, and it served us well right up to this wall. Its worldview is fundamentally single-device: one NAS, holding its own sessions, making its own decisions. Distributed authorized-state, the thing our roaming model runs on, is not a feature you bolt onto that worldview; it is a different worldview. So we wrote HaloChilli, our own captive portal engine, built from the first line around state that is shared, synchronised, and fast to consult on the access device itself. The name keeps the lineage; the architecture does not.

What a million means

"A million captive portals" is not one load test; it is the same guest-shaped problem repeated across thousands of venues in different countries, on different regulations, with different login flows, hitting whichever of our five regions is nearest, frequently all at once, because events synchronise humans and humans synchronise load. The architecture above is what makes that shape survivable: serve everything yourself so the garden stays sealed, ask the network for as little as possible, keep other people's code well-fed and off the hot path, answer the gate question instantly and do the bookkeeping later, and let the fleet share the state a controller would have hoarded.

None of it is exotic. All of it is the accumulated residue of watching real guests connect on four continents and being unwilling to make any of them wait. If you are building against our platform, the API docs show what the bootstrap hands you. If you are evaluating us, this post is the level of thinking underneath every feature we ship. And if you just run venues: book a demo, and the next phone that joins and asks who it needs to be will get its answer before it finishes asking.

Live Event WiFi Deployment: The Field Guide

Mon, 07 Sep 2026 00:00:00 GMT

Event WiFi has a reputation problem, and it earned it honestly. Most of us have stood in a conference hall watching a spinner, surrounded by two thousand people doing the same. The physics of that room are hard, but they are not mysterious. Almost every event network that falls over falls over for one of a handful of predictable reasons, and every one of them is avoidable at the planning table, days before the first flight case rolls off the truck.

This guide is the deployment playbook we wish someone had handed us years ago. It is written for the people who actually build these networks: AV and IT contractors, venue technical teams, and the unlucky organiser who just found out that "the WiFi" is now their job. It is hardware-agnostic. Everything in it can be done with any serious equipment, by hand, if you have the time. Where we give numbers, they are opinionated on purpose. Hedge-everything guides do not help anyone at midnight before a load-in.

The short version

If you read nothing else, deploy against these rules:

Plan for 70 to 80 percent of headcount connected at peak for conferences and expos, 40 to 60 percent for concerts and social events.
Budget 2 to 4 Mbps per guest. Airtime, not raw bandwidth, is your real constraint.
Plan around 60 to 100 active clients per radio. Ignore the association limit on the datasheet.
More small cells at low power beats fewer loud APs. Spread the client load across devices.
5GHz carries the event. 6GHz is your cleanest spectrum where clients support it, but plan for its shorter reach.
Stay on narrower channels in dense zones. You care about many users connecting reliably, not one user's speed test.
Press, production and payments need priority, not just separation. A VLAN alone does not protect them.
Roaming quality decides the guest experience. A network that cannot hand clients off cleanly is a network that does not work, whatever the throughput numbers say.
Preload the captive portal before doors open and size DHCP at twice your expected peak.
Teardown is part of the deployment, not what happens after it.

The rest of this guide walks the event timeline: plan, stage, install, doors open, show time, teardown.

Plan: do the capacity math

Every failed event network we have seen was under-planned, not under-specced. The math takes twenty minutes and it decides everything downstream: AP count, placement, channel plan, backhaul contract.

How many people will actually connect

Attendees are not clients. The take rate depends on the event:

Conferences, expos, trade shows: 70 to 80 percent of headcount at peak. These crowds are working. Laptops, phones and often a tablet per person, and they arrive expecting to upload, demo and video-call.
Concerts, weddings, social events: 40 to 60 percent. People are there for the event, not the internet, but the spikes are sharper: doors, intermission, the headline moment when ten thousand phones start uploading video simultaneously.

Err on the high side. At any large gathering the cellular network degrades as towers saturate, which pushes people onto your WiFi precisely when it is busiest. Your network inherits the carriers' failure.

Each connected person also brings more than one radio. Count 1.2 to 1.5 devices per connected attendee at a working event once laptops and wearables join.

How much per client

2 to 4 Mbps per general guest covers messaging, social, uploads and standard-definition streaming comfortably. Resist the urge to promise more. The constraint in a dense room is not the pipe, it is airtime: every transmission occupies the channel for everyone on it, and a handful of clients pulling 50 Mbps can starve a hundred clients trying to load a boarding pass. Per-client rate limiting is not stinginess, it is fairness enforcement, and it is the single most effective quality lever you have.

Clients per radio

Datasheets love to advertise 200+, sometimes 500+, associated clients per access point. Association is not service. The most misleading number in event WiFi is the association limit, because an AP can hold hundreds of idle associations while delivering usable service to a fraction of them.

Plan around 60 to 100 active clients per radio, and use the lower end of that range for zones where clients are doing real work (a press pit, a demo floor) and the higher end for zones where most traffic is light and bursty.

A worked example: 2,000-person expo

Input	Value
Headcount	2,000
Expected peak take rate	75% → 1,500 people
Devices per connected person	1.3 → ~1,950 clients
Per-client budget	3 Mbps
Planning load per radio	80 clients
Radios required	~25
Dual-band/tri-band APs required	14 to 18, placed by zone

Zone it rather than averaging it. The entry hall takes the association storm at doors. The main floor holds the sustained load. The food court peaks at lunch, the keynote room peaks twice a day and is empty otherwise. An even grid of APs is a plan for an even crowd, and there is no such thing.

Backhaul sizing falls out of the same numbers, with one mercy: not everyone transmits at once. A 10:1 to 20:1 oversubscription against the theoretical sum is normal. For this expo, 300 to 500 Mbps of real, tested backhaul is a sane target. (Provisioning the backhaul itself is out of scope for this guide; we are assuming you have a line, bonded cellular, or fibre already arranged.)

How this changes by event type

The framework holds everywhere; the numbers and the failure modes move. What to expect:

Event type	Take rate	Spike shape	Dominant zone	Hardest problem
Expo / trade show	70 to 80%	Doors surge, then sustained all day	Demo floor	Exhibitor and press uplink surviving guest load
Conference	70 to 80%	Synchronised: every break moves everyone at once	Keynote hall	Roaming as rooms empty and refill in minutes
Concert / festival	40 to 60%	Extreme bursts: doors, intermission, encore	Pit and GA front	Association storms plus a wall of body attenuation
Wedding / social	40 to 60%	Photo moments and speeches	One room	Photographer and vendor priority on a modest pipe

Read your event's row, then apply the rest of the guide with those numbers in hand.

Plan: placement and the empty-venue lie

Two principles carry almost every placement decision.

More small cells at low power beats fewer loud APs. It is tempting to cover a hall with four APs at full transmit power. Coverage will look perfect on the survey. Then the room fills, all four radios saturate, and there is nowhere for the load to go. Many APs at low power (10 to 14 dBm, roughly matching a phone's transmit power) create small cells that spread the client load across many radios, which is the entire game. A client five metres from a quiet AP gets better service than a client thirty metres from a loud, drowning one.

The empty venue lies to you. A human body is 3 to 5 dB of attenuation at these frequencies; a crowd is a wall of water. The pristine coverage map you measured on Wednesday afternoon does not exist on Saturday night. Mount APs overhead wherever rigging allows, so signals travel over the crowd instead of through it. Tripod-mounted APs at head height are a last resort; they serve the ten people standing nearest and lose everyone behind them.

Overhead has a ceiling, literally. Expo halls and arenas often put the rigging at 10 metres or more, and every metre of height is distance you have inserted between the AP and every client it serves. The trap is that the failure is asymmetric: the AP transmits with decent power through a decent antenna, but the phone answers with a fraction of that through a terrible antenna held against a body. A high-mounted network surveys beautifully, because a survey measures the downlink, and then collapses under load as uplink retries pile up. So the placement ladder is:

3 to 6 metres is the sweet spot: trussing, poles, columns, booth structures. Above the crowd, still within reach of a phone's weak uplink. At an expo, booth builds and pipe-and-drape rigs give you this for free if you claim the positions early.
If the ceiling is all you get, change the antenna, not the strategy. Directional patch or narrow-beam antennas aimed down claw back the path loss with gain, and their tight footprint recreates the small, defined cells that height otherwise destroys. This is how arenas do it.
What you never do is hang omnidirectional APs at 10-plus metres. An omni at height creates one giant, sloppy cell that hears clients from three zones away, which undoes the entire small-cell plan in a single mounting decision.

Survey with the staging in place if you possibly can. LED walls, metal trussing and scaffolding reshape propagation, and they usually arrive after the site visit.

Stage: configure in the warehouse, not the venue

The venue gives you hours; the warehouse gives you days. Every minute of on-site configuration is a minute stolen from the things you can only do on site: physical placement, cable runs, and verification.

Before the truck leaves:

Every AP configured, named by zone, firmware-matched and labelled to match the floor plan.
SSIDs, VLANs, rate limits and RADIUS/portal settings applied and tested against a bench setup.
A printed (yes, printed) floor plan with AP positions, channel assignments and switch port mapping. Venues eat laptop batteries and cellular coverage.
Spares: at least 10 percent extra APs, pre-configured as hot swaps, plus the cables, injectors and mounts to deploy them.

The install-day test is simple: if a box can be plugged in by someone who has never seen the configuration, staging was done right.

Install: RF settings that survive a crowd

The dense-venue RF playbook is short and unglamorous, and skipping any line of it is how networks die at 2pm on day one.

5GHz carries the event. It has the channels, the client support and the capacity. Design as if it is the only band, then treat everything else as auxiliary.

Deploy 6GHz where you can. WiFi 6E and WiFi 7 clients now make up a meaningful share of any professional crowd, and 6GHz is the cleanest spectrum at any event: no legacy devices, no hotspot pollution, wide open channels. Its physics cut both ways, though. 6GHz propagates noticeably shorter range than 5GHz and gives up more to obstruction, so it is not a drop-in replacement: plan tighter cell spacing for it, or treat it as a capacity layer in your densest zones (press areas, demo floors) rather than a coverage layer. Offloading the newest, most capable clients onto 6GHz also quietly relieves 5GHz for everyone else. One interaction to respect: 6GHz is the most height-sensitive band of the three, so it pays the high-ceiling penalty hardest. If your only mounting option is up high, 6GHz needs the directional-antenna treatment even more than 5GHz does.

2.4GHz is either off or quarantined. At an event it is a war zone of personal hotspots, Bluetooth and wireless production gear. If legacy devices or payment terminals need it, give it a dedicated SSID at minimum power and keep guests off it.

Stay narrow on channel width. 20MHz channels in dense zones is our default, 40MHz where density is moderate. Wide channels buy individual throughput at the cost of channel reuse, and at an event you care much less about each user's throughput than about the number of users the room can hold cleanly. This one is genuinely subjective, and if your event is a small workshop where forty people need fast transfers, go wide. In a dense hall, go narrow and take the reuse.

Kill the legacy floor. Disable 802.11b rates and set the minimum basic rate to 12 or 24 Mbps. Slow clients transmit for longer, and airtime is the shared resource; one 1 Mbps client at the edge of a cell degrades the channel for everyone on it. Set a minimum RSSI so clients are nudged to a nearer AP instead of clinging to a distant one.

Cap the SSID count. Every SSID beacons on every radio, and beacons are pure overhead. Three to four SSIDs per radio is a sane ceiling; each additional one taxes every client in range whether they use it or not.

Install: segmentation, and why a VLAN is not enough

An event network is at least four networks wearing one set of hardware:

Guest: isolated client-to-client, rate-limited, internet-only.
Production: show control, streaming encoders, AV. Never shares airtime priority with guests.
Press and photographers: their uploads are the event's public record, on deadline.
Payments and POS: small traffic, zero tolerance for failure.

VLAN separation is the obvious first step, and it is not sufficient. A VLAN gives press their own broadcast domain and address space, but at the radio and the uplink they are still queuing behind two thousand guests. Separation without prioritisation just means their traffic fails on its own dedicated network.

The classes that matter need actual QoS: WMM priority at the radio, queue priority at the switch and gateway, and bandwidth reservations that hold under guest saturation. The test is brutal and simple: at absolute peak guest load, can a photographer push a 2GB card to an editor, and does a card machine complete a transaction on the first try? If the answer depends on how busy the guests are, the segmentation is decorative.

Where the venue allows it, put press and production on their own radios or their own band entirely (this is a natural use of that 6GHz capacity layer). Airtime you never contend for is the only airtime you can promise.

Doors open: surviving the surge

Guests forgive a queue at the bar; they never forgive a login page that will not load. The first ten minutes after doors are the network's real stress test, and it is not a bandwidth test, it is an onboarding test.

DHCP first. Size the pool at twice your expected peak associations, with leases of 30 to 60 minutes. Gate churn, people connecting, wandering out for a call, reconnecting, exhausts tight pools fast, and DHCP exhaustion presents as "the WiFi is broken" while every dashboard shows green.

The captive portal is the perceived quality of the entire network. Whatever the backend, the splash page must be paint-fast and lightweight, and it must be warm before the first guest arrives, not compiling itself when the first phone connects. If the portal stack has a cold-start behaviour, trigger it yourself before doors. Keep the page under a couple of hundred kilobytes, host its assets locally or on fast edge infrastructure, and make the auth flow survive a thousand submissions in a ten-minute window. A beautiful portal that takes eight seconds to render has already told every guest the network is broken, regardless of what the network can actually do.

Watch the walk-in on a live view. Association counts per AP during the first thirty minutes tell you immediately whether the load is spreading the way the plan said it would, and doors-open is when a mis-aimed antenna or a dead switch port announces itself.

Show time: roaming is the whole ballgame

Here is the uncomfortable truth about dense-venue WiFi: you can get every setting above right and still deliver a miserable experience if roaming is broken. Event guests move constantly, between halls, to the food court, back for the keynote, and every one of those walks is a series of handoffs between access points.

The failure mode is the sticky client: a phone that associated at the entrance and clings to that AP from across the building, hammering out retries at the lowest rates, degrading its own experience and burning airtime for everyone still near the door. Multiply by a few hundred and a well-designed network performs like a broken one.

Well-implemented roaming is paramount, and it is a system property, not a checkbox:

802.11k and 802.11v on, always. Neighbour reports and BSS transition steering give clients the information and the nudge to move to the right AP before they degrade.
802.11r (fast transition) is worth it, tested. It cuts re-authentication during handoff to near-imperceptible, which matters enormously on portal- or RADIUS-authenticated networks. But it still confuses some older clients, so test with the oldest devices you realistically expect in the crowd before you commit.
Minimum RSSI and band steering do the pushing where clients will not listen: shed clients that have drifted too far, and lift capable clients up to 5 and 6GHz.
Consistent everything. Same SSID, same security, same VLANs everywhere the client roams. Any inconsistency between APs turns a 50-millisecond handoff into a full reconnect through DHCP and the portal, in the middle of someone's video call.

Walk the floor during the event with a phone and watch it hand off. If you can cross the venue on a video call without a stutter, the network is doing the hardest thing it will be asked to do.

Show time: operating from the floor

Nobody at a live event is sitting at a NOC. Whoever is watching the network is doing it from a phone, standing behind a stage, mid-conversation with a stressed producer. Plan the observability accordingly:

One live view: active clients, per-AP load, uplink utilisation. Big numbers, glanceable.
Alerts pushed, not polled: an AP going dark should find you; you should not be refreshing dashboards to find it.
The mid-event fixes worth knowing by heart: swap a failed AP for a pre-configured spare, drop transmit power in a zone where cells are colliding, tighten guest rate limits when the uplink runs hot, and steer around a saturated zone by nudging minimum RSSI. Every one of these is a two-minute change if it was staged, and a truck roll if it was not.

Teardown: end it like you mean it

The event ends; the network's obligations do not, unless you end them deliberately. Teardown is a feature of the deployment, not a footnote:

Access codes and portal sessions expire when the event does. Nothing left open, nothing to remember to close.
Guest data has a retention story. A pop-up network should keep data for days, not quietly forever, and whatever the organiser needs (attendance, portal analytics, sponsor reporting) should be exported and delivered as a wrap-up report before the data ages out.
Hardware comes back tested and reset, and the event's configuration is archived, because the fastest way to plan the next event is to clone the last one.

The next event deserves a clean slate, and so does this one's data.

Doing all of this without doing all of this

Everything in this guide can be built by hand, and for years that is exactly how we did it. It is also exactly why we built Live Events into Halo Cloud: an event becomes an object with a start and an end, any device you plug in on site finds its event and configures itself, the portal is themed once and preloaded before doors, the live capacity view is designed for a phone held in one hand behind a stage, and when the event ends the teardown, code expiry and wrap-up report happen on their own. If you would rather spend load-in day on placement and cable runs instead of configuration, that is what it is for. And if you are running an event soon, book a demo and we will spin up a pop-up network live on the call.

Opening our API, or: how we learned to stop worrying and love other people's code

Mon, 07 Sep 2026 00:00:00 GMT

Every platform team has the meeting. Someone proposes opening the API, properly opening it, documented, supported, for anyone to build on, and the room fills with reasons to wait. We had that meeting, and we had exactly two fears worth taking seriously. Both turned out to be wrong, and both were wrong in ways that taught us more than being right would have. This is the field log.

Fear one: the API is safer hidden

The argument felt responsible at the time: the API existed for our own portal and apps, nobody else knew its shape, and keeping it that way was a form of protection. Publishing documentation felt like publishing a map.

Here is what that fear actually was, once we looked at it honestly: hope, dressed up as a security posture. Hiding an endpoint is not a security layer; it is a security delay. Anyone who can join a network and open a developer console can watch our own portal talk to our own API, which means the map was already published to anyone curious enough to look. Security that depends on people not finding your endpoints is not architecture. It is optimism with a firewall.

The uncomfortable admission is that the fear was doing a job for us: it let us defer work the architecture owed regardless. We always had a real authentication layer, that was never the gap. The gap was the worldview behind it: the API had been designed for one trusted consumer, us. Auth built for a single, well-behaved, first-party caller quietly leans on the caller's good behaviour, and the API's privacy gets counted as part of the security story even though it was never a load-bearing part.

Deciding to open the API meant deciding that every caller is untrusted, and rebuilding the model around that assumption: the same gates, the same limits, the same isolation for every caller, no matter whose name is on the request.

And here is the part we did not expect, and the reason this post exists: once we made the decision, the work was not the mountain the fear had promised. The dread was expensive; the engineering was not. The fear had been costing us more than the fix.

The lasting consequence is the principle we now hold hardest: we are zero trust for ourselves, exactly as we are for every customer. Our own portal, our own apps, our own dashboards are just API consumers. No privileged backdoors, no internal-only side doors that partners cannot see. We eat at the same table we serve, which means every improvement the public API earns, first-party inherits, and every claim we make about the API's security is a claim we stake our own product on. That is a far stronger security statement than obscurity ever was, and it is checkable, which obscurity never was.

Fear two: we will lose control of the experience

This one wore better clothes. It sounded like product craft: we have opinions about how guest WiFi should feel, we sweat the flows, and handing partners an API means handing them the ability to build something worse and put our engine behind it.

With some distance, we can name that fear for what it was: myopic, and more than a little self-aggrandising. "Protecting the experience" assumed we had already imagined every experience worth having, that the ceiling of the product was the ceiling of our own imagination. A platform whose experiences are bounded by its makers' foresight is not a controlled product; it is a small one.

The evidence against the fear was not long in coming. We wrote in the previous engineering post about partners building fully custom login flows against our engine, their brand, their steps, their logic, and doing it elaborately. Those flows are not degraded versions of what we would have built. Many of them are things we would never have prioritised, for markets and workflows we were not staring at, and some of them taught us what the platform actually was. The moments that changed our minds were the integrations we could not have specified, because we did not know enough to specify them.

Then partners went further than flows. Linkbase, who run guest WiFi for short-term rentals in Canada, built a full API integration: they and their property clients manage every one of their networks from Linkbase's own dashboard, inside the web app where the rest of their rental operation already lives. The experience we were so worried about protecting? For their vertical, they replaced it wholesale, and theirs is the right one, because a host managing a rental at 11pm wants one pane of glass, not two. Cloud-Fi, our partner in Uganda, went a different direction entirely: an Android app they hand to their own customers, who use it to manage venues and watch revenue collection and disbursement, an operating business with money moving through it, built on top of us. We did not design either of those experiences. We could not have. One replaced our interface and the other turned our platform into the plumbing of someone else's product, and both are better arguments for the API than anything we shipped ourselves.

Control, it turns out, was never the valuable thing. The valuable thing was the floor: making the worst integration a partner can build still safe, still fast, still respectful of the guest. So that is where our opinions went. Instead of gatekeeping the experience, we engineered its minimums: the one-shot bootstrap that hands custom code everything it needs before it can improvise, the structured context that makes the lazy path and the correct path the same path, the guardrails that hold when the guidelines go unread. We stopped trying to be the author of every experience and became the physics of all of them. Physics scales better than authorship.

What the bomb turned out to be

The Strangelove joke in the title is only half a joke. The bomb, the thing we feared and learned to love, is other people's code running against our platform, permanently, at the most latency-critical moments we have. It is still slightly terrifying, and it should be; healthy platforms stay a little afraid of their consumers.

But the ledger is not close. Fear one, faced, made the platform safer than hiding ever could, and made us our own strictest customer. Fear two, faced, made the platform bigger than our roadmap, and turned partners into a source of product direction we could not have hired. The API is open, the fears were mirrors, and the only regret is the time we spent in the meeting.

If you want to see what the platform hands your code before you write a line of it, the API docs are where we would start. Build something we did not imagine. At this point, we are counting on it.

Extending guest WiFi with a third-party extender

Thu, 13 Aug 2026 00:00:00 GMT

A third-party extender can stretch your guest network into the rooms your HaloWiFi AP can't reach — with every client still behind the captive portal. The setup is three settings on the extender; the failures are always the same three mistakes. This guide covers both, plus which devices actually work.

The short version: put the extender in AP/bridge mode, match the Guest SSID exactly (open, no password), and make sure the extender never runs DHCP or NAT. Do that, and a client behind the extender is indistinguishable from a client on the main AP — same DHCP lease, same portal login, same session tracking.

How it works

The extender is a dumb radio. It rebroadcasts the Guest SSID and bridges every frame back to the HaloWiFi LAN — no routing, no NAT, no DHCP of its own. Everything that makes guest WiFi guest WiFi stays on the HaloWiFi router, unchanged: DHCP address assignment, captive-portal interception (HaloChilli), RADIUS authentication, session tracking, bandwidth quotas and analytics. The extender is invisible to the portal logic.

Backhaul matters more than brand. Run an Ethernet cable from the extender to any LAN port on the HaloWiFi router or a downstream switch. Wireless backhaul works, but on single-radio extenders it halves effective throughput and adds a roaming variable — every permanent deployment should use cable.

One ESSID per extender. A HaloWiFi router broadcasts two networks at once — the open Guest network (captive portal) and the password-protected Staff/PSK network. A third-party extender can only rebroadcast one of them. This guide extends the Guest ESSID; the Staff branch is covered in step 4.

The topology

InternetISP / WAN WAN HaloWiFi RouterCaptive Portal (HaloChilli)RADIUSDHCP / DNSDirect APGuest ESSID Ethernet ExtenderAP / bridge modeGuest SSID · open · no DHCP Guest Devicesees captive portal captive portal auth (HaloChilli → FreeRADIUS) also broadcasts Guest SSID directly

The extender bridges radio coverage; every control-plane function stays on the router.

From the router’s perspective, a client behind the extender looks identical to a client on the main AP — same DHCP range, same RADIUS session, same portal flow.
Field notes, deployment team

What the extender must never do

Three failures account for nearly every broken extender deployment:

Double NAT. The extender must not create its own subnet. If it does, HaloChilli can't see the client's real IP and the captive-portal redirect fails completely — clients get a connection error instead of the login page.
Its own DHCP. Only the HaloWiFi router assigns addresses. A live DHCP server on the extender hands out out-of-range IPs, breaking RADIUS accounting, bandwidth control and analytics. Re-check after every firmware update — some devices silently re-enable it.
Hiding client MACs. Sessions are tracked by the client's original MAC address. Mesh systems that forward all traffic behind the node's own MAC break per-device session isolation, time limits and quotas for everyone on that extender.

Two softer rules: broadcast exactly one SSID (the one you chose to extend — never both), and match the Guest SSID string exactly, case-sensitive, with security set to Open / None. A mismatched SSID is a second visible network that bypasses portal auth.

Setup in six steps

Put the extender into AP / bridge mode. In the extender’s web UI or app, switch the operating mode to Access Point (sometimes “AP mode” or “bridge”). This disables its router and NAT functions. Do not use “Range Extender” or “Repeater” mode — those create a second subnet and break the portal.
Disable the extender’s DHCP server. Many devices do this automatically in AP mode — confirm it under LAN/Network settings. The DHCP field should read Disabled before you continue.
Connect the backhaul cable. Ethernet from the extender’s LAN or WAN port into any LAN port on the HaloWiFi router or a switch on its LAN. Cat5e or better; for ceiling mounts, a PoE switch powers the extender over the same cable.
Match the Guest SSID. Set the extender’s SSID to exactly the HaloWiFi Guest network name, security Open / None. The Guest network is open by design — the captive portal does the authenticating.
Verify the client IP. Join the extender’s SSID with a test device. It should get an address in the HaloWiFi DHCP range (typically 192.168.182.x). Anything like 192.168.0.x or 10.0.0.x means the extender’s DHCP is still on — back to step 2.
Confirm the portal appears. Browse to any HTTP site (e.g. http://example.com) — the HaloWiFi portal login should load; complete a test login end-to-end. HTTPS sites show a certificate error before the redirect can fire, so always test with plain HTTP.

Extending the Staff/PSK network instead? Same steps, different step 4: match the Staff SSID and set WPA2-Personal (or WPA3) with exactly the same passphrase. There is no captive portal on that ESSID — the password is the gate. Never leave an extender SSID open on the Staff segment; that would be uncontrolled access.

Device compatibility

From venue deployments so far — treat unlisted devices as untested and verify MAC passthrough plus true AP mode before installing:

Works in AP mode

TP-Link RE series — Tether app or web UI: Settings → Operation Mode → Access Point. Disable DHCP under LAN settings. MAC passthrough confirmed.
Netgear EX series — use AP mode, not Range Extender mode (settings at 192.168.1.250). Disable DHCP under LAN Setup.
GL.iNet / OpenWrt — full control: disable DHCP, set network.lan.proto=none, disable firewall forwarding. The most flexible option for technical deployments.

Conditional

TP-Link Deco — must be switched to Access Point mode in the app before joining the network; mesh mode hides client MACs. Verify DHCP is off after the mode change.
Netgear Orbi — AP mode exists on RBR/RBS; older firmware lacks MAC passthrough, so check versions first.
Generic OpenWrt — configure as a dumb AP via LuCI/UCI: no gateway/DNS on the LAN interface, dnsmasq off, wireless bridged to LAN.

Do not use

Amazon Eero / Google Nest WiFi — neither offers true bridge mode; both always create a second subnet and hide client MACs, which kills the portal redirect for every client behind them.
Single-radio budget extenders — one radio shared between clients and backhaul halves throughput, and most can't do true AP mode at all.

When something's not right

Portal not appearing — test with an HTTP (not HTTPS) site; confirm the client IP is in the 192.168.182.x range; confirm AP mode (not router/NAT) and that no second DHCP server is live.
Wrong client IP — the extender's DHCP is active. Disable it, reboot the extender, reconnect. Firmware updates are the usual culprit.
Per-device limits not enforcing — the extender is in mesh mode and hiding MACs. Switch to true AP/bridge mode; verify with a capture that the client MAC appears on the LAN.
Clients get uncontrolled access — the extender SSID is bridged to the wrong segment and has bypassed HaloChilli. Re-bridge onto the Guest LAN and confirm NAT is off.

When to stop extending

Extenders work, with caveats you now know: no RF telemetry, no fast roaming, and settings that need re-checking after firmware updates. A second HaloWiFi AP removes all three — full cloud visibility, zero MAC-passthrough concerns, and seamless portal roaming: HaloWiFi APs in one deployment share 802.11r keys automatically through the cloud controller, so handoffs take ~50 ms. A third-party extender on the same SSID forces a full re-association — a 150–300 ms drop — every time a client walks between radios.

If the extender is a stopgap, it's a good one. If coverage is the actual problem, the second AP is the actual fix — and it's managed from the same dashboard as the first. Questions either way: support@halowifi.com.