OpenResty Manager: a Go control panel for OpenResty reverse proxies

The problem OpenResty Manager solves, and who it is for

OpenResty is a distribution of Nginx plus LuaJIT. It is fast and programmable, and it is also a configuration surface that most people do not want to touch by hand. The README frames OpenResty Manager as a way to secure reverse proxy websites running at home or on the Internet without knowing too much about OpenResty or Let's Encrypt. That is the whole pitch: you get the OpenResty runtime, but you drive it from a browser.

The intended audience is visible in the topic list: home-server, self-hosted, sysadmin, cockpit, webmin, 1panel. These are people running a handful of services on one box, or a few boxes, who want TLS certificates to renew themselves and who want a basic access-control layer in front of internal apps. The project positions itself as an alternative to OpenResty Edge and Nginx Proxy Manager, which tells you the comparison the maintainers expect you to make.

The scope is wider than a proxy UI. The feature list includes access control, HTTP Flood protection and identity authentication, certificate application and renewal, a web terminal and file manager for the host, a Docker Compose based app store, multi-node management, and distributed CDN caching. That is a lot of surface for one panel, and it is worth asking whether you want all of it. If you only need to put TLS in front of three containers, the extra modules are weight you will carry without using.

How it works: Go service, SQLite by default, OpenResty underneath

The repository layout is the clearest evidence of the architecture. There is main.go and service.go at the top level, a pkg/ directory, a service/ directory, and a frontend/ directory. The module is named om in go.mod, and the Go version declared there is 1.24.1. So the panel is a Go binary serving an API, with a separate frontend build, and the control logic lives in the Go service.

The persistence layer is chosen at build or configuration time. go.mod requires github.com/glebarez/sqlite v1.11.0 alongside gorm.io/driver/mysql v1.5.7 and gorm.io/driver/postgres v1.5.11, all under gorm.io/gorm v1.25.12. In practice that means a single-node install can run on an embedded SQLite file, while a multi-node deployment has a path to MySQL or Postgres. The README does not spell out which database the default installer picks, so treat that as something to confirm on your own install rather than assume.

The request path is the part that matters operationally. OpenResty Manager does not proxy traffic itself in the sense of terminating connections in the Go process. It writes configuration that OpenResty consumes, which is why the repository carries an nginx/ directory next to the Go code. Sites, upstreams and certificates are records in the panel database; the panel renders them into OpenResty configuration and reloads the server. That design is why a broken panel configuration can take your websites down with it, and why the README's uninstaller script is a blunt instrument rather than a per-site removal.

Other dependencies fill in the operational details. github.com/labstack/echo/v4 v4.13.3 with echo-jwt/v4 v4.3.1 handles the HTTP API and session tokens. github.com/pquerna/otp v1.4.0 is the two-factor authentication library. github.com/shirou/gopsutil/v4 v4.25.3 supplies host metrics for the dashboard. github.com/kr/binarydist v0.1.0 is a binary diff and patch library, which is the mechanism behind self-update. github.com/golang-jwt/jwt/v5 v5.2.2 covers token signing, and gopkg.in/natefinch/lumberjack.v2 v2.2.1 handles log rotation.

Installing OpenResty Manager on a host or in Docker

There are two installation paths, and the README is explicit that they are not interchangeable by region. Users in China are told to use the Chinese site at om.uusec.com/cn/ because the international installer may not work for them. If you are outside China, the host installer is a single command run as root.

sudo bash -c "$(curl -fsSL https://om.uusec.com/installer.sh)"

The script performs the installation and registers a systemd service. After it finishes, the README states you manage the service with systemctl, for example systemctl stop oms. The service unit name is oms, which is worth noting because the panel's own name and the service name differ.

If you prefer containers, the Docker installer is a separate script and produces a different management workflow.

sudo bash -c "$(curl -fsSL https://om.uusec.com/docker_installer.sh)"

After the Docker install, the README says the container is managed with bash /opt/om/om.sh, which covers starting, stopping, updating and uninstalling. That script is the only documented interface to the container lifecycle, so it is the file to read if you want to know what the installer actually did.

Once either install completes, the panel listens on port 34567 over HTTPS. The README warns that cloud servers must have TCP ports 80, 443 and 34567 open. You log in at https://your-ip:34567 with the default username admin and the default password #Passw0rd. Change those credentials before you expose the panel to anything.

The documented first-run sequence is short: apply for a Let's Encrypt certificate in the certificates menu, install an app such as WordPress from the app store, add an upstream for that app, create a site with the domain names you want reverse proxied, then point your DNS A or CNAME record at the server and visit the site. Removal is a single script.

sudo bash -c "$(curl -fsSL https://om.uusec.com/uninstaller.sh)"

The README describes this as one-click uninstallation completing in minutes. It does not document what happens to site configuration, certificates or container data, so back up anything you care about first.

Multi-node CDN: the feature that changes the deployment shape

Most panels stop at one server. OpenResty Manager documents a multi-node mode where additional servers run the same software as CDN child nodes, and the primary node pushes site configuration to them. The README lays out an eight-step flow, and the shape of it is worth understanding before you commit, because it turns a single-box tool into a small distributed system.

