wangwanjie/gately

If you run a NAS or a home server and want a public domain plus HTTPS without stitching together haproxy, nginx, a DDNS cron script and a certificate renewal job, Gately offers one binary that covers those jobs. It is most compelling for people already juggling several small network daemons; it is also a young project with no long-term track record.

The problem

Before: exposing a service at nas.example.com means pointing a dynamic DNS record at your router, punching a port through NAT or UPnP, terminating TLS somewhere, and remembering to renew a wildcard certificate. Each step tends to be a separate tool with its own config format, and the reverse proxy has to know which backend owns which hostname. After: Gately sits at the network edge, discovers the public address, obtains certificates through ACME, and routes incoming TLS by SNI to the right internal target, so several services can share port 443. The result is one admin console and one config directory instead of several.

What's different

The distinguishing mechanism is SNI routing inside the port-forwarding module: TLS is passed through by domain name, with a default target and per-route PROXY protocol support. That is what lets a single inbound port serve many backends, which is normally the haproxy-plus-nginx combination. The README's performance table compares Gately with that pair on the author's machine (90 SNI domains, PROXY protocol v2, ECDSA P-256, TLS 1.3) and reports higher throughput and lower p99 latency, plus an HTTP/2 figure for Gately that was not measured for the nginx setup. Treat those numbers as the author's benchmark, not an independent result.

The breadth is the real trade-off. DDNS providers, STUN and UPnP/NAT-PMP traversal, ACME via DNS-01 or HTTP-01, Tailscale, frp client/server, a WAF and a web terminal all live in the same process. Pulling them together reduces moving parts, but it also means one tool holds your DNS keys and certificate private keys, and a bug in any module is a bug in the component at your network edge. The project argues that Apache-2.0 source and an editable outbound-address list make this auditable; auditing it is still work you have to do.

Who should try it

A good fit is a homelab or NAS owner who already runs a handful of services on one machine and wants hostname-based HTTPS routing without maintaining haproxy and nginx separately. The fnOS path is notably convenient: Gately appears as a native app and fnOS administrators can sign in with their fnOS session, without a separate Gately password. OpenWrt packages also make a router install plausible.

A poor fit is someone who needs a proven, widely deployed edge proxy with years of hardening, or who only wants one small feature such as DDNS. For a single service with a static IP, the integrated stack adds surface area without saving much. Also skip it if you cannot accept a new project as the thing holding your certificates and DNS credentials.

Requirements and limitations

The Docker route needs host networking, NET_ADMIN and a Docker socket mount, so the container has broad access to the host. The binary route needs a config directory, and the admin console starts with default credentials (admin / gately.cn) that must be changed, with two-factor authentication available in settings. API tokens are shown only once and can be scoped per module, which matters if you script against the admin API; account, backup, restore and restart endpoints accept login sessions only.

Ongoing care matters more than install: certificate renewal, DNS provider credentials and any SSH certificate-push targets need to keep working, and the fnOS .fpk packages are installed manually from App Center rather than through the official store. There is no documented independent security review or production track record in the supplied material.

HotRepo's take

HotRepo first tracked the project on 2026-10-24, when it was 9 days old. On 2026-10-25 it appeared on the NEW-REPOSITORY board (新项目榜, not the overall Trending board) at #5 with 362 total stars. That is a single dated snapshot; there is no comparable daily-board history, so persistence cannot be judged. The feature set is broad enough to deserve a look if the haproxy-plus-nginx replacement matches your setup, but before trusting it at the edge, verify the SNI routing and certificate-renewal behaviour for your own backends.