Webinoly turns LEMP server setup into a few shell commands

A command set, not a control panel

Webinoly is described as production NGINX made simple, and the way it delivers on that is a set of commands rather than a dashboard. The project presents itself as one of the most reliable configurations for hosting websites, with the promise that you can deploy everything in a single step, and the overview makes clear that you can either install a complete LEMP stack or pick individual packages.

The audience is the person with a bare Ubuntu server and a deadline: a developer who needs to point a domain at a WordPress install, or an operator who would rather not hand-write an NGINX virtual host, request a certificate and wire up a reverse proxy route by hand. The project markets itself to PHP and web developers, and the topic list gives the shape of the stack it manages: NGINX, PHP and PHP-FPM, MariaDB and MySQL, Redis, Certbot and Let's Encrypt, plus fastcgi-cache, reverse proxy and WordPress topics.

The repository layout matches that description. The top level holds a lib directory, a templates directory, an usr directory and a single weby entry point, all in Shell, which is the pattern of a tool that ships its own library of functions and its own template files for the configuration it generates.

Ubuntu 26.04 or 24.04, arm64 or amd64, 512 MB of RAM

The requirements are short and strict, and they are the first thing to check. The operating system must be Ubuntu 26.04 or 24.04. The architecture must be arm64 or x86_64, which means both the small ARM cloud instances and the usual x86 servers are supported. Memory minimum is 512 MB.

That list narrows the audience in a way that is easy to miss. A Debian server, a Rocky Linux host or a container image you already run will not do, because the tool installs and configures the stack in the way those two Ubuntu releases expect. The same applies to the reverse proxy and WordPress paths: they are drawn from the same environment rather than being portable templates you can drop onto any distribution.

The documentation exists in English and Spanish at webinoly.com, and the project keeps its own site for that, with a separate documentation area, a contribute page and a premium area for discussions. The README itself is short, which is a signal in itself: the commands are the interface and the reference pages live on the project website, so expect to keep that documentation open while you work.

The installer runs from a pipe, with root, and that is the sharp edge

The quick start is three commands. The first installs Webinoly and builds the stack by piping a remote script straight into a root shell:

curl -sSL qrok.es/wy | sudo bash

The second creates a WordPress site for a domain:

sudo site example.com -wp

The third adds HTTP authentication:

sudo httpauth -add

Read the first command carefully before running it. A curl to a short URL piped into sudo bash means the content of that URL executes with full root privileges, and the short domain is opaque enough that you cannot tell from the command alone what it will touch on the machine. The repository is on GitHub and the project publishes a changelog there, so a cautious approach is to download the script, read it, and run it from the local copy instead of streaming it.

Every subsequent command is prefixed with sudo as well. The design is that the tool owns the server configuration, so it needs root to write NGINX configuration, to manage services and to place certificates.

WordPress gets the most attention, including the awkward installs

The site command is where most people will land, and the project has a dedicated set of WordPress tools rather than a generic CMS path. The feature list names subfolder install, external database, multisite and domain mapping, which are the four variations that break naive installers.

A subfolder install means WordPress living at a path such as a site directory rather than owning the whole domain. An external database separates the database from the application directory, which matters when the database lives on another machine or when you want to back the two up separately. Multisite and domain mapping are the harder cases, since a network install with many domains has a different certificate and virtual host structure, and those are the paths most worth testing before you depend on them.

For a plain PHP site without WordPress, the site command is the same shape without the -wp flag, and the reverse proxy route covers applications that are not PHP at all.

Caching, HTTP/3 and the reverse proxy for non-PHP apps

Performance is handled with three named components: FastCGI Cache, Redis Object Cache and HTTP/3 support. FastCGI Cache sits in NGINX and serves cached pages without touching PHP-FPM, while Redis Object Cache is the application-side cache that WordPress plugins talk to. HTTP/3 support matters for connections over QUIC.

The reverse proxy side covers what PHP cannot: the feature list states compatibility with Java, Node, React and Vue. In practice that means the tool can front a service that listens on its own port with an NGINX virtual host, certificates and the caching layer already in place, which is the part that most sites need and that most quick guides skip.

There is also an extras layer: a redirection manager, SMTP support and custom headers. The redirection manager is the piece that prevents a common early mistake, namely piling up a string of manual redirect rules in a configuration file while sites get renamed.

Certificates, HTTP authentication and what the A+ claim rests on

Security is handled by Free SSL through Let's Encrypt with Certbot in the dependency set, plus HTTP Authentication, which is what the httpauth command configures. The README states that the configuration gets an A+ grade on the Qualys SSL Labs test, and it is presented as an outcome of the default setup rather than something you switch on.

That claim is a starting point rather than a guarantee. A rating depends on the certificate chain, the ciphers and the protocol versions the server ends up presenting, and the tool can change those settings as you add sites, proxy hosts or custom headers. If you need the rating to hold, check the SSL Labs report after each change rather than trusting the default to survive your edits.

The related alternative is doing the same work by hand: installing NGINX, MariaDB and PHP-FPM through the distribution package manager, writing a virtual host file per site, obtaining and renewing certificates with Certbot on a timer, and then maintaining all of it on every new deployment. Webinoly's value is that the second half of that list is automated and consistent, not that the first half is possible.

Cloning, migration and a real-time log viewer

Operations are covered by three features: full site and server cloning and transfer tools, a real-time log viewer, and the backup and migration set. Cloning matters when you stage a copy of a production site for testing, and a transfer tool shortens the distance between two machines you control.

The monitoring piece is described as a real-time log viewer rather than a metrics dashboard, so it answers the question of what the server is doing right now rather than what it did over the last month. For a tool whose whole pitch is one-command deployment, being able to watch the NGINX and PHP logs while you make a change is a sensible pairing.

On maintenance, the project ships tagged releases. Version v1.21.3 was published on 2026-09-19, v1.21.2 on 2026-07-18 and v1.21.1 on 2026-06-27, and the last push to the repository was on 2026-09-19. The licence is GPL-3.0, which is worth weighing if you plan to modify the scripts and keep the changes private, since a derived script carries the copyleft obligations of the original. The project is primarily shell scripts and templates, so customising it means forking code rather than writing configuration.

Editorial conclusion

Webinoly fits a sysadmin or developer who wants a working NGINX and PHP server with certificates and a WordPress site in minutes, and who is comfortable running its commands with root privileges on a fresh Ubuntu machine. It does not fit an existing Debian or RHEL host, a container-only environment, or a team that needs to review every configuration change before it lands, since the tool writes its own NGINX and PHP configuration. Before you install, confirm the machine runs Ubuntu 26.04 or 24.04 on arm64 or amd64 with at least 512 MB of RAM, read what the piped installer does before letting it run as root, and check whether the WordPress path you need, such as multisite or domain mapping, is one the project already supports.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. QROkes/webinoly on GitHub
4. README
5. Releases