NEW! Subscribe to our email newsletter » NEW! Subscribe to our FREE email newsletter to receive updates »

Why is Amazon AWS not recommended?

Because its extremely complex, even for advanced teams. As with many services and tech that gets “trendy” with corporate and enterprise teams, it eventually gets mentioned on blogs and at conferences and the “smaller” guys start to repeat these recommendations, even though they don’t have much idea about them.

AWS is the perfect example. The majority of teams using AWS should not be using it. It is simply too complex to use (both technically, and the UI itself) to make sense for small agencies or independent developers. Plus, their customer support is horrible (or doesn’t even exist) for smaller accounts.

There have also been reports that AWS will randomly change the public IP address of your servers, meaning your website could suddenly go down, if you didn’t configure AWS the way they “say” with static IPs etc (although they never warn you about this, and the documentation is very poor).

There is also the problem where AWS does not support root SSH logins, meaning you have to setup your SSH keys before being able to login, and new users must do this too. Their default Linux user is named the OS name, e.g. “ubuntu” which makes configuration even more unstable and more of a headache when setting up new servers.

Simply put, AWS is focused on protecting their own network, and not really on small teams looking for performance or user friendliness. It makes more sense for corporate teams who need certain types of regulatory contracts, containerization, and internal networking… but 90% of teams really don’t need it and shouldn’t use it with all the other options out there.

How we maintain both HTTP and HTTPS mirrors

GitHub Pages is an awesome feature that came out a few years ago on GitHub to allow for basic, static-file HTML websites to be hosted free of charge on GitHub. It can be a bit confusing to understand in the beginning, because you must connect one of your repos to be used for a given […]

Native Staging Sites (Optional) In Subdirectory

For the past several weeks, SlickStack has been testing our new Staging Site feature and it is now live on all SlickStack installations. If you use another staging service or simply don’t use staging at all and wish to disable staging sites, simply change your ss-config options to be STAGING_SITE=”false” and it will later remove […]

Adminer Bundled For Easy MySQL Management

The very lightweight Adminer script is now included by default in all SlickStack installations, hosted as a single adminer.php file under the /var/www/meta/ directory. This “hidden file” approach means a cleaner public web root, and less room for attacks and exploits. It uses the Nginx alias feature to point requests to example.com/adminer to the /var/www/meta/adminer.php […]