OneinStack: a shell installer for LEMP, LAMP and Java stacks

What OneinStack solves, and for whom

Standing up a web server by hand means compiling Nginx, choosing a database build, wiring PHP-FPM to the right socket, and repeating that on every machine. OneinStack replaces that with a set of shell scripts. The repository describes itself as a script written in shell to quickly deploy LEMP, LAMP, LNMP, LNMPA or LTMP stacks, and the target is a 64-bit Linux host running RHEL 7 through 9 (including CentOS, RedHat, AlmaLinux, Rocky and Anolis), Debian 9 through 13, Ubuntu 16 through 24, TencentOS 3 to 4.4, openEuler, Kylin or Fedora 27 and later. That list is the practical boundary: if your distribution is not on it, the installer has no supported path.

The audience is narrower than the tag list suggests. This is for the person who owns a VPS or a dedicated box and wants the same stack shape on each rebuild, not for a platform team orchestrating fleets. The install is a source compile, which means a working compiler toolchain and enough patience for a build that can run for a long while on a small instance. In exchange, the versions are pinned by the script and the layout is predictable across machines.

How the installer is structured

The top level of the repository is the map of the tool. install.sh is the entry point, options.conf holds the choices, and the rest are task-specific scripts: addons.sh for PHP extensions, vhost.sh for virtual hosts, pureftpd_vhost.sh for FTP users, backup_setup.sh and backup.sh for backups, upgrade.sh and uninstall.sh for lifecycle, and reset_db_root_password.sh for the database root credential. config/, include/, init.d/, src/ and tools/ hold the supporting pieces that those scripts read and write.

The mechanism is a source compiler installation. The README states the stack is compiled from source, that the most stable source is the latest version, and that downloads come from the official site or high-speed mirrors. That choice explains the version breadth: the README lists MySQL 9.7 LTS down to 5.5, MariaDB 13.0 down to 5.5, Percona 8.0 down to 5.5, PostgreSQL 18.6, ClickHouse and MongoDB; PHP 8.5 down to 5.3; Nginx with native HTTP/3 and QUIC, Tengine, OpenResty, Caddy and Apache; Tomcat 11 down to 7; OpenJDK 8, 11, 17 and 18. Supporting services are handled the same way: Valkey or Redis, Memcached, Node.js, Pure-FTPd and phpMyAdmin are installed on request, and Jemalloc is available to optimize MySQL and Nginx.

Two design details matter more than the version list. First, options.conf is read before install.sh runs, and the README says to modify it if you need different installation, data storage or Nginx log directories. That makes the file the single source of truth for the layout, and it means the layout decision happens before anything is compiled. Second, the installer expects to run inside screen. The README gives screen -S oneinstack before the install and screen -r oneinstack to reconnect if the connection drops. That is an honest admission that the build is long enough to outlive an SSH session.

Installing it and adding a first virtual host

The README splits installation by distribution. On CentOS or RedHat, install wget and screen first:

yum -y install wget screen

On Debian or Ubuntu the equivalent is:

apt-get -y install wget screen

Then download the archive from the project mirror, unpack it and enter the directory. The README gives exactly this sequence:

wget https://mirrors.oneinstack.com/oneinstack.tar.gz
tar xzf oneinstack.tar.gz
cd oneinstack

Before running the installer, open a screen session so a dropped connection does not kill the build:

screen -S oneinstack

If you need to change the installation directory, the data storage directory or the Nginx log directory, the README says to edit options.conf before running install.sh. Then start the install:

./install.sh

After the stack is up, the first real task is a virtual host. The README gives vhost.sh for adding one and vhost.sh --del for removing it:

~/oneinstack/vhost.sh

What you should see is an interactive prompt that collects the domain and related settings, then writes the host configuration. The README also documents Let's Encrypt SSL and DNS-01 wildcard certificates through Cloudflare, Aliyun DNS and DNSPod with automated renewal, so certificate setup is part of that same flow rather than a separate manual step. If you need a second PHP version alongside the first, the README gives install.sh --mphp_ver 54, and addons.sh for extra PHP extensions.

