Couchbase Server Ports

Couchbase Server uses multiple TCP ports to facilitate communication between server components, as well as with Couchbase clients. These ports must be open for Couchbase Server to operate correctly.

Ports Overview

This page describes the TCP ports that are used by Couchbase Server for network communication. Some ports, such as those used for cluster management, are required to be open on every node because they are essential to how Couchbase Server communicates with itself. Other ports are used by individual Couchbase Services, and are only required to be open on the nodes where those services are running.

Couchbase Server uses a default set of port numbers for all ports that it requires. The Couchbase Cluster Manager on each node is responsible for port management, and will open and close these ports on the host as necessary, as well as automatically switch to using encrypted ports if the cluster is configured to use TLS. Most port numbers can be remapped to fit the requirements of your network environment, but some port numbers cannot be changed.

If other software on the same host is using any of the ports that are required by Couchbase Server, then Couchbase Server will not function properly and may fail to start. Refer to Port Availability below.

Ephemeral Ports

An ephemeral port is one temporarily allocated by a server’s operating system, as the source for an outgoing communication. Each operating system provides a default range of port numbers that can be assigned to ephemeral ports, when necessary. For Linux distributions, the typical range is 32768-61000. Couchbase Server relies on the full default range provided by each operating system: therefore, the default range should not be reduced by the administrator; since the resulting lack of ephemeral ports may result in outgoing communications using well-known ports instead (for example, 8091); thereby preventing Couchbase-Server processes from binding to the well-known ports to which they are assigned.

Couchbase Server Communication Paths

Couchbase Server components and services connect to each port over one or more communication paths. These paths are defined as:

Node-local: A Couchbase service running on a node connects to the port on localhost, and communication happens entirely within the node itself.
Node-to-node: A Couchbase service connects to the port on other nodes in the cluster.
Client-to-node: A Couchbase client, such as an application using the Couchbase SDK, connects to the port on the node that it requires access to.
XDCR (cluster-to-cluster): A source node connects to the port on a destination node of another cluster as part of an XDCR replication stream. (This is very similar to the client-to-node communication path.)

As of Couchbase Server Version 7.0, the XDCR protocol Version 2 (XMEM), which uses the Memcached Binary protocol, is the only XDCR protocol supported. Version 1 (CAPI), which used the REST protocol, is no longer supported. Refer to XDCR Advanced Settings for information about the XDCR protocol version and other advanced settings.

Each communication path used by a required port must remain open and unblocked by firewalls or other such mechanisms.

Port Availability

Neither the Cluster Manager nor any of the Couchbase Services will start if unable to listen on all required ports. Note that the cluster manager and all services attempt to bind to required ports using the IP address family that the Couchbase Server cluster is configured to use (see Manage Address Families). Therefore, if the Couchbase Server cluster is configured to use IPv6, the cluster manager and all services attempt to bind to required ports using IPv6; and if the cluster is configured to use IPv4, the cluster manager and all services attempt to bind to required ports using IPv4. If the cluster manager or service is unable to bind to one or more required ports using the configured IP address family, it will not start.

Refer to the Detailed Port Description, below, for a list of the ports required by each service.

Ports Listed by Communication Path

The following table lists all port numbers, grouped by category of communication path.

Table 1. All Couchbase Server Ports, Listed by Communication Path

Communication Path

Default Ports

Node-local only

Unencrypted: 9119, 9998, 11213, 21200, 21300

Encrypted: 21250 ^[1], 21350 ^[2]

Node-to-node

Unencrypted: 4369, 8091-8094, 9100-9105, 9110-9118, 9120-9122, 9130, 9999, 11209-11210, 21100

Encrypted: 9999, 11206, 11207, 18091-18094, 19102, 19130, 21150

Client-to-node

Unencrypted: 8091-8097, 9123, 9140 ^[3], 11210, 11280

Encrypted: 11207, 18091-18095, 18096, 18097

XDCR (cluster-to-cluster)

Version 2 (XMEM)
- Unencrypted: 8091, 8092, 11210
- Encrypted: 11207, 18091, 18092

If enforcing TLS encryption, these ports may be blocked outside of a Couchbase Server cluster but need to remain open between nodes.

Certain support and diagnostic requests may run against ports other than the administration port (8091). These are expected to execute locally on a node and so do not require external access.

Detailed Port Description

The following table contains a detailed description of each port used by Couchbase Server.

