Introduction

Running Spring Boot with two ports is a common pattern when you want to separate application traffic from management or migration traffic. The cleanest option is using a dedicated management port for Actuator endpoints. For advanced cases, you can add a second connector to the embedded server for full application routes.

Use a Dedicated Management Port First

If the goal is operational separation, configure management endpoints on a different port.

server.port=8080
management.server.port=8081
management.endpoints.web.exposure.include=health,info,prometheus

This keeps client traffic on one port and operations traffic on another, which simplifies firewall and monitoring policies.

Restrict Management Surface Area

A second port is useful only if access is controlled. Limit endpoint exposure and bind management interface appropriately.

management.endpoint.health.show-details=when_authorized
management.server.address=127.0.0.1

In container or cloud environments, pair this with network policy so only trusted sources can reach the management listener.

Add a Second Application Connector with Tomcat

When you need two full application listeners, customize embedded Tomcat.

1import org.apache.catalina.connector.Connector;
2import org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory;
3import org.springframework.boot.web.server.WebServerFactoryCustomizer;
4import org.springframework.context.annotation.Bean;
5import org.springframework.context.annotation.Configuration;
6
7@Configuration
8public class PortConfig {
9
10    @Bean
11    public WebServerFactoryCustomizer<TomcatServletWebServerFactory> extraConnector() {
12        return factory -> {
13            Connector connector = new Connector(TomcatServletWebServerFactory.DEFAULT_PROTOCOL);
14            connector.setPort(9090);
15            factory.addAdditionalTomcatConnectors(connector);
16        };
17    }
18}

Now the same app responds on both primary and additional ports.

Validate Behavior on Each Port

After configuration, verify endpoint routing explicitly.

curl -i http://localhost:8080/api/ping
curl -i http://localhost:8081/actuator/health
curl -i http://localhost:9090/api/ping

Do not assume filters, auth rules, and headers behave identically on all listeners.

Design Port Roles Clearly

Document purpose of each port:

• Primary application traffic.
• Management and observability.
• Temporary migration or internal compatibility traffic.

Clear role boundaries reduce operational mistakes and make incident triage faster.

Consider TLS and Proxy Topology

If TLS is terminated by ingress or reverse proxy, verify scheme and forwarded headers for both ports. A common failure is securing one listener while leaving another exposed unintentionally.

For internal-only listeners, combine private network binding with cluster policy and service segmentation.

Deployment and Infrastructure Alignment

Two-port app configuration must match deployment manifests and load balancer setup. In Kubernetes, expose intended ports in service definitions and ensure health checks target the expected listener.

If infrastructure misses one port, local tests may pass while production routing fails.

Monitoring by Port Purpose

Build metrics dashboards per port role. You should see high controlled traffic on primary app port and predictable low traffic on management port.

Unexpected spikes on management port can indicate misrouting or probing and should trigger alerts. Port-level visibility makes it easier to isolate whether issue is app logic, health endpoint, or listener configuration.

Recommended Rollout Sequence

A practical rollout approach:

1. Add second port in configuration.
2. Restrict access with network and auth controls.
3. Verify endpoint behavior per listener.
4. Update dashboards and alerts per port.
5. Deploy gradually and monitor traffic shape.

This sequence reduces risk from exposing extra listeners.

Common Pitfalls

• Opening management port without tightening endpoint exposure.
• Forgetting to update firewall or load balancer for new listener.
• Assuming security filter behavior is identical across ports.
• Mixing public and admin traffic on one listener without policy boundaries.
• Validating only local environment and skipping deployment-level tests.

Summary

• Use management.server.port for clean app and admin separation.
• Add extra server connectors only when truly needed.
• Secure and validate each listener independently.
• Align app config with infrastructure listeners and policies.
• Monitor traffic by port role to improve operations and incident response.