Step one is the DNS Manager, which manages third-party DNS records and needs a root domain for CDN CNAME binding. Step two creates a node group with domain resolution enabled and a domain such as cdn.uusec.com. Step three is installing OpenResty Manager on the other servers. Step four adds those nodes to the primary server and assigns them to the node group. Step five creates the actual reverse-proxied site. Step six adds a CNAME record pointing the site domain at the node group domain. Step seven synchronizes the site configuration to the child nodes from the Node Manager. Step eight is verifying that traffic actually routes through the CDN node.

The dependency chain here is real. The panel now needs API access to your DNS provider, network reachability between primary and child nodes, and a synchronization step that you must remember to run after site changes. The README presents this as a feature list, not a runbook. There is no documented conflict resolution for the case where a child node is offline during a sync, and no described mechanism for removing a node cleanly. If you run a single server, skip this entirely; it adds moving parts you will not exercise.

Where OpenResty Manager is the wrong tool

The default credentials are the first thing to fix, and the README puts them in plain text in the quick start: admin and #Passw0rd. That is a deliberate convenience for first login, but it means the panel is unsafe the moment it is reachable and unconfigured. If your install process does not include changing them, this is the wrong product for you.

The bigger limitation is the coupling between the panel and the running web server. Because the panel generates OpenResty configuration from its own database, hand-editing files under the nginx/ directory is not a supported workflow. The README never describes a way to import existing Nginx or OpenResty configuration. If you have years of tuned server blocks, this panel does not adopt them; you rebuild them as sites in the UI.

Rollback is undocumented. The README gives an installer and an uninstaller, and nothing in between. There is no described way to revert to a previous panel version, and no described backup or restore procedure for the panel database. The release history shows v2.4.4, v2.4.5 and v2.4.6, with v2.4.4 and v2.4.5 published a day apart in June 2026, which suggests rapid patch cycles. If your change-management process requires a tested downgrade path, the documentation does not give you one.

Finally, the feature list is broad enough that no single part is described in depth. HTTP Flood protection is named but the README does not state thresholds, algorithms or tuning parameters. Identity authentication is named without listing supported protocols. For a security-facing component, that gap matters: you cannot evaluate the protection from the README alone, and you should not deploy it on the assumption that the defaults are appropriate for an Internet-facing site.

How it compares with Nginx Proxy Manager

Nginx Proxy Manager is the obvious alternative and the one the topics list names directly. Both give you a web UI for reverse proxy hosts and Let's Encrypt certificates, and both are self-hosted. The difference is in what sits underneath and what else is bundled.

Nginx Proxy Manager drives Nginx. OpenResty Manager drives OpenResty, which means the LuaJIT layer is available for request-time logic that plain Nginx configuration cannot express. If your reason for choosing OpenResty is the Lua side, Nginx Proxy Manager is the wrong base regardless of interface quality.

The second difference is scope. Nginx Proxy Manager is a proxy and certificate manager. OpenResty Manager bundles a host terminal, file management, a Docker Compose app store, multi-node management and CDN caching on top of the proxy role. If you already have a terminal and a container workflow you like, that bundling is redundant, and you are accepting a larger attack surface for features you will not use. If you are setting up a fresh home server and want one interface for all of it, the bundling is the point.

The third difference is language and packaging. OpenResty Manager is a Go binary with an embedded or external SQL database and a systemd unit named oms, plus a separate Docker path. That is a different operational profile from a container-first Node application, and it matters for how you patch it. The Go dependency list here is current, with echo v4.13.3 and gopsutil v4.25.3, so the maintenance burden is on the application rather than on stale libraries.

Licence and maintenance cost

OpenResty Manager is licensed under AGPL-3.0. The practical consequence is the network clause: if you modify the software and let users interact with it over a network, the AGPL requires you to offer them the corresponding source. Running it unmodified to proxy your own sites does not trigger that obligation in the way a modified hosted service would. This is a description of the licence text, not legal advice; if you plan to embed the panel in a product, have a lawyer read AGPL-3.0 section 13 rather than relying on a summary.

Maintenance activity is visible in the release cadence. The most recent release is v2.4.6 on 2026-08-19, and the last push to the default branch was on the same date. Before that, v2.4.5 landed on 2026-06-09 and v2.4.4 on 2026-06-08. That is a roughly two-month gap between the June and August releases, with a quick patch pair in June. The repository is not archived.

Upgrade cost is where the documentation is thinnest. The Docker path exposes updating through bash /opt/om/om.sh, and the presence of github.com/kr/binarydist v0.1.0 in the dependency list indicates the panel can apply binary patches to itself. Neither the README nor the release notes describe a supported downgrade, a database migration policy, or what happens to running sites during an upgrade. If you operate this in front of production traffic, the upgrade step is the one to rehearse on a staging box first, because the panel and the web server restart together.

Editorial conclusion

Adopt OpenResty Manager if you already run OpenResty or want a single panel that covers reverse proxy sites, free certificates, host terminal access and a Docker app store, and if AGPL-3.0 fits how you distribute your work. Do not adopt it if you need a long-term support contract, a documented rollback path, or a panel whose configuration files you can hand-edit without fighting the UI. Before installing, confirm the three TCP ports (80, 443 and 34567) are reachable from where you will administer the box, and change the default admin credentials immediately after the first login at https://your-ip:34567.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. Safe3/openresty-manager on GitHub