When there is a sign that says “NO SWIMMING” there are alligators in the area, do you heed the warning, or just jump in and risk it all?
As someone that lived in the Sunshine State, I for one love alligators but respect them, and my policy is don’t bother them and they won’t bother you.
Don’t Feed the Alligators
True story: There was a fool in the Southern part of USA that told people at the local dock of a alligator infested waterway [Clear DO NOT SWIM signs], that he was going to jump into the marina’s waters as he wasn’t afraid of the alligators. The people pleaded with him not to do it as this was an insane act, but the fool did it anyway. As soon as he jumped in, the alligators attacked him, and he screamed and cried for help. Yet in horror, the people at the dock couldn’t help the fool as it was already too late.
The moral of the story is when there are clear signs of DO NOT, they are there for your own safety. Should you not heed them, then you do so at your own risk. This story and moral can also be applied to common sense web hosting practices, and I felt that I’d post the most common and most frequent of them here as a sign for you to follow so you don’t end up feeding the alligators. Cause if you do, don’t place the blame on anyone else but yourself for not heeding the warnings.
Common Sense DIY Web Hosting Tips for aMiSTACX on AWS
1. Do NOT upgrade themes, modules, or system files on a live production commercial server! If you break the server, and don’t have a backup, or can’t restore correctly and quickly, you can be losing customers and sales for hours, days, or even weeks. Just don’t take the risk!
A development environment is so easy to create. Just clone production, test on dev using a hosts file, and then when all is clear deploy to production. Plus when development is NOT in use, just stop it. No running = no billing, and EBS storage equates to pennies per month.
2. If you do want to feed the alligators, and attempt live updates on a production server, make sure you have a lifeline, and take full backups of the frontend and backend. This way you may get out of the swamp with only missing an arm or a leg, but not a full meal for the gators. Know how fast you can restore is also important.
3. Do NOT use 777 for file permissions – ever! 777 is only great for instant scratch-off lotteries and Las Vegas slots. If you see your developer attempting to troubleshoot an issue with 777 – fire them! Setting 777 means you have absolutely no clue of what you are doing, you have reached a point of desperation, and you are OK with letting everyone in the world [Bots, Scripts, and Humans] instantly attack your server and potentially gain full control. [A malware injection to a commercial site can easily cost you a couple of thousands of dollars to repair.]
4. Don’t override the default ubuntu user security model in relation to the www-data [user/group] of Apache and NGINX. It’s OK on a development server, but not on a production server. If you can’t connect with WinSCP or Putty, we offer a secure way through our Utility Server for Windows. WinSCP [SFTP] allows proper sudo security elevation that almost no other SFTP clients provide.
5. Stick with simplicity, and gravitate to complexity. When you are first starting off your business, keep things as simple as possible, prove your business model, then you can justify more complexity to increase business growth. We see so many customers wanting to use elaborate caching systems like ElasticCache, Elasticsearch, Auto Scaling, LoadBalancers, and they just don’t need them yet. Our t3-xlarge with S3 Titanium can handle more than 60K unique visitors per month. That’s just a CDN + aMiSTACX + S3 [RDS Optional]
6. Stay away from cheap developers, and countries known to hire slave labor programmers! In the end you absolutely get what you pay for! Does anyone really want to work for $3 – $5 dollars an hour and be considered an expert?
Image above: A real job hiring posting.
7. Do USE A51 to help manage your AWS environment. It comes with all aMiSTACX stacks, and really will be your eyes and ears for your AWS empire. It may also even help you reduce your operating costs. We also send out dashboard alerts for known issues or tips that are very useful.
8. Use 2 Factor Authentication [2FA, MFA] whenever possible. It’s an extra step that keeps the killer bots at bay. A51 can set 2FA, and our WordPress stacks include a free third-party plugin, and Magento has its own built-in.
9. Make sure AWS security groups have port 8080 and 22 restricted. In some cases, you don’t even need port 80 as you can use DNS to say “Always HTTPS“, and thus no traffic will not ever go to 80. That’s also why we don’t support certain dinosaur caching engines.
10. Keep your development server restricted at all times. Tell robots.txt to not allow search indexing, block or restrict all incoming ports, use a hosts file so DNS is not public. Use A51 to start/stop the servers and RDS only when needed. Why do all of this? Because the last thing you really want is all of your test data showing up on public searches. 😉
11. Stay away from free modules and plugins unless the company is very well established. Many free plugins on github or WordPress end up with as no longer supported or abandoned. Many are prime sources for exploitation by scripts. This goes back to item number 6. “You get what you pay for.”
12. Take time to fully read the aMiSTACX admin guide that came with your stack. All the tips and how-to-dos are there to save you time, and act as a general guide.
13. If you need help or have an issue, do the following: 1. Check our aMiSTACX KB first, 2. Try our Bot for the answer, 3. If all else fails, contact humans. 99.9% of the time the humans are going to just send you a link to an article, or tell you the information is in your stack guide.
14. Don’t launch advanced stacks and expect everything to work. Only launch what you can technically handle, or with comfortably learning. Stay within your skill-set, or be willing to learn, and while not expecting miracles. All our stacks work correctly when installed accordingly. Our videos are abbreviated, and only meant for a high-level overview, and not a replacement for technical experience or to replace our admin guides.
15. Don’t blame the stack, or our modules for performance issues. All of our modules and stacks are tested to a certain level of performance. 99.99% of the time performance issues with Magento and WordPress are due to poorly written 3rd party themes and modules. Even themes that are “highly rated” are still performance turtles. With a properly tuned Magento stack using a Luma theme and a CDN like Cloudflare and aMiSTACX S3 Titanium you can achieve below 2 second load times all day long, and have awesome manageability, scalability, and stability. [Demo]
16. Magento is a beast and has a learning curve. Please make sure you review all of our KB articles for theme installs and module installs, and most importantly obey the file permissions for user and group at all times. By keeping with the default web/php permissions model, and following our guides, you will have a much higher level of success.
17. Take a few minutes to leave awesome feedback for aMiSTACX on AWS Marketplace. Helping us helps you in return. As we grow, we continue to introduce new themes and modules that will help your business perform.
18. Migrate to aMiSTACX. If you are not yet an aMiSTACX customer, you’ll be much happier over here than with your current provider. We are not a cheap solution, but aim to be a premium economical performance solution. We offer simple, dependable, and performance DIY web hosting solutions for developers, business owners, and administrators.
19. If your developer(s) can’t figure out how to SSH or SFTP to AWS, do yourself a favor and get rid of them before you waste your money. AWS is probably now the largest hosting provider in the world. aMiSTACX even posts how-to-connect with SSH and SFTP, and AWS has this information posted too. And before you throw them into the alligator pond, please make sure port 22 is open for them 😉
20. Make use of our Utility stack for Windows! By far one of the best ways to run a secure project and help reduce connection issues. Simply set up an IDE like phpStorm, connect as a remote project, secure connections via Security Groups, and you basically can control when and who is doing your development work 24hrs a day!
21. Our recommendation is to use Matomo Analytics [We use Matomo.] over Google Analytics any day and everyday. Besides Big Brother not having access to all of your client access data, Matomo offers much more freedom and performance gains. No client-side scripts required! Yes, GA will slow your site speed for ALL of your pages, but Matomo can make use of Cloudflare APPs, and is handled by the CDN edge. That’s awesome and it works great 😀 and as a bonus we also offer Matomo on one of our G3 stacks.
If your developer(s) insists on working local, or downloading your code to their laptop/desktop – get a new developer! Period! How many laptops are stolen or hacked? How many have viruses? Why would should you risk your code and/or your customer data to a developer? Seriously!
How do you think the developer [Item 6.] can live on $3 – $5 dollars an hour? By selling your customer’s addresses, credit card info, and much more on the black market! That’s how. 😉 As we say in America, “There is no such thing as a free lunch”.
If your customers only knew what you are willing to do with their data – you wouldn’t have customers. Just DON’T DO IT!
Working local? “I’m just waiting for all of your delicious code and customer data!”
If having your code in the hands of some developer in some far off land at the edge of a laptop in some Internet cafe wasn’t enough to have you lose some sleep, then the headache of inconsistent environments will.
Devs that work local will not be able to mirror the actual live Dev server environment. No mater how you contain it or virtualize it, it won’t be the same. This leads to the infamous quote for broken code “it works on my local”. This just leads to a large waste of time, and ultimately a waste of money in order to troubleshoot these inconsistencies. Run your development like a Boss, and just don’t make this amateur mistake. Keep your devs in check!
21. Use a Password Manager like LastPass! There is absolutely NO excuse to use weak passwords, or the same passwords across sites. We use and recommend LastPass.
22. Block or restrict traffic from countries you do not do business with! If you are not doing business with China, then don’t let Chinese traffic hit your site. This is beneficial in many ways: no window shopping sucking up your resources, less bots or script attacks originating from those countries, and you really don’t need to inspire others to do what you are doing, right? Cloudflare and CloudFront both have provisions to block or challenge by country. Use it! Focus on providing better services to those that actually pay for your goods or services.
23. Don’t set an RDS instance to Public. Unless there is a real specific reason to set an RDS instance to “Public”, you shouldn’t. You are opening a hole in security, and making your system more prone to attack. Public is only required under certain circumstances. For management, all you need to do is launch your management tool in the same zone. E.g. Launching our Windows Utility Server w/ phpMyAdmin in the AWS Ohio Zone, and your RDS instance is in Ohio. In this situation, the public RDS option is NOT required. Just make sure the RDS Security Group is open for the utility server, and this will be the private IP EC2 address, and NOT the public EC2 address.
24. Read the admin guide for your stack. Every stack [Except Windows] comes with both an HTML version and a PDF version of an admin guide specifically written for that stack. It is very important that you review it prior to development or production. It covers many topics and answers many questions. And if you contact support with a question, more than likely it is either in the stack guide or in our KB section, and we’ll just send you a link or a page number to reference. Oh much faster if you check with our bot first.
25. Leverage Macey-Bot – Our bot, named Macey-Bot, is very useful. She can be reached from the A51 dashboard, from this link, and from the contact page. Be sure to bookmark, and please use correct sentence structure and ask in question format!
26. Change the default CMS username, password, and in some cases the email address for production aMiSTACX stack deployments. We use a standardized format, and in some situations use our own email address as a placeholder. Updating them to something unique helps make guessing and script attacks that much harder.
27. Be grateful and appreciate any personal help you may receive from our team. All of us appreciate NOT working weekends and holidays, and we love to get paid for our time. If you are tired of treading water, and we come by with a life preserver, please don’t demand a boat or a helicopter.
28. Avoid a Paradox Business Model. One of the biggest mistakes any business can make on the web [besides having devs working local], is creating what we call a Paradox Business Model. What does this mean? It is an extension of rule #5, keeping with simplicity. Many business owners add 3rd party modules, and pay for expensive marketing before they have a good track record of organic sales and organic SEO.
What happens is for every script that is added to your site, your store will slow down by X amount of seconds. For every second of additional load time, sales will decrease and your bounce rate will increase, and your cart abandonment may also increase. Couple this with expensive advertising campaigns, and paying 3rd party monthly subscription fees, and what you have accomplished is create a perfect Paradox Business Model.
Basically at this point you are paying others to track and send you more lost sales. If you still want to be in denial, and are not flexible in your thinking, basically this means [unless you have an infinite source of money to throw away] you will be bankrupt in so many days or months.
How to conquer the Paradox Business Model.
Simplicity + lean and mean. Make the fastest and most simplistic site for your customers using aMiSTACX. Keep load times under 3 seconds [ideally under 2], and avoid Google Analytics, go with Matomo, keep marketing to direct feeds [no tracking scripts], and focus on organic SEO. Keep payment options to a minimum! Many payment plugins slow the load times of ALL of your pages and put you back to the SLOW and NO GO Paradox.
We like to say, “Remove to Improve.”
Keep to a simplistic easy to manage web footprint. You don’t need a load balancer, auto scaling, NGINX, RDS, or even AWS S3 to prove your business can generate revenue. A simple aMiSTACX G4 LAMP and a free account on Cloudflare is all you need! As you sales grow and traffic grows you can gravitate to more exotic solutions, and thus justify the cost increases.
aMiSTACX: Here to Help those that Help Themselves
At aMiSTACX we like to say “Your success is our success”; however, if you fail to read our “DO NOT SWIM” signs, or just really don’t mind taking extreme risks, please don’t put us into a position of saying “Told you so”, or even “Sorry we can’t help you” as once you jump into the alligator pond, all we can do is watch. [Although our professional development team can bail you out for $100 per hour as we love to feed our own alligators :D]
We will probably continue to add to this list, but for now, use common sense, and please try not to feed the alligators.
We are a DIY hosting platform. We do NOT support any CMS directly [Except our in-house developed modules]. We DO occasionally take on select development and/or engineering projects, and work closely with our customers to ensure their success.
Our entire team works tirelessly to make sure you have the best and fastest products.