Gately

English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Español | Français | Deutsch | Русский | Português (Brasil)

An open-source, auditable network gateway toolkit for home networks, NAS boxes, cloud hosts, and servers of all kinds. DDNS, STUN traversal, port forwarding, reverse proxy, certificates, WAF, and more ship in a single ~32 MB file, and existing Lucky configurations can be imported.

fnOS users: Gately ships as a native fnOS app. It plugs into the fnOS unified gateway, so it opens from the fnOS desktop icon and works over the same address you use for fnOS, including your remote domain, with no extra port to open. Once enabled, fnOS administrators can sign in directly with their fnOS session, without a Gately password or two-step code. See fnOS native app.

Gately is fully open source, so users and the community can read the source and the configuration directly. For software that sits on your network edge and holds your DNS keys and certificate private keys, open source lets you see exactly what it does. Gately's commitments:

• The source is released under Apache-2.0 and open to community review
• No connections to any project-operated server by default and no device information reported; third-party sign-in uses your own OAuth apps, with no relay in between
• Every outbound address (public IP lookup, STUN servers, and so on) is visible, editable, and can be turned off
• Configuration is plain-text JSON, so you can put it under git for auditing and rollback

Port forwarding with SNI routing plus Web Services can replace the common haproxy (TCP routing by SNI) + nginx (TLS and reverse proxy) pair. The numbers below compare the two on the same machine with the configuration of a real server: 90 domains routed by SNI, PROXY protocol v2 between the two hops, and an ECDSA P-256 certificate with TLS 1.3.

How it was measured:

• Host: Intel Core i5-13500T. Each stack was limited to 2 CPU cores (haproxy and nginx in Docker with --cpuset-cpus, Gately pinned with taskset) to match a small cloud server. Backends and the load generator ran on other cores.
• haproxy used mode tcp with req_ssl_sni rules and send-proxy-v2. nginx used worker_processes 2 and the proxy settings of the production site, which send Connection: upgrade and therefore open a new backend connection per request; a tuned nginx with upstream keep-alive would narrow the gap on small responses.
• Gately's path was the SNI rule, PROXY v2, then a Web Services listener, the same number of hops as haproxy → nginx.
• Each case ran for 10 seconds, and the cases that were repeated agreed within 3%. On a real 2 vCPU cloud host the static site served 5.5k req/s against 3.4k req/s. New TLS connections were on par (about 480–550 per second for both) when the client used X25519; with the post-quantum hybrid key exchange that Go clients and recent browsers offer, Gately completed about 13% fewer handshakes in that run.
• Results depend on hardware, configuration and traffic. Treat them as a sanity check that Gately keeps up with haproxy and nginx, and measure with your own workload.

Images are available for amd64, arm64, and arm/v7:

docker run -d --name gately --network host --cap-add NET_ADMIN \
  -v ./gately-data:/etc/gately \
  -v /var/run/docker.sock:/var/run/docker.sock \
  ghcr.io/wangwanjie/gately:latest

Open http://<device-ip>:16680 and sign in with the default account admin and the default password gately.cn. Then change the password and enable two-factor authentication under Settings. See deploy/docker-compose.yml for a complete Compose example.

If you forget the password or lose your authenticator, run gately reset-password or gately reset-totp on the server (docker exec -it gately gately reset-password for Docker); the change takes effect once you confirm. See Reset password and two-factor authentication.

Port forwarding, STUN, and web services listen on host ports, so --network host is recommended. If you do not need Docker management, drop the docker.sock mount. --cap-add NET_ADMIN lets Intrusion Prevention write bans to the host's nftables firewall; without it, bans still apply to Gately's own services.

Download the archive for your platform from Releases (Linux amd64/arm64/arm/mips/mipsle/riscv64, macOS, Windows, FreeBSD), extract it, and run:

./gately -c /etc/gately

Flags: -c sets the config directory (the GATELY_CONFIG_DIR environment variable also works), -listen overrides the admin UI listen address, -apply applies <name>.json files from a directory to the config directory on every start (GATELY_APPLY_DIR, handy for GitOps and Kubernetes; the account and token files cannot be overwritten), and -version prints the version. For unattended installs, set GATELY_INITIAL_PASSWORD to choose the initial admin password instead of the default gately.cn.

Service templates: systemd and OpenWrt procd. To verify downloaded archives and images (cosign signatures, build provenance, SBOM), see Verifying release artifacts.

Each Release ships offline .fpk packages for fnOS: gately_<version>_fnos_x86.fpk (Intel/AMD) and gately_<version>_fnos_arm.fpk (ARM). They are not in the official App Center, so install them manually: open App Center → Manual install (the button at the bottom-left), pick the file, and finish the wizard.