Where OneinStack is the wrong tool

The clearest limitation is the install model. Everything is compiled on the target host, so the first run is long, CPU-heavy and dependent on the mirror staying reachable. There is no documented offline bundle, no container image, and no rollback path: the README documents upgrade.sh and uninstall.sh, but it does not document reverting a single component to its previous version after an upgrade. If you need atomic, reversible deployments, this is not the mechanism for it.

The second limitation is scope. OneinStack manages one host. The README describes backup targets including local storage, rsync between servers, Aliyun OSS, Qcloud COS, UPYUN, QINIU, Amazon S3, Google Drive and Dropbox, which covers moving data off the box, but it does not describe configuration management across many boxes. If you already run Ansible, Terraform or a container platform, adding a shell installer underneath that creates a second, competing source of truth about what is installed.

The third is the surface area of the script itself. A tool that runs as root, downloads source archives, compiles them and rewrites service configuration is a high-privilege operation, and the README's security section is a single line: "Some security optimization." That is thin. It does not say which kernel parameters, which file permissions, or which service hardening is applied. Anyone deploying this should treat the resulting host as one they still need to audit, rather than one that arrives hardened.

How it differs from a container or package-manager approach

The nearest alternative in spirit is a distribution's own package manager with a configuration tool on top. The difference is version control. Debian 12 ships one PHP version in its repositories; OneinStack lets you pick from PHP 8.5 down to 5.3 and install a second one beside it with install.sh --mphp_ver 54. That matters when an application is pinned to an old runtime and the distribution has moved on. The cost is that you now own the upgrade path for every one of those components yourself through upgrade.sh, rather than receiving security patches from the distribution.

A container-based deployment solves the same version-pinning problem differently. Images are immutable, rollback is a tag change, and the host stays clean. What it does not give you is the OneinStack layout: a conventional /usr/local style install with systemd units named nginx, mysqld, php-fpm, httpd, tomcat, pureftpd, valkey-server, redis-server, memcached and clickhouse-server, all managed with systemctl. If your operational habits, monitoring or runbooks assume those unit names and that filesystem layout, a container platform is a bigger change than it looks. The honest comparison is that OneinStack optimizes for a familiar single-host server, and containers optimize for replaceability. Pick based on which of those two you actually need.

Maintenance, upgrades and licence

The repository is not archived, and the last push was on 2026-09-28. Releases are infrequent rather than continuous: V2.8 on 2026-09-17, V2.7 on 2025-03-04 and V2.6 on 2023-07-16. That cadence is worth reading carefully. Between V2.6 and V2.7 there is roughly twenty months, and between V2.7 and V2.8 roughly eighteen. A project that ships a major tag every year and a half is not one where you should expect a same-week fix for a newly disclosed CVE in one of the bundled components. The upgrade script exists, but the responsibility for running it on a schedule is yours.

The README documents the upgrade and uninstall entry points:

~/oneinstack/upgrade.sh

and

~/oneinstack/uninstall.sh

Backups are configured separately, with backup_setup.sh for parameters and backup.sh to run one immediately. The README shows adding the latter to cron for a daily 1:00 run:

0 1 * * * cd ~/oneinstack/backup.sh  > /dev/null 2>&1 &

On licensing: the repository is Apache-2.0. That covers the scripts in this repository. It does not cover the components the scripts download and compile, which carry their own licences, and it does not cover the project's own website, which the README links separately. If you redistribute a server image built with this tool, check the licence of each bundled component rather than assuming the Apache-2.0 header settles it. This is a description of what the repository states, not legal advice.

Editorial conclusion

OneinStack suits operators who want a source-built, version-pinned web stack on a single 64-bit Linux host and who are comfortable running shell scripts as root. It is the wrong choice if you want container images, a control panel with a web UI, or unattended upgrades you do not have to think about. Before committing, read options.conf and confirm the install, data and log directories, because the README says those paths must be changed before install.sh runs. Then verify the mirror URL for oneinstack.tar.gz resolves from your network, since the whole install depends on that download.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. oneinstack/oneinstack on GitHub
3. Project website
4. README
5. Releases