Open Your Network for LobbyFlight Displays
What a LobbyFlight display asks of your network: which hosts it contacts, how often, and which firewall rules quietly break it.
Open Your Network for LobbyFlight Displays
This article is for whoever runs the hotel network. It tells you exactly which hosts a LobbyFlight display contacts, how often it contacts them, and which well-meant firewall rules break the board in ways that are hard to recognise as network problems.
What you are actually letting through
A LobbyFlight display is not an appliance and not an agent. It is a browser sitting on a web page — /display/<hotelId> — that fetches data over HTTPS and draws a flight board with it. Everything it does is an outbound request from that browser to a web server.
Two things follow from that, and they are the two things IT departments most often ask about. You do not need to open any inbound port, because nothing ever connects *to* the screen. And you do not need to allow WebSockets, because the product does not use any: the board polls on timers instead of holding a socket open. If your monitoring flags a long-lived connection on port 443 from a display, it is not us.
You also do not need a VPN, a tunnel, or any protocol beyond plain HTTPS.
Hosts to allow
Allow outbound HTTPS to lobbyflight.com and *.lobbyflight.com. That covers the display page itself, the configuration endpoint, the flight data, the weather endpoint and the heartbeat — all of it is served from the product's own origin.
If your hotel is on the Premium plan and uses Portal → White-Label → Custom Domain to run the board under your own hostname, for example flights.yourhotel.com, then that hostname has to be in the allow list too. This is the single most common reason a firewall rule that looks correct still leaves a screen blank: a rule for *.lobbyflight.com does not match a display served from your own domain.
Beyond the product's own domains, the display's browser reaches out to a small number of third-party hosts:
www.googletagmanager.com, www.google-analytics.com, region1.google-analytics.com, connect.facebook.net, *.posthog.com, *.vercel-insights.com and *.vercel-analytics.com. None of them are part of the flight data path. If your policy is to block trackers on signage VLANs, block them.js.stripe.com, api.stripe.com, hooks.stripe.com, checkout.stripe.com) is only needed if staff open the billing pages of the portal from the same network segment. Displays never touch it.Two hosts that older versions of this article listed do not exist and should not be in your rules: there is no api.lobbyflight.com and no cdn.lobbyflight.com. The public API lives at https://lobbyflight.com/api/v1. Uploaded images — hotel logo, display logo, info slides — are served through the product's own origin under /_next/image, so there is no separate CDN host to open. Google Fonts is not needed either: the display's fonts are compiled in at build time and served from our own domain, and the site's Content-Security-Policy sets font-src 'self' data:, so a request to fonts.googleapis.com would not be made in the first place.
Ports
| Port | Protocol | Why it is needed |
| ------ | ---------- | ------------------ |
| 443 | TCP / HTTPS | Everything: the page, the config, the flight data, the heartbeat |
|---|---|---|
| 80 | TCP / HTTP | Only the redirect to HTTPS on the very first request to a host |
| 53 | UDP / DNS | Name resolution |
Port 80 matters for a shorter time than you would think. The site sends Strict-Transport-Security with a two-year max-age, includeSubDomains and preload, so after the first successful contact the browser upgrades to HTTPS on its own and never asks for port 80 again. Anything that downgrades traffic to plain HTTP will fail rather than fall back.
How often the display talks
This is the part an IT department can actually plan against, so here is the real request profile of one screen:
Images are cached aggressively by the browser: logos, slide images, icons and fonts are served with a one-year immutable cache header, so they are fetched once and not again. Note that this is ordinary HTTP caching. No service worker is registered on the display route, so there is no offline buffer behind it; when the network is gone, the requests above simply fail until it comes back.
The rule that breaks the least visible thing
If your allow list is too narrow and only the heartbeat is blocked, nothing appears to be wrong. The screen keeps showing flights, guests see a working board, and nobody in the lobby notices anything. But the portal stops hearing from the display, and after 12 minutes it lists that display as Offline.
That threshold is deliberate. The display sends a heartbeat every 5 minutes, so a 12-minute window is two missed beats plus a little slack — wide enough that a reload or a brief blip does not raise a false alarm. If a screen shows a status you cannot reconcile with what you see in the lobby, check whether /api/analytics/heartbeat is reachable before you go looking at the screen itself.
Proxies and SSL inspection
The display is a browser, so an explicit proxy configured in that browser will be used. What you cannot assume is that a proxy is harmless.
The site ships a strict Content-Security-Policy: default-src 'self', font-src 'self' data:, and closed lists for img-src and connect-src. Anything sitting in the middle that rewrites HTML, injects a script, or serves content from a host that is not on those lists gets blocked by the browser itself, regardless of what your firewall allows. A proxy that only forwards bytes is fine. A proxy that edits them is not.
The same applies to SSL inspection. Put the hosts the display needs on the inspection bypass list — lobbyflight.com, *.lobbyflight.com, your own white-label domain if you use one, and openweathermap.org. There is no LobbyFlight certificate to import; the certificates are issued by the hosting platform, so bypassing inspection for those hosts is the only option. If you leave inspection on and the heartbeat is among the casualties, you get exactly the silent-offline case described above.
Guests are on a second path
Displays are not the only LobbyFlight traffic in the building. If your hotel uses the guest companion, guests scan a QR code and open /guest/<token> on their own phones — a small progressive web app that registers a service worker for the guest area. That traffic comes from the guest WLAN, not from the display VLAN, and it goes to the same domains. A rule set that locks down the signage VLAN does not affect it, but a captive portal or a filter on the guest network can.
Checking that it works
From the display's own network segment, request the health endpoint and expect 200 OK:
curl -s -o /dev/null -w "%{http_code}\n" https://lobbyflight.com/api/healthAdding ?detailed=true returns a per-service breakdown instead of a single overall status, which is more useful when something is partially broken. There is also https://lobbyflight.com/api/status. Point your monitoring at these, on the main domain — a check against api.lobbyflight.com will fail forever, because that host does not exist.
If a screen still will not come up after the rules are in place, work through it in this order: confirm DNS resolves the host the display actually uses (your white-label domain, if you have one), confirm port 443 is open to it, then disable SSL inspection for that host and try again.
When you need us
Write to info@lobbyflight.com with the subject IT/Network Configuration and include your firewall rules and any error output you have. Telling us the display ID and whether the portal shows the screen as online or offline saves a round trip, because it tells us immediately whether the heartbeat is getting through.