# Network ports reference

> Every network port Buttons and its supporting applications use, which ones are configurable, and what a connection's module or a workflow node needs on the network.

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. High Availability Direction: inbound to the cluster. In an HA deployment, the defaults are 80 for HTTP and 443 for HTTPS, not 4440 and 4443 . Use only the cluster's virtual IP to connect to Buttons, never the address of one of the three machines. Buttons moves the virtual IP to another machine when one goes down, so the virtual IP keeps working. A Connection or Workflow that receives incoming network traffic, for example a module with a return port or a workflow with a REST Server node, also needs a port forwarding rule. The rule makes the virtual IP forward that port to whichever machine is running the Connection or Workflow. Without it, the port isn't reachable on the virtual IP. See Forward incoming traffic to a connection and Forward incoming traffic to a workflow . Tally Server (Listen) connections are the exception: Buttons forwards their ports automatically. Plan facility firewall rules for 80 , 443 and every forwarded port on the virtual IP. The three machines also talk to each other on other ports to stay in sync. Those ports don't need to be reachable from anywhere else. Where to go next Startup configuration reference Secure a Buttons deployment First-time setup