Private networking and TCP/UDP services

Applications in the same project on the same server can communicate using private hostnames and container ports. Keep databases and internal services private unless outside access is required.

Connect applications privately

Open the application’s Overview and copy its private hostname. Use that hostname and the service’s container port in the calling application’s configuration. The name works inside that project’s server network, not in your laptop’s browser or on another server.

Existing applications may need redeployment after the networking update before they join the project network. Applications retain outbound internet access.

Deploy a non-HTTP service

1. Choose TCP/UDP service as the application type.
2. Use a Docker image, or source with an explicit start command that stays running.
3. In the runtime step, find TCP/UDP networking and select Add service port.
4. Set the container port and choose TCP or UDP.
5. Leave Publish TCP/UDP ports externally off for a private service.
6. Add credentials and a persistent volume when the service requires them, then review and deploy.

Web services and static sites can also add separate service ports alongside their HTTP endpoint. Use a different TCP container port from the HTTP port.

Publish a service externally

Enable Publish TCP/UDP ports externally only when outside clients need access. Choose a stable external port from 10000–29999 for each configured service port. The endpoint uses the server IPv4 address and selected external port shown in the overview.

Allow only the chosen protocol, port and trusted source addresses in your provider firewall. Infralane does not change provider firewall rules. Use the service’s own authentication and TLS where supported; raw TCP/UDP traffic does not inherit HTTP-domain HTTPS.

The same external port and protocol cannot be used twice on a pool. A TCP mapping and a UDP mapping can share a number. Disabling publishing takes effect after a successful configuration deployment; remembered port numbers alone do not expose a port.

Readiness and troubleshooting

A running process alone may not prove a service is ready. Use an image healthcheck for private or UDP services when meaningful readiness is required. Check the deployment logs, internal listener, protocol, project and server placement before changing firewall rules.

If a published port conflicts, choose an available port and redeploy. If private DNS is missing, confirm both applications have been deployed on the same project’s server network. Moving a service to a different pool changes its server IP and requires rechecking endpoints and port availability.

For durable data and recovery, read Persistent volumes and backups. TCP/UDP service configuration is currently a dashboard feature, outside the MCP deployment schema.