How to Set Up High Availability (HA) and Upgrade Warpgate with PostgreSQL as the Database

[vjmax]

Hi,

I’m currently using Warpgate with PostgreSQL as my backend database, and I’m looking for guidance on two things:

High Availability (HA): What’s the best approach to set up HA for Warpgate? I am using PostgreSQL for the database and want to ensure that Warpgate is highly available with multiple instances, preferably behind a load balancer. Are there any best practices or tools (e.g., HAProxy, Nginx) to achieve this? Additionally, how should the Warpgate configuration and session data be managed across multiple instances?

Upgrading Warpgate: Could you provide steps or best practices for upgrading from one version of Warpgate to another while using PostgreSQL? Specifically, I want to know how to handle database migrations, any potential schema changes, and the general process to ensure a smooth upgrade with minimal downtime.

Thanks in advance for your help! Any advice or documentation would be greatly appreciated.

[Eugeny]

Multiple Warpgate instances can work with the same database at the same time without any need for synchronization, however if you put a load balancer in front of them, the load balancer has to provide session stickiness (TCP connection based for SSH/MySQL/Postgres and cookie based for HTTP) as session storage is local to each service.

As for database migrations, currently there is no provision for running mixed versions against the same database. When Warpgate service starts, it automatically applies any new database migrations that haven't been applied yet - so upgrading a cluster requires downtime.

[BornTKill]

Hi!

I have done a fast and shitty HA for my instances that are used by 20p for SSH mainly.

2 VM warpgate with sqlite backend (default) 1 active, 1 standby Both behind HAProxy Rsync warpgate datadir from active warpgate to standby instance.

Works well since 2years and simple to implement cause you don’t have to deal with DB HA :)

I know it’s shitty but it’s KISS. Migration is easier also. Stop rsync :)

[vjmax]

@Eugeny

Hi 👋,

I'm planning to deploy multiple Warpgate instances on AWS. I understand that Warpgate supports running multiple instances connected to the same database without requiring synchronization — which is great. However, I have a few questions regarding load balancer setup in AWS, especially when exposing multiple protocols.

Problem Warpgate exposes several TCP ports:

2222 → SSH

55432 → PostgreSQL

33306 → MySQL

8888 → HTTPS (UI/API)

In AWS, Application Load Balancers (ALB) support only HTTP/HTTPS , so I can only use ALB for the web UI. But what’s the best approach to expose the other protocols like SSH and database access?

My Understanding So Far If I use ALB, I can only expose HTTPS (i.e., UI/API on port 8888).

If I use NLB, I can expose all the necessary TCP ports (SSH, MySQL, PostgreSQL, etc.).

• With NLB, I assume I’ll need:
• One listener per port (2222, 33306, 55432, 8888)
• One target group per port, each forwarding to the respective port on the Warpgate instances.

❓ Questions Is my understanding correct that NLB is the recommended solution for exposing all Warpgate protocols?

Is it required to set up a separate listener and target group for each port (SSH, MySQL, PostgreSQL, HTTPS)?

How to handle these ports in LB.Do you recommend any best practices for setting this up in AWS

Thanks in advance! Looking forward to your input — or please correct me if I’m wrong.

[Eugeny]

@vjmax you're correct, you have to use NLB for all non-HTTP protocols. You do need separate target groups as the target group definition includes the target ports and those are different per protocol.

You could use NLB for HTTPS as well but that requires each instance to terminate SSL by itself and it's just easier to let ELB do that instead. Make sure to enable session stickiness so that the users don't get thrown between the instances.

NLB setup is pretty straightforward, I don't have any special tips to offer as for best practices

[vjmax]

@Eugeny

Hi , We’ve configured AWS NLB in front of two Warpgate instances to enable high availability. After attaching the instances to the NLB, both Warpgate servers continuously log the following error messages:

ERROR Session failed error=sudden disconnection ERROR Session failed error=Disconnected INFO SSH: Client session closed session=ccde5762-cf5f-4db1-919e-eefa6370750c INFO SSH: Closed connection session=ccde5762-cf5f-4db1-919e-eefa6370750c

These errors appear only when the Warpgate instances are registered in the NLB. If we remove the instances from the load balancer, the error logs stop immediately.Why is this happening? Is there any workaround?

[Eugeny]

Do they appear immediately without any actual client sessions? Could NLB be probing the ports and disconnecting? If you could grab a tcpdump of one of these connections I'll check if we could cleanly ignore these

[vjmax]

Yes, they occur immediately without any actual session being established.

Here's a tcpdump capture from one of our Warpgate instances behind the NLB:

08:04:55.929869 IP 172.31.95.231.38505 > 172.31.88.134.2222: Flags [S]
08:04:55.929895 IP 172.31.88.134.2222 > 172.31.95.231.38505: Flags [S.]
08:04:55.930435 IP 172.31.95.231.38505 > 172.31.88.134.2222: Flags [.]
08:04:55.930478 IP 172.31.95.231.38505 > 172.31.88.134.2222: Flags [F.]
08:04:55.931316 IP 172.31.88.134.2222 > 172.31.95.231.38505: Flags [.]