Skip to content

Networking and Load Balancing Updated 2026-05-29

Integrating Traffic Distributor with a running application

How to put the Traffic Distributor in front of an application that is already serving traffic on Stack Harbor PaaS — adding the second backend, swapping domains, swapping public IPs.

The hard part of putting Traffic Distributor (TD) in front of an existing application is not the distributor itself — it is the cutover. You have live users hitting a known endpoint, and the new entry point needs to take over without dropping connections.

This page walks through the two valid cutover paths, depending on how the application’s custom domain is bound.

The setup

We start with one environment running the application — call it primary-env. It already has a custom domain attached.

1. Stand up a second copy

You need a second backend for TD to route to. Two options:

  • Clone primary-env. The platform’s environment cloning feature gives you an identical copy with the same configuration and data already in place.
  • Create from scratch. Use the same topology and redeploy the application — appropriate when the data layer is external or already shared.

If you clone, walk through the configuration for hard-coded values — direct links, IPs, environment-name strings — and fix them for the cloned name.

Let’s call the second environment second-env.

2. Install Traffic Distributor

From the dashboard’s Marketplace, install Traffic Distributor and pass it both environments as backends. TD comes up as its own environment, ready to handle requests.

If your platform exposes multiple regions, migrate one of the two backends to a different region. That gives you genuine failover across hardware boundaries — one backend can be down and TD will keep serving from the other.

At this point TD is ready, but no traffic is reaching it yet. The application still serves from primary-env directly.

3. Move the entry point onto TD

To route real users through TD, the custom domain that points at primary-env needs to point at the TD environment instead. The right method depends on the DNS record type:

  • CNAME or ANAME → swap domains
  • A record → swap public IPs

Path A: Swap domains (CNAME / ANAME)

When the custom domain is bound by CNAME or ANAME, the platform’s Swap Domains feature handles the move in one step.

  1. In the dashboard, hover over primary-env and pick Settings.
  2. Under Custom domains, open Swap Domains and select the Traffic Distributor environment from the drop-down.
  3. Click Swap and confirm.

In a minute, the custom domain is bound to the TD environment. Both backends become reachable through that one domain, and TD’s routing rules decide which one each request lands on.

Path B: Swap public IPs (A record)

When the custom domain is bound by A record, the move requires changing the IP behind the domain. The platform offers two ways to do this.

Option 1: SwapExtIps via CLI

The cleanest cut. The CLI command exchanges the public IP between primary-env’s front node and TD’s NGINX balancer:

~/jelastic/environment/binder/swapextips \
  --envName primary-env \
  --sourceNodeId {primary-front-node-id} \
  --targetNodeId {td-balancer-node-id}

No DNS changes are needed — your A record still points at the same IP, and that IP now lives on the TD balancer. See the CLI: swap public IPs doc for the parameter reference and the restart behaviour.

Option 2: Manual A record update

If you would rather work in your DNS manager:

  1. Ensure TD’s NGINX balancer has a public IP attached. Copy its value from the dashboard.
  2. Open your DNS manager and update the A record so it points at the new IP.
  3. Wait for the previous DNS TTL to expire. Until it does, some resolvers will still hand out the old IP — that’s fine, those requests will keep hitting primary-env until the TTL flushes.
  4. Once traffic has fully migrated, detach the public IP from primary-env so you stop paying for an unused address.

Audit your application for hard-coded IP dependencies before cutting over — outbound integrations, allow-listed IPs, monitoring probes, anything that targets the old IP needs to learn the new one.

After the cutover

From this point on, every request to the custom domain hits TD first. TD applies whatever routing rule you configured — 100/0 for a pure proxy, ratio for A/B, primary-with-failover for high availability — and forwards to one of the two backends.

You can then add more backends, change the ratio, or run a blue/green release without touching DNS again.

See also