Bitfocus - Network ports reference

Network ports reference

Docs for

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 (see "Understand routing concepts" in the main documentation).

Editor, Discovery, 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, 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
`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.

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.
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" (First-time setup guide).

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" in the main documentation). 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 only (80/443): that's the one pair of ports a facility firewall needs to know about for this deployment path. 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.

Was this helpful?

0 of 0 users found this page helpful

Network ports reference

Editor, Discovery, 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, 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
`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.

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.
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" (First-time setup guide).

Modules, connections, and workflow nodes#

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" in the main documentation). The inbound rule for this one belongs on the Listener's machine, not the Buttons host.

Outbound#

Kubernetes high availability#

Was this helpful?

0 of 0 users found this page helpful