# SlickStack: a Bash-only LEMP provisioning script for single domain WordPress > SlickStack is a free Bash script that provisions and maintains a LEMP stack with WordPress on Ubuntu LTS servers, running on cron jobs that pull updates from the repository. It suits operators who want a self contained server with no Python or Docker runtime, and it deliberately refuses multi tenancy, clustering and a graphical interface. **littlebizzy/slickstack** — Lightning-fast WordPress on Nginx - Repository: https://github.com/littlebizzy/slickstack - Website: https://slickstack.io - Stars: 704 · Forks: 109 - Language: Shell - License: GPL-3.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/littlebizzy-slickstack ## What the script provisions when it takes over a bare server SlickStack is described as a free LEMP stack automation script written in Bash, built for WordPress provisioning, performance and security. The design goal is narrow and stated plainly: it is for a single primary domain per server, and it will never support installing multiple top level domains on one machine, and it will not include a built in user interface. The reasoning given is that this keeps the stack focused on speed, stability, security and predictable integration with third party management tools. The stack shape is conventional. Nginx sits in front, PHP runs through php-fpm, and MySQL is the database, with WordPress on top. Databases are named production, staging and development, and they exist depending on whether staging and dev sites are enabled. By default MySQL connects locally over TCP to 127.0.0.1:3306. Remote databases are possible, but the project states plainly that server clustering and load balancing are not a goal, and that the stack is aimed at simple, high performance WordPress servers rather than complex enterprise architecture. Sizing advice is concrete rather than vague. A basic WordPress site runs on 1GB or more of RAM, while 2GB or more is recommended for WooCommerce, Multisite, bbPress, BuddyPress, membership sites, forums and other dynamic or high traffic workloads. The installation guide also points at KVM cloud servers such as DigitalOcean, Vultr and Linode as the environment where the stack works best. ## The install is one wget and one bash run as root Because the installer is pure Unix shell, the whole provisioning step is a single command, and the assumption is that you already have a KVM cloud server on a supported Ubuntu LTS release, at least 1GB of RAM, and an SSH session logged in as root. The command downloads a script to /tmp and runs it: ```bash cd /tmp/ && wget -O ss slick.fyi/ss && bash ss ``` There is no package manager step before that, no agent, and no configuration file to author first. The pitch is weight: the project contrasts itself with heavier provisioning tools such as EasyEngine or Ansible, saying it requires no external runtimes such as Python or Docker. That difference has a real cost, which comes later in this article, but on the day you set the server up it means a bare Ubuntu box becomes a working WordPress host in one command. Supported releases are listed explicitly. The installer covers Ubuntu 18.04 through 24.04, and Ubuntu 26.04 is not supported yet. New installations should normally use Ubuntu 24.04, while 20.04 and 18.04 are legacy choices that need Ubuntu Pro or ESM for continued Ubuntu package maintenance. That is worth reading carefully, because an old LTS without a subscription gets no security updates from Ubuntu itself, and this script does not replace that channel. After the install, day two management happens through the bundled scripts in /var/www/, run with sudo bash. The project expects little hands-on work, because scheduled cron jobs connect to the repository and apply changes. ## ss-config holds the decisions that change the shape of the stack The configuration surface is a single file, ss-config, and there is a dedicated guide for it covering secure editing, schema migration, automatic tuning, pilot files, supported boundaries, rollback and troubleshooting. The tuning story ties back to the hardware rule: as a site grows, you can resize the server and run the installer again so that the stack reapplies optimized settings for the available resources. In other words, the configuration is not static text you maintain by hand forever. It is regenerated against the machine it finds. One decision in this file has an outsized effect. SlickStack installs a self signed OpenSSL certificate by default, and it is HTTPS only with HSTS enabled, so plain HTTP sites are not supported at all. The project advises that Cloudflare should be active on the domain before browsers will show the site as fully secure, because the certificate presented is not one Cloudflare trusts until Cloudflare terminates TLS in front of the server. If you would rather run Certbot with Let's Encrypt, the project says to change the settings in ss-config before the installation runs. After the first install completes, switching to Certbot and Let's Encrypt is possible, which is the order that avoids a failed first run. Two other defaults are worth stating plainly. There is no built in interface, so every administrative action goes through the bundled scripts. And HTTPS-only means a plain HTTP site is not a configuration option you can fall back to while debugging. ## The cron jobs make the GitHub repository the control plane SlickStack does not expect you to run a deployment pipeline. The repository is a directory of scripts, with crons/, bash/, modules/, languages/, docs/ and archive/ at the top level, and the installed server keeps scheduled cron jobs that connect back to the repository and pull changes. The idea is that the same mechanism that installed the stack also maintains it. That design has a clear upside. There is no server-side state to drift and no agent version to reconcile, because the server simply re-reads the upstream repository on a schedule. For an operator with one or a handful of boxes, that removes a class of work that configuration management tools still impose. It also means the upstream repository is part of your production trust boundary, and the mechanism is not something the project documents as reversible in detail. There is no documented pause switch, no pinning of a commit, and no way to freeze a known good version of the scripts, at least not in what the documentation describes. A stack whose control plane is a public repository that others can push to is a different risk profile from one you pin and review before applying. The project is not archived, and the last push was on 2026-08-25, so upstream is being worked on, but it also has no GitHub releases at all, which means there is no published release to pin against. ## Reinstallation rewrites the stack instead of repairing one service The command sudo bash /var/www/ss-install is the tool for both initial setup and later reconciliation, and the documentation is unusually clear about what rerunning it does. It is designed to reconcile the managed stack without deleting normal WordPress content, but it is a broad maintenance operation: it upgrades packages, rewrites managed configuration, may synchronize staging, truncates SlickStack logs, resets permissions, purges caches and restarts services. The project advises reading the Installation guide before rerunning it on production. The list matters for operations. A tool that purges caches and restarts services touches request paths for every site on the box, and a tool that truncates logs removes the evidence you would need to diagnose what went wrong during the same run. The Troubleshooting guide is described as a first response runbook that isolates edge, service, application, resource, access, cron, update and recovery failures while preserving evidence and using narrow repairs. The existence of that runbook implies the broad operation is not the right first move for a broken service, and the Commands guide distinguishes narrow operations from compound operations and lists destructive commands and known legacy or broken shortcuts. The trade-off is real, and it cuts both ways. You get a stack that heals itself, and you get a maintenance path that can be blunter than the problem you are trying to solve. ## The hard boundaries: one domain, no interface, no clustering Several of the sharpest limitations are stated as design intent rather than as missing features, which makes them easier to accept and equally easy to hit. Multi tenancy is out, so two unrelated sites on one server are not a configuration you will find. A built in interface is out, so every administrative task goes through the bundled Bash scripts, and any team used to a dashboard has to change how it works. Clustering and load balancing are out, so a high traffic site has to grow vertically by moving to a larger server. The documentation set also describes what SlickStack deliberately leaves to others. The Scope guide covers intended users, suitable workloads, managed boundaries, external responsibilities and non-goals, while the Architecture guide maps request flow, control plane, service boundaries, filesystem layout, environments, cache layers and generated configuration. The Roadmap guide lists current priorities, likely next directions, later possibilities, version support goals and explicitly rejected directions. That combination of an architecture map and a list of rejected directions is a good sign for a project that intends to stay small on purpose. Two operational limits follow from the model. The stack is single site by construction, which rules out running a portfolio of client sites from one host. And because HTTPS is mandatory with HSTS on, adding a domain before Cloudflare or a trusted certificate is in place is not a soft start. A stack that updates itself from a public repository is a poor fit for environments where configuration changes need a review and a sign off before they reach production. ## Where SlickStack differs from EasyEngine and Ansible The project names two comparison points itself, and the differences are about approach rather than about feature lists. EasyEngine is a heavier provisioning tool with its own runtime and more moving parts on the box, and Ansible is a general purpose configuration management system that needs Python and an inventory of hosts. SlickStack is a single Bash script that installs and then maintains one server, with no Python, no Docker and no host inventory. The real distinction shows up in the maintenance model. Ansible expresses desired state as tasks you run when you choose, against a list of machines, so each change is authored, reviewed and executed on your schedule. SlickStack instead installs cron jobs that connect to the repository and apply changes on a schedule, so the upstream repository plays the role that your playbooks play in Ansible. That is fewer concepts to learn and no separate control machine, and it is also less control over exactly what changes and when. For a single site on a single box with one operator, that trade is easy to accept. For a fleet, the inversion is uncomfortable: the repository is the source of truth for every server, and there is no published release series to pin. SlickStack covers its own reasoning in the Scope and Roadmap guides, and the choice of Bash only is deliberate rather than accidental, which tells you which workloads the project is actually shaped for. ## Conclusion SlickStack fits an operator who wants one domain per server, a self updating stack, and no Python or Docker on the box, and it does not fit a team that needs several domains on a host, a built in interface, clustered MySQL, or a repair tool that touches one service at a time. Before running it, read docs/ss-config.md and docs/installation.md, decide whether Cloudflare will sit in front of the domain, and confirm that your Ubuntu release is between 18.04 and 24.04, since 26.04 is not supported yet. ## FAQ ### How do I install SlickStack on a fresh Ubuntu server? Log in as root over SSH on a supported Ubuntu LTS server with at least 1GB of RAM, then run the download and install command from /tmp. The installer supports Ubuntu 18.04 through 24.04, and 26.04 is not supported yet. ### How do I get a trusted HTTPS certificate with SlickStack? By default the stack installs a self signed OpenSSL certificate and enables HSTS, so Cloudflare should be active on the domain first. You can set Certbot and Let's Encrypt preferences in ss-config before installing, or switch after the first install completes. ### Can SlickStack host multiple domains on one server? No. The project states that SlickStack is designed for one primary domain per server and will never support installing multiple top level domains on a single server. It also has no built in user interface. ### How do I update or repair a SlickStack server? Reinstallation through sudo bash /var/www/ss-install reconciles the managed stack without deleting normal WordPress content, but it also upgrades packages, rewrites configuration, may synchronize staging, truncates logs, resets permissions, purges caches and restarts services, so the Installation guide should be read before rerunning it in production. ### Does SlickStack need Python or Docker on the server? No. It is written purely in Bash, so it has no third party provisioning dependencies and needs no external runtimes such as Python or Docker, which is how it differs from tools like EasyEngine or Ansible. ## Sources - [Issues](https://github.com/littlebizzy/slickstack/issues) - [License: GPL-3.0](https://github.com/littlebizzy/slickstack/blob/master/LICENSE) - [littlebizzy/slickstack on GitHub](https://github.com/littlebizzy/slickstack) - [Project website](https://slickstack.io) - [README](https://github.com/littlebizzy/slickstack/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/littlebizzy-slickstack