A cloud digital signage player usually needs one outbound rule: allow HTTPS (TCP port 443) to the vendor's domain. The player always starts the connection. It needs no inbound port, no port forward and no DMZ placement.
What port does digital signage need?
Port 443, outbound, HTTPS. That one port carries everything: pairing, content, schedules, live updates and the player software itself. A signage player never listens for an incoming connection from the internet, so a network scan from outside finds nothing to connect to.
The device also needs DNS (UDP 53) and outbound NTP (UDP 123) to set its clock. A device with a wrong clock fails every HTTPS certificate check. Most networks already allow both.
Why no inbound port is needed
A firewall remembers which device started a conversation. When the player opens an outbound HTTPS connection to the vendor's server, the firewall lets the replies on that same connection back in automatically. That is how a browser loads a page or a chat app receives a message: the client calls out, the server answers back down the open line. Nothing has to call in.
Live updates work the same way. Publish a change and the screen updates at once, instead of waiting for its next check. To do that, the player holds one outbound connection open, rather than closing it after each request. On Brix, that connection is a WebSocket to api.brixsignage.com, still over port 443, still started by the player. Some firewalls and proxies block the WebSocket upgrade specifically, even while they allow plain HTTPS. If that happens, Brix falls back to Server-Sent Events on the same host and the same port. Nothing to open, nothing to change.
On the screen itself, Check connection in the Brix player's settings tests each link in order (internet, Brix, the live connection, media, storage), so a tech can see which link is down instead of guessing at a blank TV.
If a vendor's setup instructions ask you to open an inbound port or forward one to a player, ask why. A signage player has no reason to need one.
Domains to allow (the firewall whitelist)
Every vendor uses its own domain, so get the current list from your vendor. For Brix, one host carries the core product:
| Allow | Domain | Protocol | Why |
|---|---|---|---|
| Needed | api.brixsignage.com | HTTPS, outbound, port 443 | Pairing, content, schedules, live updates, the player screen |
| Optional | browser.sentry-cdn.com | HTTPS, outbound, port 443 | Loads the crash-reporting library. Blocked = fewer crash details reach Brix; the player still runs. |
| Optional | o4511406415740928.ingest.us.sentry.io | HTTPS, outbound, port 443 | Sends a crash report, only after the library above loaded. Same effect if blocked. |
| Depends on content | api.open-meteo.com, geocoding-api.open-meteo.com | HTTPS, outbound, port 443 | Forecasts and place names for the Weather app, fetched by the screen itself |
| Depends on content | cdn.jsdelivr.net | HTTPS, outbound, port 443 | Loads the HLS library, only the first time a scheduled live stream plays on a device that cannot decode HLS natively |
| Depends on content | the host of any web page, video or data feed you schedule | varies | A web page app, a YouTube video or a live feed connects to its own host, not Brix's |
There is no separate media or CDN domain to allow for Brix: images, video and documents all come from api.brixsignage.com.
Does the firewall need to trust a certificate?
Only if it inspects TLS. A firewall that decrypts and re-signs HTTPS to scan it needs the player to trust the firewall's own certificate. A Signage Stick or Android player has no way to add a certificate, so a TLS-inspecting firewall has to exempt its traffic by domain instead of intercepting it. A Windows player trusts the Windows certificate store, so a certificate your IT team installs on that PC also works. Otherwise every connection fails with a certificate error, and the screen never gets content.
A firewall or content filter that blocks by category, rather than inspecting TLS, can also miscategorize a signage vendor's domain the same way it would any new cloud service. Allow the domain by name rather than relying on category matching.
Wired or wireless: what changes
Wired Ethernet sidesteps every Wi-Fi-specific problem below: a captive sign-in page, a hidden network, and enterprise Wi-Fi authentication. If the player is fixed to one spot near a switch, wired is the simpler choice.
On wireless, three things specifically trip up signage, none of them firewall settings:
- A captive portal (a sign-in page before internet access starts) blocks setup and breaks playback after, since nobody stands at an unattended screen to accept terms. Use a network that grants full access as soon as it accepts the password.
- A hidden network (one that does not broadcast its name) needs the network name typed in by hand. Many fixed signage devices offer no way to do that during setup, so broadcasting the name for the few minutes setup takes, then hiding it again, avoids the question.
- Enterprise Wi-Fi (the kind that checks a username and password, or a certificate, against a RADIUS server) is a common gap: fixed signage hardware is usually built for a personal network with one shared password. Check with your hardware vendor, or put screens on a separate personal-security SSID, or use wired Ethernet instead.
Some signage players also use multicast to notice when a neighbor screen has gone offline. That tells apart "the whole site lost its uplink" from "one screen died". It needs client devices on the same Wi-Fi to see each other's traffic. Many enterprise and guest networks block this on purpose, for privacy between guests. That is fine: the player's connection to the cloud does not depend on it. Losing it only removes that one diagnostic signal.
Is there ever an inbound port?
Only if you turn one on yourself, for a feature unrelated to the firewall question above. Brix has an optional LAN trigger. A local point-of-sale system, door sensor or AV rack can use it to tell a specific screen to change what is on it, without a round trip to the cloud. Turning it on (Screens > a screen > Advanced > Let equipment here control this screen) opens one listener on that device's own local network address, on a port you choose. Every request to that listener must be signed with the screen's own key, or the device refuses it.
That listener answers only devices on the same local network. It is not reachable from the internet, and it never needs a rule on your perimeter firewall. It is off by default, and most screens never need it.
A checklist for your network team
- Allow outbound HTTPS, port 443, to your signage vendor's domain. Add no inbound rule.
- For Brix: allow
api.brixsignage.com. Treat Sentry and jsdelivr.net above as optional. - If a content filter or firewall blocks by category, add the domain by name.
- If the firewall inspects TLS, exempt the player's traffic rather than intercept it.
- Give the player a password-protected personal-security SSID (not Enterprise Wi-Fi), or wired Ethernet.
- Do not hide the SSID during setup, and keep any captive sign-in page off the network the player uses.
- Put the player on its own VLAN or subnet, the same as any other fixed appliance.
- Leave the LAN trigger feature off unless you specifically need local automation.
FAQ
Does a signage player need a static IP address?
No. A normal DHCP-assigned address works, the same as any other device on the network.
Will blocking the WebSocket connection break the screen?
No, on Brix. If a network blocks the WebSocket upgrade, Brix switches to Server-Sent Events over the same domain and port, so live updates still arrive. A screen that is fully offline instead keeps playing its last cached content until the connection returns.
What happens if the firewall rule is wrong?
A new device shows "Can't reach Brix" instead of a pairing code. On an Android player or Signage Stick, the message names the domain to allow. Or a screen that was working goes offline in the dashboard, while the TV itself stays on and keeps showing its last cached content. See troubleshoot a screen for what each state means.
Does the Amazon Signage Stick have different requirements?
Yes, it needs Amazon's own domains allowed as well as your signage vendor's. See Amazon Signage Stick network requirements for that specific list.
A firewall rule is one part of a security sign-off. For the questions that come after the network ones, see answering a digital signage security questionnaire.
Get your network team this list before a rollout, and pairing goes faster on day one. Talk to us and we can walk through your network setup with you directly.