SlickStack [ss] - "Alpha"
SlickStack is a free LEMP stack automation script written in Bash designed to enhance and simplify WordPress provisioning, performance, and security.
➞ No email please! Post all questions & comments in our free Facebook group.
Table Of Contents
Much of modern computing history can be traced back to one thing: Unix. Indeed, one of the only things about web servers tbat hasn't changed in several decades is the Unix shell (Bash) command language. Keeping the same pragmatism and simplicity in mind that inspired LittleBizzy's managed hosting, SlickStack [ss] is coded entirely in Bash.
"Everything should be made as simple as possible, but not simpler."
— Albert Einstein
While there are clear benefits to programming languages like Python or Ruby, provisioning a server with WordPress isn't very complicated, and every Linux server comes with shell built into it. Let's not forget what happens when typical web agencies rely on advanced dependencies like Ansible... yikes! Onward, then...
SlickStack [ss] works best on VPS servers with KVM virtualization that have at least 2GB RAM from quality network providers such as Vultr, DigitalOcean, Linode, and other non-AWS networks. The underlying LEMP configuration is meant specifically for single-site WordPress installations, and does not support Multisite installs. SlickStack [ss] supports WordPress, WooCommerce, bbPress, and BuddyPress "out of the box" with pre-optimized settings that scale.
- Ubuntu 18.04
- Nginx 1.14.0 - custom
- PHP-FPM 7.2 - custom
- MySQL 5.7
- WordPress (latest version) - optional
- WP-CLI 1.5.1
- Redis 4.0.9 - tweak
- Monit 5.25.2
- Git 2.17.0
- UFW 0.35
Because it’s written purely in Bash (Unix shell), SlickStack [ss] has no dependencies and works on any Ubuntu Linux machine. Unlike heavier provisioning tools like EasyEngine or Ansible, there are no third party languages required such as Python, meaning a lighter and simpler approach to launching WordPress servers.
The below installation steps presume that you've already spun up a dedicated Ubuntu 18.04 VPS server (KVM) with at least 2GB RAM memory and that you are logged in via SSH.
- Create Nginx directory:
sudo mkdir /var/www/ && sudo chown root:root /var/www/ && sudo chmod 755 /var/www/
- Create /var/www/ss-config and input all SlickStack [ss] variables:
sudo nano /var/www/ss-config
(configure as desired)
- Run the SlickStack [ss] installation:
sudo wget -O ss slick.fyi && sudo chmod 755 ss && sudo bash ss
After completing the installation steps above, your
/var/www/ directory should look exactly as below. Keep in mind that you should never alter the crontab file on any SlickStack [ss] server, nor should you edit/modify any files appearing in the below list with the exception of
ss-config (this does not apply to WordPress files found under
/var/www/0-crontab /var/www/1-cron-often /var/www/2-cron-regular /var/www/3-cron-hourly /var/www/4-cron-daily /var/www/5-cron-weekly /var/www/6-cron-monthly /var/www/7-cron-sometimes /var/www/cache/ /var/www/html/ /var/www/logs/ /var/www/ss-check /var/www/ss-clean /var/www/ss-config /var/www/ss-config-sample /var/www/ss-install /var/www/ss-muplugs /var/www/ss-perms /var/www/ss-update /var/www/ss-worker
/var/www/html/ (WordPress) directory should look like this:
/var/www/html/wp-admin/ /var/www/html/wp-content/ /var/www/html/wp-includes/ /var/www/html/wp-...
...and if deploying as
/var/www/html/wp-content/mu-plugins directory should look like this:
/var/www/html/wp-content/mu-plugins/0-autoloader /var/www/html/wp-content/mu-plugins/cf-littlebizzy /var/www/html/wp-content/mu-plugins/delete-expired-transients-littlebizzy /var/www/html/wp-content/mu-plugins/disable-embeds-littlebizzy /var/www/html/wp-content/mu-plugins/disable-emojis-littlebizzy /var/www/html/wp-content/mu-plugins/disable-empty-trash-littlebizzy /var/www/html/wp-content/mu-plugins/disable-image-compression-littlebizzy /var/www/html/wp-content/mu-plugins/disable-xml-rpc-littlebizzy /var/www/html/wp-content/mu-plugins/error-log-monitor /var/www/html/wp-content/mu-plugins/force-strong-hashing-littlebizzy /var/www/html/wp-content/mu-plugins/header-cleanup-littlebizzy /var/www/html/wp-content/mu-plugins/index-autoload-littlebizzy /var/www/html/wp-content/mu-plugins/nginx-cache /var/www/html/wp-content/mu-plugins/remove-query-strings-littlebizzy /var/www/html/wp-content/mu-plugins/server-status-littlebizzy /var/www/html/wp-content/mu-plugins/virtual-robotstxt-littlebizzy
Outside of the so-called Application Layer, so much of the way computers and servers now work has been moved away from in-house teams and specialists and onto "the cloud" that terms like DevOps have become standard among recruiters, companies, and developers alike. Modern web development trends have begun to revolve entirely around concepts such as automation, APIs, cloud services, and beyond — a phenomenon we might refer to as Web 3.0.
While this shift is exciting, there is now a massive and growing disconnect between these emerging technologies and the humans that are expected to implement or benefit from them. Typical small business owners (SMBs), along with independent agencies or freelancers, now face a virtually impossible learning curve if they wish to maintain not only a competitive "webdev" edge, but even to keep up with basic standards in website security, etc.
"The innovation that this industry talks about so much is bullshit. Anybody can innovate. Don't do this big, 'Think Different' innovation thing. Screw that; it's meaningless. 99% of it is 'Get the work done.' That's my least favorite part of the technology news cycle: the constant innovation and new ideas, 'This will revolutionize,' all that hype – that's not where the real work is. The real work is in the details."
— Linus Torvalds
Telling these sorts of people to learn how to use Configuration Management (CM) tools like Ansible — or hire somebody who does — completely misses the point; it's the equivalent of telling someone who doesn't speak Spanish to go study Latin to better prepare for their exam, which happens to be tomorrow. Meanwhile, there's a cheeky student (e.g. Shopify or Wix) across the way, trying to sell them the answers (which look a bit shoddy).
While Silicon Valley "gurus" and corporations pump out new buzzwords (and SaaS services) on a daily basis, the typical small business website is still trying to figure out how to make their contact forms work correctly. The "legacy" shared web hosting monopolies — think EIG or GoDaddy — also have little motivation to education their audience, as perpetuating confusion seems to be a core pillar of their business model.
Before the likes of Google and Amazon and Shopify and Wix take over the entire web and turn it into Wall Street-backed website builders that feed into their private ecosystems, SlickStack hopes to bridge the knowledge gap between emerging technology and old-school web development to empower SMBs to achieve top notch website performance and security by offering a "controlled" LEMP-stack environment with limited options that is perfectly suited to the world's most popular open-source CMS: WordPress.
TL;DR: while "the wheel" might not need re-inventing, it can surely always be improved.
IDEALISM / SHOWBOATING #### GRAND CANYON OF DISCONNECT PRAGMATISM / SIMPLICITY #### ########################### ############################
Typical SMB owner thought process:
- Why is my website loading so slowly?
- Which web hosting company should I choose?
- What cache/security plugin is the best?
- When is my freelancer going to reply?
- @#$%! THIS... BACK TO SHOPIFY!
|Standard Shell Commands||Yes||No||No||No||No||No||No||No||No||No||Yes||Yes|
|Single Sites Focus||Yes||N/A||No||No||N/A||N/A||No|
Why don't use you env-vars? Teams who use GitHub repos to develop their sites (e.g. dev/stage/production branches) have started using env-vars with systems like Roots Trellis so that their entire codebase can be safely open-source. However, this requires defining the env-vars within the server stack (hidden from public root) so it's not so friendly for many agencies. Since our goal is to support "typical" agencies with mostly frontend knowledge, we felt that reflecting the WordPress setup was a simpler approach and so if using SlickStack there will be two config files (ss-config and wp-config.php)
But shouldn't configs be outside the public root? There's lots of "should" and theorizing in computer programming, but one reason for the success of WordPress is its pragmatism and user-friendliness. There's plenty to criticize about WordPress from the perspective of things like "12-factor apps" but let's remember that WordPress was around before many of these guidelines and even after better approaches have been founded, WordPress is still the king of CMS software for a reason.
Why ss-config-sample and not ss-config-example? Because we aim to mirror WordPress Core as much as possible. Because the misnomer has existed in WordPress since the beginning, the WP Core team has no intention of changing it.
Why don't you use TMPFS or similar? For stability reasons, we don't use any tpmfs (memory-based storage) for caching or otherwise, as it introduces more instability, possible data loss, and doesn't necessarily improve performance. What people people don't realize is Linux already uses tmpfs for its own purposes, and already stores many "requests" in RAM. Best to let the operating system do its thing, and we optimize the software packages installed.