# High‑availability in Kong: configuring primary/backup targets in a single Upstream

**URL:** <https://discuss.konghq.com/t/high-availability-in-kong-configuring-primary-backup-targets-in-a-single-upstream/13501>\
**Category:** Questions\
**Tags:** kubernetes, kong-gateway\
**Created:** [April 22, 2025, 5:41pm UTC](https://discuss.konghq.com/t/high-availability-in-kong-configuring-primary-backup-targets-in-a-single-upstream/13501 "2025-04-22T17:41:56Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ashakhba](https://avatars.discourse-cdn.com/v4/letter/a/958977/32.png) [@ashakhba](https://discuss.konghq.com/u/ashakhba)\
**Post date:** [April 22, 2025, 5:41pm UTC](https://discuss.konghq.com/t/high-availability-in-kong-configuring-primary-backup-targets-in-a-single-upstream/13501/1 "2025-04-22T17:41:56Z")

</div>

Hi team!

I’m evaluating high‑availability/failover strategies in Kong and would like advice on configuring a primary + backup target within a single upstream. In plain Nginx you can write:

```auto
upstream service-a-upstream {
  server service-a.namespace.svc.cluster.local:80;
  server service-a-backup.namespace.svc.cluster.local:80 backup;
}

server {
  location / {
    proxy_pass http://service-a-upstream;
  }
}

```

which gives automatic failover + auto‑recovery purely in Nginx.

In Kong, I see a few alternatives:

1. **Weighted targets + active healthchecks**  
Set weight 65535 for primary and 1 for backup, and enable healthchecks (backup still gets a small slice).
2. **Some custom plugin?**  
Maybe one already exists that understands “priority” or “fallback” semantics.
3. **KONG\_NGINX\_HTTP\_INCLUDE trick** with a custom server config?

```auto
# ConfigMap: servers.conf (loaded via KONG_NGINX_HTTP_INCLUDE)
#
# ───────── upstream groups ─────────
upstream service-a-upstream {
    server service-a.namespace.svc.cluster.local:80;
    server service-a-backup.namespace.svc.cluster.local:80 backup;
}
upstream service-b-upstream {
    server service-b.namespace.svc.cluster.local:80;
    server service-b-backup.namespace.svc.cluster.local:80 backup;
}
upstream service-c-upstream {
    server service-c.namespace.svc.cluster.local:80;
    server service-c-backup.namespace.svc.cluster.local:80 backup;
}

# ───────── unified fallback vhost ─────────
server {
    listen 8888;
    server_name kong-fallback;

    # --- Service A ---
    location /service-a {
        proxy_next_upstream error timeout invalid_header http_502 http_504;
        proxy_next_upstream_tries 2;
        proxy_pass http://service-a-upstream;
    }

    # --- Service B ---
    location /service-b {
        proxy_next_upstream error timeout invalid_header http_502 http_504;
        proxy_next_upstream_tries 2;
        proxy_pass http://service-b-upstream;
    }

    # --- Service C ---
    location /service-c {
        proxy_next_upstream error timeout invalid_header http_502 http_504;
        proxy_next_upstream_tries 2;
        proxy_pass http://service-c-upstream;
    }
}

```

Will this even work?

I might be thinking about this all wrong—any advice or suggestions are welcome!