• Works with the fnOS unified gateway: click the Gately icon on the fnOS desktop and the admin UI opens through the fnOS unified gateway under /app/gately/, sharing the entry point you already use for fnOS. Both the LAN address and your remote fnOS domain work, with no need to open or forward port 16680. Access through the gateway is controlled by fnOS (only fnOS administrators can open it), so the safe entry and LAN-only settings apply only to direct access on port 16680.
• Signs fnOS administrators in with their fnOS session: turn on Settings → Access control → Sign in with fnOS and fnOS administrators who are signed in to fnOS enter Gately from the desktop icon without a password or two-step code; regular fnOS users still sign in. After you sign out, the login page offers a "Sign in as fnOS user <name>" button instead of signing you back in silently. The setting is off by default and only shown in the fnOS package.
• On the LAN the admin UI is also at http://<NAS address>:16680. The default account is admin and the default password is gately.cn.
• The app runs as root, so it can listen on 80/443, manage Docker through docker.sock, and open a real Web terminal. Install it only on a NAS you control.
• Config lives in the app's var directory and is kept on uninstall unless you choose "delete all" in the uninstall wizard. Upgrading is another manual install of the newer .fpk.
• The package also adds a gately command (/usr/local/bin/gately) for gately ctl and gately mcp.
• Port 16680 is shared with the Docker image. Stop the gately container before starting the native app.
• Verify the download as described in Verifying release artifacts; .fpk files are listed in checksums.txt.

Each Release ships OpenWrt packages: gately_<version>_openwrt_<arch>.ipk for OpenWrt 24.10 and earlier (including iStoreOS), installed with opkg install, and .apk for OpenWrt 25.12 and later, installed with apk add --allow-untrusted. Packages cover amd64 / arm64 / arm / mipsle / mips / riscv64; pick one by DISTRIB_ARCH in /etc/openwrt_release (see the table in the install guide).

• The service is enabled and started on install; the admin UI is at http://<router address>:16680, and the default account is admin with the password gately.cn.
• Config lives in /etc/gately and is kept across upgrades, uninstalls and firmware upgrades (sysupgrade). To upgrade, install the newer package; the online upgrade on the About page points you to the package manager instead.
• The binary is about 35 MB, so the packages suit x86 soft routers, ARM64 boxes and other devices with ample storage; the arm package needs ARMv7 with hardware floating point.

Create an API token with only the metrics:read permission and point Prometheus at /api/metrics. Metrics, alert examples and the Grafana dashboard are described in Monitoring.

Create a token on the "API Tokens" page of the admin console. You can create several, grant each read-only or read-write access per module, set an expiry, and the plaintext is shown only once, right after creation. Scripts can then call the admin API in bulk:

curl -H "Authorization: Bearer gtl_xxxx" http://localhost:16680/api/ddns/tasks

Account, two-factor authentication, and token management, as well as the backup, restore, restart, and system settings endpoints, accept login sessions only. All endpoints, required permissions, and data schemas are listed on the "API Docs" page of the admin console. You can also export them to docs/api/en (openapi.json and API.md) with make api-docs; the website https://gately.cn references them directly when published.

When upgrading from an older version, the previous global API token becomes a "legacy token" automatically (same value, full access to every module). Tighten its permissions or replace it with a new token on the API Tokens page.

These three modules manage the official external programs (automatic restart, logs aggregated in the UI). Gately does not bundle them, so you can always run the latest upstream release. Programs are located in this order: the path set in the module settings, PATH, then the bin/ subdirectory of the config directory. For Docker deployments, drop the binary into the mounted config directory, for example ./gately-data/bin/frpc; Tailscale needs both tailscale and tailscaled. Tokens and keys in config files are stored with 0600 permissions, and the cloudflared token is passed via an environment variable so it never appears in the process list.

See the migration guide. In short: under "Settings → Import from Lucky", choose the lucky_*.lkcf file from your Lucky config directory, preview it, then import. Imported rules are disabled by default; go module by module, disabling in Lucky and enabling in Gately.

Requirements: Go 1.26+, Node.js 24+, pnpm.

make web      # build the frontend (outputs to web/dist, embedded via go:embed)
make build    # compile bin/gately
make test     # go test -race ./...
make lint     # gofmt, go vet, frontend type check

For frontend development, run cd web && pnpm dev; /api is proxied to local 127.0.0.1:16680.

Some tests are skipped by default and need extra setup:

For the directory layout and technology choices, see docs/en/ROADMAP.md.

The website (gately.cn) source lives in website/ and is built with VitePress: cd website && pnpm install && pnpm dev; pnpm deploy:site builds and syncs it to the server.

• Lucky compatibility is based on publicly observable behavior, interfaces, and configuration formats. Do not submit code copied from Lucky binaries or frontend bundles.
• A new module needs a config schema with validation, runtime start/stop, REST endpoints, and unit tests. Modules that can be migrated from Lucky implement luckyimport.Importer; modules that want to show status on the overview page implement module.Summarizer.
• Code comments are written in Chinese; control statements must use braces.

Questions, feedback and usage tips are welcome in the Telegram group: t.me/gately_chat, or scan the QR code with your phone:

Please report bugs in GitHub Issues and attach a diagnostics bundle (Settings → Diagnostics); it is generated locally and contains no passwords, tokens, domains or real IPs.

Every Gately feature is free. If it helps you, you can sponsor development with USDT, Afdian or WeChat Pay; addresses and QR codes are on the sponsor page.

Apache License 2.0