OpenResty Manager: A Web Panel That Wraps OpenResty, Let's Encrypt and Docker in One Go Binary
Modern, secure, and elegant server control panel, alternative to OpenResty Edge and Nginx Proxy Manager.
At a glance
- What is it?
- Safe3/openresty-manager is a Go-based control panel that puts reverse proxy sites, free certificate issuance, host administration and a Docker app store behind a single web UI on port 34567. It is aimed at people who want OpenResty's behaviour without writing OpenResty configuration, and its AGPL-3.0 licence is the first thing to check before it goes near a commercial deployment.
- Who is it for?
- Adopt it if you run your own reverse proxy hosts and want certificate renewal, access control and a terminal in one place rather than three. Do not adopt it if your organisation cannot accept AGPL-3.0 obligations, or if you need the panel to manage a proxy layer you did not install.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 27 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap It Fills Between Nginx Config Files and a Managed Edge Service
Running OpenResty directly means editing configuration, reloading the service, and remembering that a certificate renewal hook has to fire before the cert expires. The README positions OpenResty Manager as the open source alternative to OpenResty Edge, and the feature list reads like a direct answer to that chore list: access control, HTTP Flood protection, identity authentication, and automatic application and renewal of free SSL certificates, all without needing to know much about OpenResty or Let's Encrypt. The stated audience is people running reverse proxy websites at home or on the internet. That phrasing matters. This is a panel for an operator who owns the machine, not for a platform team provisioning proxies for other people. The topics list confirms the framing: home-server, self-hosted, sysadmin, webmin, cockpit. If your proxy layer is already generated by Terraform or an internal platform, the panel duplicates work you have already automated.
What the Panel Actually Manages: Sites, Upstreams, Certificates, Nodes
The README's quick start walks through the object model in order. Certificates are added first, either by applying for a Let's Encrypt certificate or uploading an existing one. Upstreams come next, described as load balancing targets for installed applications. Sites are created last, and a site is where you enter the domain names to be reverse proxied. That ordering is not arbitrary: a site references a certificate and an upstream, so both must exist before the site can be saved. The multi-node CDN path reuses the same primitives at a larger scale. You create a node group with domain resolution enabled, install OpenResty Manager on additional servers to act as CDN nodes, register those nodes on the primary server, and assign them to the group. A CNAME record then points the public hostname at the group's resolution domain, and the Node Manager menu synchronises sites out to the child nodes. The README does not describe the sync protocol, whether it is push or pull, or what happens to a node that is offline during a sync. Treat the CDN feature as something to verify on your own topology rather than something the documentation explains.
Installing It: Two Scripts, One Management Port, One Default Password
There are two installation paths, both one-liners. The host version is `sudo bash -c "$(curl -fsSL https://om.uusec.com/installer.sh)"`, after which the service is controlled with systemctl, for example `systemctl stop oms`. The container version is `sudo bash -c "$(curl -fsSL https://om.uusec.com/docker_installer.sh)"`, and afterwards `bash /opt/om/om.sh` handles starting, stopping, updating and uninstalling the container. The README warns that servers behind cloud providers need TCP ports 80, 443 and 34567 opened. It also carries a prominent warning that users in China should install from the Chinese site at om.uusec.com/cn, because the international installer may not work there. Two operational details deserve attention. First, the management interface is served on 34567 over HTTPS, and the default credentials are admin and #Passw0rd. That password is published in the README, so it is a known value on any host that has just been installed and not yet reconfigured. Second, both installers are fetched from a remote URL and piped into a root shell. That is normal for this category of tool, but it means the installed version is whatever the server serves at the moment you run it, not a version you pinned.
The Default Credential and the Root-Level Surface Are the Real Risks
A control panel that manages OpenResty, exposes a web terminal, and browses the filesystem is, by construction, a high-value target. The README lists host management with a web-based command terminal and file management as a headline feature, and the app store is built on Docker Compose. Anyone who reaches the panel with valid credentials can plausibly reach the host. The default password is documented, so the window between installation and first login is the exposure window. The README does not state whether the panel forces a password change on first login, whether it supports two-factor authentication, or what the session model looks like. Those are the questions to answer before the panel is reachable from the public internet. The multi-node mode widens this further: the primary node holds credentials for every child node it manages, so the blast radius of a compromised primary is the whole CDN cluster. None of this is unusual for self-hosted panels, but it is the part of the design that the README treats most lightly.
AGPL-3.0 Is the Constraint That Decides Most Commercial Cases
The repository is licensed AGPL-3.0. The README's licence section is truncated mid-sentence, so the repository's LICENSE file is the authoritative text, not the README. The practical shape of AGPL-3.0 is that if you modify the software and let users interact with it over a network, you are generally expected to offer those users the corresponding source. Running an unmodified copy to reverse proxy your own sites is a different situation from embedding the panel in a product you sell. The distinction is fact-specific and depends on your jurisdiction and your deployment, so it is a question for your own counsel rather than something this article can settle. What can be said plainly is that AGPL-3.0 is a deliberate choice by the maintainer, and it is incompatible with the assumption that a control panel can be quietly folded into a closed product. If that assumption is load-bearing for you, the licence decides the evaluation before any feature does.
Where Nginx Proxy Manager Fits Differently
Nginx Proxy Manager is the obvious point of comparison, and the difference is in what sits underneath. Nginx Proxy Manager drives Nginx. OpenResty Manager drives OpenResty, which is Nginx plus the LuaJIT module and a bundle of Lua libraries. That extra layer is what makes the security features plausible: HTTP Flood protection and identity authentication in OpenResty are typically implemented in Lua at the request-processing stage, which is not something plain Nginx configuration can express without additional modules. So the two tools are not interchangeable at the same layer. If you only need hostname-to-upstream mapping with Let's Encrypt certificates, both will do it and the choice comes down to interface preference and licence. If you want request-level filtering and authentication handled inside the proxy, OpenResty Manager is targeting a capability that Nginx Proxy Manager does not claim. The README does not document how the access control and flood protection rules are configured or what their defaults are, so the depth of those features is something to inspect in the UI rather than take from the feature list.
Upgrade Path, Release Cadence and What to Check First
Recent releases are v2.4.4, v2.4.5 and v2.4.6, with the two most recent published a day apart in June 2026 and v2.4.6 following in August 2026. That pattern suggests active maintenance with occasional rapid follow-up patches, which is worth knowing when you plan an upgrade window. The container deployment has an explicit update path through `bash /opt/om/om.sh`, which is the cleaner of the two options because the management script owns the container lifecycle. The host deployment relies on systemctl for the oms service, and the README does not describe an upgrade command for that path, so a host install likely means re-running the installer. The README also does not describe a configuration export or backup mechanism. For a panel holding certificate private keys, upstream definitions and site routing, the absence of a documented backup route is the gap to close before you depend on it. Verify three things on a test host: that you can change the admin password and restrict access to port 34567, that certificate renewal actually fires on schedule, and that you can reconstruct your site definitions from something other than the running panel.
Editorial conclusion
Adopt it if you run your own reverse proxy hosts and want certificate renewal, access control and a terminal in one place rather than three. Do not adopt it if your organisation cannot accept AGPL-3.0 obligations, or if you need the panel to manage a proxy layer you did not install. Before committing, install on a throwaway host, change the default admin password, and confirm that the 34567 management port is reachable only from where you actually administer the box.
Community notes