Table 2. All Couchbase Server Ports, Listed by Service
Port name	Default port number (un / encrypted)	Description	Node-to-node	Client-to-node	XDCR (cluster-to-cluster)
`epmd` ^[4]	4369	Erlang Port Mapper Daemon	Yes	No	No
`rest_port` / `ssl_rest_port`	8091 / 18091	Cluster administration REST/HTTP traffic, including Couchbase Web Console	Yes	Yes	Version 2
`capi_port` / `ssl_capi_port`	8092 / 18092	Views and XDCR access	Yes	Yes	Version 2
`query_port` / `ssl_query_port`	8093 / 18093	Query service REST/HTTP traffic	Yes	Yes	No
`fts_http_port` / `fts_ssl_port`	8094 / 18094	Search Service REST/HTTP traffic	Yes	Yes	No
`cbas_http_port` / `cbas_ssl_port`	8095 / 18095	Analytics service REST/HTTP traffic	No	Yes	No
`eventing_http_port` / `eventing_ssl_port`	8096 / 18096	Eventing service REST/HTTP traffic	No	Yes	No
`backup_http_port` / `backup_ssl_port`	8097 / 18097	Backup service REST/HTTP traffic	No	Yes	No
`indexer_admin_port`	9100	Indexer service	Yes	No	No
`indexer_scan_port`	9101	Indexer service	Yes	No	No
`indexer_http_port`	9102	Indexer service	Yes	No	No
`indexer_https_port`	19102	Indexer service	Yes	No	No
`indexer_stinit_port`	9103	Indexer service	Yes	No	No
`indexer_stcatchup_port`	9104	Indexer service	Yes	No	No
`indexer_stmaint_port`	9105	Indexer service	Yes	No	No
`cbas_admin_port`	9110	Analytics service	Yes	No	No
`cbas_cc_http_port`	9111	Analytics service	Yes	No	No
`cbas_cc_cluster_port`	9112	Analytics service	Yes	No	No
`cbas_cc_client_port`	9113	Analytics service	Yes	No	No
`cbas_console_port`	9114	Analytics service	Yes	No	No
`cbas_cluster_port`	9115	Analytics service	Yes	No	No
`cbas_data_port`	9116	Analytics service	Yes	No	No
`cbas_result_port`	9117	Analytics service	Yes	No	No
`cbas_messaging_port`	9118	Analytics service	Yes	No	No
`cbas_auth_port`	9119	Analytics service (node-local only)	No	No	No
`cbas_replication_port`	9120	Analytics service	Yes	No	No
`cbas_metadata_port`	9121	Analytics service	Yes	No	No
`cbas_metadata_callback_port`	9122	Analytics service	Yes	No	No
`prometheus_http_port`	9123	Cluster management traffic and communication	No	Yes	No
`backup_grpc_port`	9124	Backup Service gRPC	Yes	No	No
`fts_grpc_port` / `fts_grpc_ssl_port`	9130 / 19130	Search Service gRPC port used for scatter-gather operations between FTS nodes	Yes	No	No
`eventing_debug_port` ^[3]	9140	Eventing Service Debugger	No	Yes	No
`xdcr_rest_port`	9998	XDCR REST port (node-local only)	No	No	No
`projector_port`	9999 / 9999	Indexer service	Yes	No	No
`memcached_dedicated_port` / `memcached_dedicated_ssl_port`	11209 / 11206	Data Service and ns_server. Used for important control-commands; e.g. creation of buckets and vBuckets, and compaction.	Yes	No	No
`memcached_port` / `memcached_ssl_port`	11210 / 11207	Data Service	Yes	Yes	Version 2
`memcached_prometheus`	11280	Data Service	No	Yes	No
Cluster Management Exchange	21100 / 21150	Cluster management traffic and communication	Yes	No	No
Cluster Management Exchange ^[1]	21200 / 21250	Cluster management traffic and communication (node-local only)	No	No	No
Cluster Management Exchange ^[2]	21300 / 21350	Cluster management traffic and communication (node-local only)	No	No	No

Custom Port Mapping

Most, but not all, port numbers used by Couchbase Server can be remapped from their defaults to fit the requirements of your network environment. Refer to Table 2 for details about default ports and whether or not they can be remapped.

Changing the port mappings will require a reset and reconfiguration of any Couchbase Server node.

Changing port mappings should only be done at the time of initial node/cluster setup as the required reset and reconfiguration will also purge all data on the node.

To Change Port Mapping

Install Couchbase Server.
Stop the Couchbase Server service.
For most ports, you’ll need to edit the Couchbase Server static_config file. (This will be wherever you put the path to /couchbase/etc/couchbase/static_config in multi-node installations.)
```
vi /opt/couchbase/etc/couchbase/static_config
```
If you’re remapping the CAPI port (8092 / 18092) you’ll need to edit the /opt/couchbase/etc/couchdb/default.d/capi.ini file and replace 8092 with the new port number.
Add each custom port map entry on its own line, using the following format (enclosed in braces and terminated by a period):
```
{port-name, port-number}.
```
For example, to change the REST API port from 8091 to 9000, you would add the following line:
```
{rest_port, 9000}.
```
Once you’ve added all of your custom port mappings, save the file and close your text editor.
If Couchbase Server was previously configured, you’ll need to delete the /opt/couchbase/var/lib/couchbase/config/config.dat file and files in the /opt/couchbase/var/lib/couchbase/config/chronicle/ directory to remove the old configuration.
```
rm -rf /opt/couchbase/var/lib/couchbase/config/config.dat
rm -rf /opt/couchbase/var/lib/couchbase/config/chronicle/*
```
Start Couchbase Server.

Any ports not given a custom mapping in the static_config file will continue to be assigned their defaults, which are listed in Table 2.

1. The Cluster Management Exchange encrypted port 21250 is not currently used, but is reserved for future use.

2. The Cluster Management Exchange encrypted port 21350 is not currently used, but is reserved for future use.

3. The Eventing Service Debugger port eventing_debug_port (9140) is an internal port and is not supported for external access outside of the cluster. You should only use this port in your development environments.

4. This port cannot be remapped.