Zoraxy: A Go-Based Reverse Proxy with a Router-Style Admin UI

What Zoraxy Solves and Who It Is For

The design philosophy is visible in the standalone mode, which the README compares to a basic home router. One account manages everything. That is a deliberate simplification, and it means Zoraxy is not built for multi-tenant or team-based administration out of the box. The external permission management mode exists, but it requires an upstream proxy to handle authentication, which shifts complexity elsewhere.

How the Proxy Core Works

The tool also includes redirection rules, which are separate from reverse proxy rules. This lets you do simple 301 or 302 redirects without creating a full proxy entry. The stream proxy for TCP and UDP extends the reach beyond HTTP, so you can forward raw protocols like SSH or game traffic. The README does not detail the internal routing table or matching priority, so you would need to consult the wiki for that level of precision. What is clear is that the proxy core is not a thin wrapper around another tool; it is a native Go implementation with its own configuration storage.

Getting It Running: Commands and Config

For Docker users, the README points to the /docker folder, but it does not give a docker run command in the main text. That is a gap if you prefer containers. The start parameters list includes -acmetestmode for ACME staging, -autorenew for the renewal check interval in seconds (default 86400), and -cfgupgrade to auto-upgrade config on breaking changes. There is also -noauth=true to run without authentication, which the README warns should only be used in a trusted environment or behind another authentication proxy. For Web SSH, you can enable loopback connections with -sshlb=true, which is off by default for security. These flags show that Zoraxy is configurable via command line, but the main configuration happens through the web UI.

TLS and ACME: Built-In but with a Maintenance Caveat

Zoraxy includes TLS and SSL setup and deployment, with ACME features like auto-renew. It supports SNI and SAN certificates, and DNS challenges for Let's Encrypt and a list of DNS providers via the lego library. This is a strong feature because it removes the need for a separate certbot or manual certificate management. The README shows an -autorenew flag for the check interval, so the tool periodically checks and renews certificates. However, the README also lists ACME integration as a section looking for a maintainer. That is a red flag: the feature exists, but the project itself signals that it needs active maintenance. The DNS challenge implementation is credited to a contributor, and the overall ACME integration is not listed as core-maintained. Before relying on it for production, you should test renewal in staging mode with -acmetestmode and verify that the certificates actually renew on schedule.

Limitations and Wrong-Use Cases

A wrong use case is high-availability or multi-node setups. The README does not mention clustering or shared state. Each Zoraxy instance appears to manage its own config and database, so running multiple instances behind a load balancer would require manual config synchronization. The load balancing feature exists, but it balances across backend servers, not across Zoraxy instances.

Alternatives and How Zoraxy Differs

Another alternative is Caddy, which also does automatic HTTPS and is written in Go. Caddy uses a Caddyfile or JSON config and has a more mature plugin ecosystem. Zoraxy differentiates itself by providing a graphical interface and a broader set of utilities like the uptime monitor and port scanner. But Caddy's automatic HTTPS is generally considered reliable and well-maintained, whereas Zoraxy's ACME integration is flagged as needing a maintainer. So if TLS automation is your top priority, Caddy might be more dependable.

Maintenance, Upgrades, and License

Zoraxy is licensed under AGPL-3.0. That means if you modify the source and deploy it as a network service, you must make your modifications available to users under the same license. For a homelab or internal tool, this is usually not a burden, but if you plan to embed Zoraxy in a commercial product, you need to be careful. The project has an active release cadence, with v3.3.4 released in August 2026 and release candidates in the weeks before. The README mentions a -cfgupgrade flag that auto-upgrades config if a breaking change is detected, which is a good sign for upgrade safety. However, the README also notes that some sections are community-maintained, and it explicitly lists ACME integration and logging as looking for maintainers. That means those parts may lag behind the core. Before upgrading, check the changelog, which is maintained by a community member, and test in a non-production environment. The project also states that it no longer accepts security advisories directly on GitHub, asking you to contact via Discord instead. That is a process constraint you should know before reporting issues.

Editorial conclusion

Adopt Zoraxy if you run a homelab or small multi-server setup and want a single binary that handles reverse proxying, TLS via ACME, WebSocket forwarding, and basic stream proxying without writing config files. Avoid it if you need granular per-route access control, advanced logging, or a mature plugin ecosystem, since those areas are thin or community-maintained. Before deploying, verify the ACME integration status, confirm your platform is supported (especially for Web SSH), and test the noauth mode only behind a trusted front-end proxy.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes