Nging ships two editions from one binary and installs as a system service

The install script takes a version, and the version picks your feature set

Nging is distributed as a single Go executable with an installer script. The automatic path downloads the script and runs it under sudo:

sudo wget https://raw.githubusercontent.com/admpub/nging/master/nging-installer.sh -O ./nging-installer.sh && sudo chmod +x ./nging-installer.sh && sudo ./nging-installer.sh

A mirror command from gitee.com is offered for networks inside mainland China. What matters is the script's argument list, which the README tabulates. Bare `./nging-installer.sh` or `./nging-installer.sh install` downloads the latest base version, `./nging-installer.sh install 5.2.6` pins a specific one, and `./nging-installer.sh up` or `./nging-installer.sh up 5.2.6` upgrades.

The parenthetical in the install row is the interesting part: if you need Docker container management, the recommendation is to install a version from the 5.3.x series, also called the pioneer edition, using `./nging-installer.sh install 5.3.2`. That makes the edition choice an install-time decision rather than a later toggle.

The releases confirm the pairing. The v5.3.5 tag is annotated as releasing v5.2.9 for the base edition and v5.3.5 for the pioneer edition, and v5.3.4.1 did the same for v5.2.8 and v5.3.4. Two products from one tag, and you pick the number.

Install, up, uninstall and un are the four operations the script supports, so lifecycle management never requires leaving the script.

Setup is a web page at localhost:9999 or an init command before first start

After the binary runs you point a browser at the setup page and configure the database plus the administrator account:

./nging init --user=root --password="root" --host="127.0.0.1:3306" --database=nging --adminUser=admin --adminPass="admin123" --adminEmail="[email protected]"

Nging supports MySQL and SQLite3. The SQLite form drops the user, password and host flags and takes a file path instead:

./nging init --type=sqlite --database="config/nging.db" --adminUser=admin --adminPass="admin123" --adminEmail="[email protected]"

The administrator password must be at least eight characters, which the flag documentation states in its placeholder description. Both routes have existed since v5.2.5 and v5.3.1 respectively, which matters if you are reading an older README.

The distinction between the two methods is timing. The web setup page at `http://localhost:9999/setup` is for an already running nging, and the `init` command is for before it has ever started, so on a fresh headless box the command is the only one of the two available.

Manual installation, when you downloaded a release tarball yourself, is extract, change directory, run the executable, granting execute permission on Linux first:

cd ./nging_linux_amd64
chmod +x ./nging
./nging

Docker is documented separately in `README_docker.md`, and the repository carries both `docker-compose-mysql.yml` and `docker-compose-sqlite.yml`, so both database choices are containerised rather than one being an afterthought.

Running at boot is a service subcommand with a port override

Persistence on boot is handled by a service subcommand rather than by a systemd unit you write yourself:

./nging service install
./nging service start

The full set is install, start, stop, restart and uninstall. The one that matters on a shared box is the port override at install time, since Nging defaults to 9999 and you can choose another with `./nging service install -p 9998`.

That detail matters more than it looks. The panel exposes SSH, FTP and a web terminal, so the port is a security decision, and moving it away from 9999 removes one scanner's favourite target without adding anything to your setup.

The container path hardcodes the default instead. The Dockerfile sets the entrypoint to the binary and the default command passes a port and a config path:

ENTRYPOINT [ "./nging" ]
CMD [ "-p", "9999", "-c", "myconfig/config.yaml" ]

The image is built FROM alpine with the release tarball copied in rather than compiled in place, so the container repackages the same executable instead of running a different build. A comment in the Dockerfile records the local test invocation with a mapped port, `docker run --rm -it -p "7770:9999" admpub/nging:latest`, which is the quickest way to see the panel before committing to an install.

The panel is Caddy and Nginx plus one plugin package per subsystem

The README describes Nging as a website service program for managing and configuring Caddy and Nginx sites, with practical surrounding tools attached: scheduled tasks, MySQL management, Redis management, FTP management, SSH management and server management. The topics list adds DDNS, FRP visualisation, cloud storage, WebDAV, offline download and file management.

The Go module shows how that is arranged. The module path is `github.com/admpub/nging/v5` and it requires one `nging-plugins/` package per subsystem, including caddymanager, collector, dbmanager, ddnsmanager, dlmanager, firewallmanager, ftpmanager and sshmanager, each at a 1.9.x version. The framework underneath comes from `github.com/coscms/webcore`, and there are commented out `replace` directives pointing at local paths for the same plugin packages.

That layout has a practical consequence. The plugin set is versioned separately from the panel, so a plugin can move to 1.9.x while the panel stays on a 5.2.x base line. The feature list is also a function of which plugins a given build included, which is worth remembering when you compare two installations of the same panel version.

The panel screens in the README cover what a day to day operator would recognise: login and two-factor verification, a dashboard with CPU and network charts, a system information page, a real-time status page, online file editing, adding a scheduled task, MySQL table management, system configuration and a console terminal.

Configuration lives in `config/config.yaml`, and the manual upgrade path depends on that file directly.

Upgrading by hand is five steps and starts with a backup

The README gives a manual upgrade procedure rather than only pointing at the script: back up the database and the old executable, stop the running old version, copy all files of the new version over the old directory, start the new version, then log in and check that the features work.

Copying over the old directory in place, rather than installing side by side, is why the backup comes first. There is no rollback inside the sequence itself, so the backup is the rollback.

There is also a migration note for anyone coming from V3, where the `caddy`, `ftp` and `download` blocks in `config/config.yaml` have to move into an `extend` block, with `ftp` renamed to `ftpserver`:

extend {
    caddy {
        // content omitted
    }
    ftpserver {
        // content omitted
    }
    download {
        // content omitted
    }
}

Older major versions live in separate branches. The README notes that V4.x, V3.x, V2.x and V1.x moved to v4, v3, v2 and v1 branches respectively, while the default branch here is `master` holding V5.

Development is current. The repository is not archived and its last push was on 2026-10-10, ahead of the v5.3.5 tag dated 2026-06-16. The module targets Go 1.26.1 and excludes a single redigo version, which is the kind of detail that matters if you build the binary yourself.

AGPL-3.0 and a panel that holds credentials to everything else

Two constraints deserve a decision before deployment.

The first is scope. This panel configures web servers, opens SSH and FTP sessions, manages MySQL and Redis clients, runs scheduled tasks and offers a web terminal. That is one interface holding credentials to everything else on the box, so the value of the tool rises with the number of subsystems you switch on and the exposure rises at the same rate.

The second is the licence. The repository is AGPL-3.0, which for a network service is the copyleft trigger: modify Nging, let others reach it over a network, and you owe them the corresponding source. Teams that deploy internal tools as opaque binaries should read that clause themselves rather than rely on a summary, and it is a reason to prefer the packaged release over a self-modified build.

A permission detail visible in the README screenshots is worth checking against your own setup. The mobile gallery includes a two-factor verification page next to login, so 2FA exists in the panel, and the mobile-first framing is consistent with a tool meant to be reachable when you are not at the machine.

Finally, the download links point at a vendor site rather than a release page on GitHub, while the source and the Dockerfile are in the repository, so building your own binary from source is the alternative if the hosted download does not suit your environment.

Editorial conclusion

Adopt Nging on a single small VPS or on a NAS and router where you want one login to edit site configuration and run scheduled jobs, since the panel plus the bundled tools covers that whole job. Do not adopt it as a multi-tenant hosting control plane, since the AGPL-3.0 licence and the single service installer point at a personal or small site operator. Before installing, decide deliberately between the base 5.2.x line and the 5.3.x pioneer line, because the command `./nging-installer.sh install 5.3.2` is the documented way to get Docker container management and no later command moves you between the two.

Frequently asked questions

Official sources

1. admpub/nging on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases