BabelBirdBabelBird Docs

Port and network requirements

This page describes standard deployment protocols. Default ports support planning; final firewall rules must match enabled components, actual listeners and container port mappings. Allow only the required sources and destinations.

Service entry points

Source → destination Reference port / protocol Purpose and condition
User browser / client → drive entry point or reverse proxy 443/TCP, HTTPS Encrypted service access
User browser / client → drive entry point or reverse proxy 80/TCP, HTTP Only when HTTP access or redirection to HTTPS is enabled
Caller → deployed Node service entry point 3060/TCP or 3080/TCP Plaintext / encrypted examples from existing deployments; exposure depends on the deployment and proxy configuration

Scroll horizontally to view all columns

Internal services and storage

Directions below are caller → service listener. Replace roles with actual hosts. A container's internal port does not necessarily need host publishing or external access.

Caller → service listener Default or reference port Condition
Components requiring cache → Redis 6379/TCP Redis is enabled and accessed across hosts
Components requiring the database → MySQL 3306/TCP This database is enabled and accessed across hosts
Transcoding or other components → internal application API 8080/TCP (existing deployment example) Use the listener and mapping in the delivery configuration
Application components → Elasticsearch 9200/TCP Search is enabled
Management client → Kibana 5601/TCP Optional management interface; restrict to management sources
Application components → Tika 9998/TCP Document text extraction is enabled
Management client → container management UI 9000/TCP (existing deployment example) Optional management component, not a required Docker cluster port
NFS clients → NFS server NFSv4: 2049/TCP NFS storage is used
NFSv3 clients → NFS/RPC services 2049, 111 and configured mountd/statd/lockd ports Protocols and auxiliary ports depend on the NFS version and system configuration; 35000 is an existing mountd example, not a universal fixed value
Authorized management client → Docker daemon 2376/TCP, TLS Remote management only; a local Unix socket does not require this network port
Application and transcoding components Actual transcoder listeners and published ports Determined by the delivery configuration, not the Docker cluster port list

Scroll horizontally to view all columns

Configure NFS by version; do not apply the NFSv3 auxiliary-port list to a pure NFSv4 deployment. See NFS firewall configuration and Docker remote access.

Docker Swarm cluster

Port Protocol Communication scope Purpose
2377 TCP Cluster nodes to managers, and between managers Swarm management
7946 TCP and UDP Between Swarm nodes Overlay network discovery and communication
4789 (configurable default) UDP Between Swarm nodes participating in the overlay network Overlay data traffic

Scroll horizontally to view all columns

Encrypted overlays also require IP protocol 50 (IPsec ESP, not TCP/UDP port 50). Restrict 4789 to trusted cluster networks. See Docker's protocol and port documentation. A single-server deployment without Swarm does not need this table's cluster rules.

Installation and maintenance

Source → destination Port / protocol Condition
Authorized deployment bastion / management client → target server 22/TCP, SSH Remote Linux installation or maintenance; restrict sources and access duration
Server requiring installation or licensing → service address in the delivery plan 443/TCP, HTTPS Outbound access to the actual package, image or licensing service

Scroll horizontally to view all columns

Use installation and licensing destinations from the current delivery plan. Do not turn old fixed IP examples into permanent allowlists. For isolated networks, agree offline delivery and licensing through the POC guide.

Apply to the actual deployment

  1. List the application, search, storage, transcoding and management components enabled for this project.
  2. Check actual listeners and published container ports, and replace roles with specific hosts and network ranges.
  3. Create rules by source, destination, protocol, port and enabling condition. Do not expose extra ports for components that need no cross-host access.
  4. Verify user access, internal calls and required installation or maintenance paths, then revoke temporary deployment access.
BabelBird capabilities may change by product version, licensed modules and deployment configuration; actual availability depends on the deployed environment and administrator settings.

Page Markdown · AI reading guide