Network ports

This page lists the network ports used by Tengri services and gives firewall configuration guidance. All ports are TCP; the values below are the defaults. Ports of Tengri services are changed with TNGRI_* variables in /etc/tengri/tengri.conf, ports of third-party services — in their own configuration files.

Client ports

These ports listen on all network interfaces and serve users and external systems. Open them to client networks on the firewall.

Port Service Purpose Setting

5433

tengri.service

Connections over the PostgreSQL protocol: psql, ODBC/JDBC drivers, BI tools. TLS is enabled with TNGRI_PSQL_SSL_KEY and TNGRI_PSQL_SSL_CERT.

TNGRI_PORT

3000

tengri.service

Web UI and REST API. Notebook kernels talk to it as well.

TNGRI_WEBAPP_PORT

3001

tengri.service

WebSocket connections of the web UI and Python clients.

TNGRI_WEBSOCKET_PORT

3005

tengri.service

Iceberg REST catalog for external engines: Spark, Trino, PyIceberg.

TNGRI_REST_CATALOG_PORT

9002

minio.service

S3 API of the local MinIO storage. Needed by clients that access the storage directly, including users' browsers.

MINIO_OPTS in /etc/default/tengri-minio

9003

tengri-s3-proxy.service

S3 access proxy: users work with the Stage/ area through it under their own credentials (Boto3, DuckDB).

TENGRI_S3_PROXY_LISTEN

8009

tengri.service

MCP server for external AI agents. Disabled by default.

TNGRI_ENABLE_MCP, TNGRI_MCP_PORT

TLS on the web UI and WebSocket uses the shared TNGRI_SSL_KEY and TNGRI_SSL_CERT settings.

Inter-node ports

In a single-machine installation all services talk within the node and need no firewall rules. In a cluster configuration the following must be open between the nodes:

Port Listens on Purpose Setting

57776

the node running tengri.service

Cluster RPC channel: agents connect to the server. Protected with mutual TLS via TNGRI_RPC_SSL_KEY, TNGRI_RPC_SSL_CERT and TNGRI_RPC_SSL_CA.

TNGRI_RPC_PORT

ephemeral

nodes running tengri-agent.service

Each worker process listens on a random port assigned by the operating system, and the server connects to it directly. TCP traffic must be allowed between cluster nodes on the whole ephemeral range — on Linux it is 32768—​60999 by default (sysctl net.ipv4.ip_local_port_range).

5432

the node running the catalog PostgreSQL

Metadata catalog: the single PostgreSQL server every cluster node connects to (the address is set in TNGRI_CATALOG_URI). In a single-machine installation it listens on 127.0.0.1 only and needs no firewall rules.

TNGRI_CATALOG_URI

2379

the node running etcd

Client connections to etcd: this is how cluster nodes discover each other. By default etcd listens on localhost only; cluster addresses are set in /etc/etcd/etcd.conf.yml.

listen-client-urls

2380

nodes running etcd

Traffic between etcd cluster members.

listen-peer-urls

8080

the node running Mimir

Metrics ingestion (remote write) from Alloy. Used only locally in a single-machine installation; open it to cluster nodes when metrics are collected centrally.

/etc/mimir/config.yaml

Local ports

The following ports listen on the loopback interface 127.0.0.1 by default or are reachable by local processes only. They need no firewall rules; they are listed here to tell them apart from unexpected traffic and to account for them when hunting port conflicts.

Port Service Purpose

3006

tengri.service

Control interface of the S3 access proxy: it hands out credentials and access decisions. Expose it only when tengri-s3-proxy runs on another node (TNGRI_S3_ACCESS_CONTROL_HOST).

9001

minio.service

MinIO web console.

9004

tengri-s3-proxy.service

Proxy admin interface: status and administration (TENGRI_S3_PROXY_ADMIN_LISTEN).

9095

mimir.service

Internal gRPC interface of Mimir.

9591

tengri.service

Prometheus-format metrics at /metrics. To scrape metrics from another node, set TNGRI_PROMETHEUS_HOST and open the port (TNGRI_PROMETHEUS_PORT).

12345

alloy.service

Alloy service HTTP interface.

random

notebook kernels

Ports of Python notebook kernels; containers publish them on 127.0.0.1 only.

Outbound connections

In environments that filter outbound traffic, Tengri services may need access to external resources:

  • the LLM addresses set in the configuration — when AI agents are used;

  • the Python package repository for notebook environments (TNGRI_PIP_INDEX_URL, PyPI by default);

  • the npm registry for dashboard builds (TNGRI_NPM_REGISTRY_URL);

  • an external S3 storage, when it is used instead of the local MinIO (TNGRI_S3_ENDPOINT_URL).

Browser notebooks fetch Pyodide packages from a CDN (TNGRI_PYODIDE_CDN_URL, cdn.jsdelivr.net by default) — that connection is made by the user’s browser, not by the server.

Firewall configuration example

An nftables ruleset example for a single-machine installation: only the client ports are open, the rest of the inbound traffic is dropped. A fragment of /etc/nftables.conf (adapt it to your own policy, and keep an SSH rule so you do not lose access to the node):

table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;

        iif "lo" accept
        ct state established,related accept
        ct state invalid drop

        tcp dport 22 accept comment "SSH"
        tcp dport { 5433, 3000, 3001, 3005, 9002, 9003 } accept comment "Tengri client ports"
    }
}

In a cluster configuration, additionally allow traffic between the nodes. The simplest way is to allow all TCP traffic between the nodes, since worker processes use ephemeral ports — add a rule with the subnet or addresses of the cluster nodes to the input chain:

ip saddr 192.0.2.0/24 meta l4proto tcp accept comment "cluster nodes"

If you need narrow rules, open ports 5432, 57776, 2379, 2380 and the ephemeral range to the cluster nodes:

ip saddr 192.0.2.0/24 tcp dport { 5432, 57776, 2379, 2380, 32768-60999 } accept comment "cluster nodes"

Apply the rules and enable loading them at boot:

sudo nft -f /etc/nftables.conf
sudo systemctl enable nftables