Network ports reference

This page lists every network port Buttons and its supporting applications (USB Relay, Bitfocus Listener) listen on or connect out through, for firewall and network planning. It's about network ports specifically, not routing Ports, the Buttons resource type under Ports and Bundles, which is a different thing covered in Understand routing concepts.

Editor, Control API, and www#

Port	Protocol	Direction	Configurable	Default scope	Purpose
`4440` (HTTP, default)	TCP	Inbound to Buttons	Yes: Environment Settings	`localhost` only, until you widen it	The editor UI, the Control API, and the web frontend
`4443` (HTTPS, default)	TCP	Inbound to Buttons	Yes: Environment Settings	Same as HTTP	HTTPS for the same traffic, defaults to the HTTP port plus three

By default, neither port is reachable from the network: nothing but the local machine can reach Buttons until you explicitly widen the listen address to all interfaces, covered in Allow access from other computers.

Tip

4440 and 4443 are defaults, not fixed: both can be changed. For the packaged app, change them live from its own Environment Settings screen. For headless Linux, set them on first launch with the WWW_PORT/WWW_HTTPS_PORT environment variables or a different port argument to watchdog-cli. See the Startup configuration reference for every option. Whatever port you actually end up running on (not necessarily 4440/4443) is the one your firewall rule and any port forwarding need to match.

Discovery, NMOS, and tally#

Port	Protocol	Direction	Default scope	Purpose
`5353`	UDP (multicast)	Bidirectional	Network	mDNS: discovering NMOS nodes and third-party network surfaces, and being discovered by them. Standard mDNS, not configurable. It needs to actually reach whatever subnet your NMOS devices or network surfaces sit on. mDNS doesn't route across VLANs by itself.
`19004`	TCP	Inbound to Buttons	Network, only if you enable it	The built-in NMOS Registry Server (IS-04 Registration/Query API). Off by default; its port is configurable in NMOS settings once enabled.
Set per connection	TCP or UDP	Inbound to Buttons	Network, only if you configure one	A Tally Server (Listen) connection, see Receive tally and labels from another system for the "Localhost only" option if you don't want a given connection network-reachable. Can't be set to `3131` or `7110`–`7112`: reserved for the health check and tally leader election respectively.

Note

Tally connections aren't all one direction: a Client (Connect) connection has Buttons connect out instead, the same outbound pattern as a device-facing module below. The row above covers only the Server (Listen) direction, where something else connects in.

Modules, connections, and workflow nodes#

Direction: outbound from Buttons, as a baseline: a connection's own module talks to its device or software over whatever port that device's protocol uses, and it isn't something Buttons imposes or lets you change. There's no single list to give here: check the specific device or software's own documentation, and that module's own configuration fields, for the port(s) it actually needs.

That baseline isn't the whole story for every module, though. Some take two separate port fields in their own configuration, one to send to the device, and a different one the device is expected to send back to. That return port is a real, fixed, inbound port once it's set, not an outbound detail. Check the specific module's own config rather than assuming outbound-only.

A connection that's specifically built to accept something calling into Buttons, like a TSL Server (Listen) connection in the table above, works the same way: inbound, on whatever port it's configured to listen on.

Workflow nodes follow the same pattern as modules. A REST Server node opens its own inbound listening port, you set it directly on the node, and it needs to be a free port your firewall allows in, the same as any other inbound port on this page. An HTTP Request node is the outbound counterpart, calling out to whatever URL and port you give it.

Elsewhere on the network, not the Buttons host#

USB Relay (a separate application, typically running on its own machine near the USB hardware): 3040 TCP by default. Its default server mode listens for Buttons to find and connect to it: open 3040 on that machine, not the Buttons host, for this default case. It can instead be set to an outbound mode (-buttonsAddress), where the relay machine connects out to Buttons itself. In that mode, 3040 isn't used at all, and the connection is inbound to Buttons on its own editor port instead, same as the first table above. Check which mode a given relay is actually running in rather than assuming.
Bitfocus Listener (also usually a separate machine): 12001 TCP by default, outbound from Buttons only, see Connect to Bitfocus Listener. The inbound rule for this one belongs on the Listener's machine, not the Buttons host.

Outbound#

Direction: outbound from Buttons, to the internet rather than another machine on your own network. Buttons reaches two Bitfocus services over standard outbound HTTPS (443), needing no special firewall rule beyond normal internet access: updates.bitfocus.io for update checks, and api.bitfocus.io for license activation and validation.

Kubernetes high availability#

Direction: inbound to the cluster, on the ingress (80/443), plus one exception: every enabled Tally Server (Listen) connection gets its own dedicated external LoadBalancer Service and address, following the elected tally leader, since the tally pods aren't otherwise reachable from outside the cluster. Plan a facility firewall rule for the ingress and for each such connection's own Service address. Every other port on this page, including Postgres, Redis, and the internal leader-election endpoints, stays inside the cluster network in both directions and needs no facility-network firewall rule. See Deploy Buttons with Kubernetes high availability.

Where to go next#

Was this helpful?

0 of 0 users found this page helpful