Network ports
This is the lookup reference for venue IT. For the prose explanation (why outbound-only, bandwidth, latency tolerance), see Network requirements.
Required outbound destinations
Every DisplaySync kiosk needs these reachable.
| Destination | Port | Protocol | Purpose | Direction |
|---|---|---|---|---|
api.displaysync.live | 443 | HTTPS | REST API, claim flow, health checks | Outbound |
api.displaysync.live | 443 | WSS | Real-time WebSocket — heartbeats, commands, content updates | Outbound |
updates.displaysync.live | 443 | HTTPS | Update binaries (Cloudflare R2) | Outbound |
*.ingest.us.sentry.io | 443 | HTTPS | Error tracking (specific subdomain: o4511146214752256.ingest.us.sentry.io) | Outbound |
| Microsoft Update servers | 443 | HTTPS | Windows security patches | Outbound |
Time servers (time.windows.com or pool.ntp.org) | 123 | NTP/UDP | Clock synchronization | Outbound |
Tailscale (optional but recommended)
Required only when Tailscale is part of your deployment.
| Destination | Port | Protocol | Direction | Purpose |
|---|---|---|---|---|
controlplane.tailscale.com | 443 | HTTPS | Outbound | Coordination server |
login.tailscale.com | 443 | HTTPS | Outbound | Authentication |
*.derp.tailscale.com | 443 | HTTPS / TCP | Outbound | Encrypted DERP relay (fallback when peer-to-peer fails) |
| (peer endpoints, learned dynamically) | 3478 | UDP | Outbound | STUN — NAT traversal probe used to establish direct peer-to-peer connections |
| (peer endpoints, learned dynamically) | 41641 | UDP | Inbound (optional) | Direct WireGuard peer-to-peer (preferred path; falls back to DERP if blocked) |
pkgs.tailscale.com | 443 | HTTPS | Outbound | Tailscale binary downloads (only during install/update) |
If only port 443 is allowed (UDP 3478 / 41641 blocked), Tailscale falls back to DERP relays over TCP/443 — slightly higher latency, still works. Most venues don't need UDP 41641 inbound; the direct path negotiates outbound from both peers via STUN.
Content origin
Required only for the URLs you assign as content. There's no fixed list — these are wherever your content actually lives.
| Destination | Port | Protocol | Purpose |
|---|---|---|---|
| Whatever your assigned content URLs resolve to | 443 (typically) | HTTPS | The pages signs display |
If your content is at demo.displaysync.live, that needs to be reachable too.
Strict-allowlist environments
If the venue can only allowlist specific hostnames (no wildcards), this is the minimum set:
api.displaysync.live
updates.displaysync.live
o4511146214752256.ingest.us.sentry.io
controlplane.tailscale.com
login.tailscale.com
<your content origin host(s)>
Tailscale's DERP relays auto-discover the closest one. On a strict allowlist that doesn't include *.derp.tailscale.com, signs may all funnel through a single relay rather than the closest one. Functional, slightly higher latency.
What kiosks do not need
| Direction | Status |
|---|---|
| Inbound from internet | None. Block everything. |
| Inbound from venue LAN | None except optional remote access over the Tailscale interface. |
| Public IP | Not required. RFC1918 / NAT is fine. |
| Domain join | Not required. Local accounts only. |
DHCP / DNS / NTP
| Service | Behavior |
|---|---|
| DHCP | Standard. Static IPs not required, but useful for documentation. |
| DNS | Standard. Whatever the venue hands the kiosk works. Public resolvers (1.1.1.1, 8.8.8.8) are fine if you set them statically. |
| NTP | Required. Kiosks need correct time for TLS handshakes and the 30s command-token freshness window. Default: time.windows.com. Switch to pool.ntp.org or a venue-provided server if needed. |
Protocol/port detail for venue IT:
| Protocol | Port | Direction | Purpose |
|---|---|---|---|
| UDP | 53 | Outbound | DNS — resolves backend, Tailscale, OS update endpoints |
| TCP | 53 | Outbound | DNS fallback (large responses; less common) |
| UDP | 123 | Outbound | NTP — clock sync (must succeed within 30s of sign:command_ack window) |
| TCP | 37 | Outbound | NTP fallback (rare; some firewalled venues) |
Why these specific ports
- All HTTPS over 443 is intentional — most venue firewalls leave 443 open by default, so kiosks are deployable on aggressively locked-down networks.
- No port 80 anywhere. DisplaySync is HTTPS-only end to end.
- No SMB / RDP / VNC required from the venue network. Hands-on access happens over Tailscale.
- NTP over UDP 123 is the one non-443 outbound. If venue IT blocks UDP entirely, switch to a different time source (some NTP servers also serve time over TCP on port 37 — last-resort).
OCSP / CRL revocation caveat: some venue firewalls block plain HTTP/80 entirely. OCSP/CRL revocation checks for fresh CA certificates may use HTTP/80; Tailscale and DisplaySync's own traffic don't depend on this, but a TLS handshake to a fresh-CA endpoint (rare) may stall when HTTP/80 is fully blocked. If you hit a "TLS handshake stuck" symptom that doesn't match a normal allowlist gap, this is a possible cause.
Verifying connectivity from a kiosk
# Backend reachable
Test-NetConnection api.displaysync.live -Port 443
# Updates host
Test-NetConnection updates.displaysync.live -Port 443
# Sentry
Test-NetConnection o4511146214752256.ingest.us.sentry.io -Port 443
# Tailscale (if installed)
Test-NetConnection controlplane.tailscale.com -Port 443
& "C:\Program Files\Tailscale\tailscale.exe" netcheck
Each should respond. If any fail, the venue is blocking that destination — work with IT to allowlist before continuing.
Sentry DSN structure
The desktop sign reports errors to Sentry via a DSN of the form:
https://<key>@<org-id>.ingest.sentry.io/<project-id>
| Environment | Project ID | Routes to |
|---|---|---|
| Production | 4511158032728064 | Production Sentry dashboard |
| Staging | 4511158035152896 | Staging Sentry dashboard |
Same hostname (sentry.io); different project IDs route reports to different dashboards. The DSN is set at build time per the desktop-sign release channel. Venue firewalls only need to allow *.ingest.sentry.io (or the specific subdomain in the Strict-allowlist environments list above) — no per-project allowlisting required.
Captive portal addendum
If the venue WiFi uses a captive-portal redirect (a "click here to accept terms" splash before internet access), DisplaySync kiosks can't auto-acknowledge it. Effects:
- The kiosk's first reachability check fails until the portal is acknowledged.
- The QR-setup screen will not be able to load, because it depends on backend reachability.
- The Network diagnostics overlay (
Ctrl+Shift+N) will show internet check red even on a working venue Wi-Fi.
Workarounds:
- Pre-claim the venue Wi-Fi from a phone using the same Tailscale-tagged credentials before deploying the kiosk. This acknowledges the portal at the network-credential level.
- Some captive portals rebind on each device — in that case, manual portal acknowledgment per-kiosk is unavoidable. Pull a keyboard, exit kiosk mode via
Ctrl+Shift+C→ "Exit for Maintenance", open Edge, accept the portal, restart the sign app.
For the local diagnostic flow, see Hotkeys → Ctrl+Shift+N.
See also
- Network requirements — narrative explanation, bandwidth estimates, Wi-Fi caveats
- Tailscale integration — image-build setup
- Sign shows offline — diagnosing connectivity failures