Network requirements (firewall and proxy)

This page lists everything a network administrator needs to allow so that Lumicast players and the Lumicast web app work correctly.

The short version: allow outbound HTTPS (port 443) to the Lumicast domains below. Nothing else is required. No inbound connections, no port forwarding, no VPN, no custom port numbers.

Ports

Direction	Protocol	Port	Required
Outbound	HTTPS (and WebSocket over TLS)	443	Yes
Outbound	HTTP (redirects to HTTPS)	80	Recommended
Inbound	anything	any	No

Lumicast never asks you to open a port in your firewall. Players always initiate the connection themselves, and they only ever connect out over standard HTTPS. Live updates use a WebSocket, which runs over the same port 443 connection, so no extra rule is needed as long as your firewall or proxy does not strip WebSocket upgrades (see Proxies and TLS inspection).

We also do not send traffic to custom ports on your side, and we never connect into your network.

Domains to allow

Lumicast uses three domains:

Domain	What to allow	Used for
lumicast.com	The whole domain (recommended)	Web app, login, API, WebSocket updates, player downloads
lumicast.app	*.lumicast.app (all first-level subdomains)	Apps and embedded content rendered on your displays
lumicast.media	At minimum cdn.lumicast.media	Images, videos, fonts and other media assets

A few notes on why the entries are that broad:

• We use subdomains within each of these domains, and we cannot guarantee that every subdomain stays the same forever, or that no new ones are added later.
• For lumicast.app, everything within the first subdomain level must be reachable: *.lumicast.app. Each app gets its own subdomain there.
• For lumicast.com we recommend allowing the whole domain, because we add services and occasionally rename them over time.

We do not publish a fixed hostname list

Our hostnames change as we add and rename services, so any list you write down today will eventually break. Please create a rule per domain instead of allowlisting individual hostnames.

How data sources reach your displays

A common question is which external systems a display needs to reach for data sources and apps to work. The answer for the built-in integrations is: none.

All fetching, polling and processing happens on Lumicast's side:

1. Lumicast polls the integration or API on a schedule (or receives a webhook), on our servers.
2. Lumicast stores the latest result.
3. The result is pushed to your displays over the existing HTTPS/WebSocket connection to Lumicast.

So a display showing a weather app, a train schedule or a SharePoint list does not talk to the weather service, the railway API or SharePoint itself. It only talks to Lumicast. Allowing the three domains above is enough.

Data sources on your own network

This also means the reverse: if you connect a data source to an API that is only reachable from inside your own network, Lumicast cannot reach it. Our servers do the polling, so the API needs to be reachable from the internet. A webhook data source is the usual solution, since your system pushes the data to us instead.

Allowlisting Lumicast on your own API

If you expose an API to Lumicast and want to restrict who can call it, note that we cannot guarantee a stable set of outgoing IP addresses at this time. Prefer authentication (an API key, a token, or a signed webhook) over an IP allowlist. If an IP allowlist is a hard requirement for you, contact [email protected] so we can look at it with you.

Content you add yourself

Some content is loaded by the display directly from a third party, because that is how the content works:

• The Webpage app, which loads the URL you enter.
• YouTube, Vimeo and Video Stream apps, which stream from the provider you point them at.
• Images or files you reference from an external URL rather than uploading them to Lumicast.

If you use any of these, also allow the domains of that content. Media that you upload to Lumicast is served from cdn.lumicast.media and needs nothing extra.

Fonts

Displays load font files from Google Fonts when a page uses one:

• fonts.googleapis.com
• fonts.gstatic.com

Fonts that you upload to Lumicast yourself are served from cdn.lumicast.media. If Google Fonts is blocked, pages still render, but they fall back to a default font.

Proxies and TLS inspection

If your network uses a proxy or a TLS-inspecting firewall, check the following:

• WebSocket connections must be allowed. Displays keep a WebSocket open to Lumicast to receive content changes instantly. If it is blocked, a display can still show content but updates arrive late or not at all.
• TLS inspection needs its root certificate trusted by the device. Some player devices (Samsung Tizen, LG webOS, Android TV) make this hard or impossible. If a display cannot connect while a regular computer on the same network can, an inspecting proxy is the usual cause. Excluding the Lumicast domains from inspection is the simplest fix.
• Captive portals and guest Wi-Fi that require a periodic browser login will disconnect displays. Put displays on a network segment without a portal, or allowlist their MAC addresses.

Checking whether it works

From a device on the same network as the display:

1. Open https://app.lumicast.com in a browser. It should load and let you log in.
2. Open https://cdn.lumicast.media in a browser. Any response other than a connection or blocked-by-policy error means the domain is reachable.

On the display itself, the service menu shows the current connection state. A display that shows a pairing code but never comes online usually points at a blocked WebSocket rather than a blocked domain.

Still stuck? Contact [email protected] with the display name and the name of the firewall or proxy product you use.