Network requirements and firewall settings

Screenbird itself uses HTTPS and WebSocket Secure over port 443 only. On a locked-down network, add the domains below to your allowlist: one list for the dashboard and one for the screens (the player). If you use an Amazon Signage Stick or a Fire TV, also read the section Time sync on Amazon devices: those devices need extra connections of their own.

When do you need this?

Most home and office networks work right away. You need this list if the network blocks unknown domains, runs a proxy or web filter, or if the screens sit on a separate VLAN with limited internet access.

Domains for the dashboard

For the computers your team manages content on:

  • screenbird.app: the dashboard itself
  • dev.screenbird.app: staging, only needed if your team works with it
  • *.supabase.co: database and sign-in, over WebSocket too
  • cdn.screenbird.app: files, images, videos, and your own fonts
  • integrations.screenbird.app: the app previews in the dashboard
  • lh3.googleusercontent.com and avatars.githubusercontent.com: profile pictures from connected accounts
  • challenges.cloudflare.com: the security check when you sign in or sign up
  • wss://api.screenbird.app: live updates between the dashboard and the screens
  • js.stripe.com and *.js.stripe.com: the payment window when you sign up and when you change your plan
  • api.stripe.com and hooks.stripe.com: completing the payment, 3D Secure included
  • m.stripe.com and m.stripe.network: Stripe's fraud check

Needed only for certain features:

  • apis.google.com and docs.google.com: the picker for Google Drive, Docs, Sheets, and Slides
  • images.pexels.com: the stock photo library
  • api.qrserver.com: QR codes in design templates
  • geocoding-api.open-meteo.com: location search in the Weather app

Domains for the screens

For every device running the player:

  • player.screenbird.app: the player itself
  • api.screenbird.app: pairing, heartbeat, and fetching content, over WebSocket too
  • cdn.screenbird.app: the content the screen plays
  • media.screenbird.app: installers and app updates
  • integrations.screenbird.app: every app and design runs inside this
  • mirror.screenbird.app: only needed for screen mirroring, over WebSocket too
  • fonts.googleapis.com and fonts.gstatic.com: fonts in apps and designs

Needed only for certain apps:

  • www.youtube.com and player.vimeo.com: the video apps

If you do not use a connection or an app, you do not have to allow the matching domain.

Ports and protocols

  • HTTPS over port 443 for all traffic
  • WebSocket Secure (WSS) over that same port 443 for live updates between the dashboard and the screen

Screenbird itself uses no other ports. An Amazon Signage Stick or Fire TV does need extra connections to set its clock (UDP port 123 and TCP port 80), see the section below.

Time sync on Amazon devices

This section applies to the Amazon Signage Stick and the Fire TV only. If you use a Samsung, LG, Android TV, PC, Mac or Raspberry Pi, you can skip it.

These devices have no clock that keeps running once the power is off. They get the time from the internet at startup. If that fails, they start up on a date weeks or months in the past, and with the wrong date every secure connection is refused. The screen then stays offline, even with port 443 fully open and every domain on your allowlist.

So allow these connections:

  • ftv-smp.ntp-fireos.com over UDP, port 123: fetching the time. This name resolves to time.aws.com; if your firewall allowlists by DNS name, allow both
  • firetvcaptiveportal.com, fireoscaptiveportal.com and kindle-time.amazon.com over TCP, port 80, not intercepted: the network check and the fallback for fetching the time

Port 80 is required even when UDP 123 is open. The device only sets its time on a network it has validated, and that check is itself a request on port 80. If outbound port 80 is blocked, the clock is never set, whatever happens on UDP 123.

The device tries again each time it connects to a network and after that only once every 7 days. A screen that misses the first attempt can therefore stay on the wrong date for a long time. Once the firewall is fixed, restart the device or reconnect it to the network to trigger a new attempt.

Things to watch:

  • The device uses fixed addresses and does not accept a time server handed out by the network, so pointing it at your own time server will not help.
  • Port 80 traffic must not be intercepted. A transparent proxy that passes the request on to the internet is fine. A proxy or web filter that answers by itself, for example with a block page, sets the clock to its own time, which is only correct if the clock of that proxy is correct. A cache that replays old responses can set a stale time.
  • Use a network without a sign-in captive portal. On a network with a sign-in portal the device makes a single attempt and does not save the result, so the clock cannot be relied on until the portal is cleared. That is exactly what many guest networks do.

Is a screen paired but offline while the device clearly has internet? This is the first place to look.

Bandwidth

How much bandwidth you need depends on how big your content is. A screen downloads a file once and plays it locally after that, so once the download is done there is barely any traffic. When idle, a screen only keeps the connection alive with a heartbeat every 60 seconds. If the WebSocket cannot get through, the screen still fetches its content every hour. Live streams and apps that keep pulling fresh data do keep using bandwidth, depending on the source.

Short network outages do not interrupt playback: downloaded content keeps playing.

Testing whether the network is set up right

On the device, open a browser and go to:

  • https://player.screenbird.app: this should show the pairing screen with a pairing code
  • https://screenbird.app: this should show the dashboard sign-in page

If either one fails, check the firewall logs to see which of the domains above is blocked.

Where is my data stored?

  • The database runs at Supabase in Paris (region eu-west-3).
  • The offsite backups sit at Backblaze in Amsterdam (region eu-central-003).
  • The dashboard, the apps, and the files are delivered over Cloudflare's network, which runs on edge locations worldwide.

The full list of processors and the retention periods are in the privacy statement on screenbird.app.

Help with a corporate rollout

Rolling out a lot of screens behind a corporate network and need documentation for your IT department? Email support@screenbird.app.

Related articles

© screenbird.app