What do I need to know in order the set-up web hosting for clients?

Posted July 4, 2016 10.4k views

Hello DOers,

I have learned a few things here on the DO community. Thus, I thank you.

Things I’ve learned:

  • Install LEMP on Ubuntu 14.04
  • Install wordpress & host wp websites
  • use server blocks with nginx

It was a struggle at times and I still don’t have the postfix email working correctly. Emails don’t get delivered sent by wordpress. (In case you have any tutorial links, please share :)

Since my websites aren’t getting any significant traffic nor handle any sensitive information, I have not learned nor set up any security for me server yet.

I’m considering teaming up with a wordpress web developer and also offer web hosting to them. My question:

What are the skills, systems and automations I need to consider before doing so?

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
4 answers


When it comes to web hosting, security is always Priority #1, so before diving in to the aspects of providing web hosting services to the public, a firm grasp of basic security principals is where you’ll want to start.

Understanding What You’ve Got

At their core, a Droplet, like any standard VPS, is a blank canvas. You’ve got a chunk of resources and you’ve got the OS – what you do with it and how you set things up is totally and entirely up to you. This applies to Dedicated Servers and Containers as well.

By nature, the security of the server and the OS is limited to what is provided by the OS distributor in their default configuration. These defaults aren’t meant to be all-inclusive nor provide maximum security for multi-user environments. You’re starting with next to nothing (you’ve got the OS, of course) and need to build from there.

Control Panel vs CLI

If you’re looking for a rather simple setup, installing a control panel such as cPanel or Plesk is going to be the route to take, with a few caveats.

1). Control Panels are not the end-all, be-all. Simply installing a control panel does not guarantee or ensure that your server is secure. Too many install cPanel and setup a few websites under the guise that cPanel provides a total security package – it doesn’t. If it were that simple, sysadmins that do business with web hosting providers would lose a decent chunk of their revenue, but they’re still here because at the core, cPanel is simply an overlay that runs as an application on top of the OS. You’ll still need knowledge of the CLI, Security and various other pain and pressure points, otherwise you’ll end up like many who simply install a control panel and run with it (hacked and at a loss).

2). Control Panels often require more resources, thus requiring you to deploy more resources than you would need if you were to manage things from the CLI. For example, cPanel will run on 512MB RAM and 1 CPU, though it’s going to struggle as you’re spreading that very thinly across Apache, MySQL, FTP, PHP and whatever else you choose to install. To start, 2-4GB RAM and 2-4 CPU’s is a base recommendation with 8-12GB RAM and 4-8 CPU’s being optimal for multi-site hosting and for handling traffic spikes. Even then, depending on the number of websites you intend on hosting, you may be better off with between 12-16GB RAM and somewhere between 8-12 CPU’s.

On the other hand, managing things from the CLI is going to be far less resource intensive, allows for far greater customization and prevents vendor-lock caused by the vendor requiring that you use their packages, their configuration and their scripts. You know where software is installed, you know what to edit, and you can modify to suit your needs. If you need “beta” software, which is often not widely supported by control panel distributors (think PHP 7.1.x), you can install it. Try that with cPanel and you’ll most likely break something unless the package you’re installing works well with their API (and OS repositories aren’t going to).

At the end of the day, the CLI wins, but there’s not a “real” GUI in terms of pretty graphics and one-click installers (unless you build a GUI to wrap around custom built scripts), so unless you write your own scripts, API interface and design your own streamline control panel that is resource-easy, you’ve got the terminal GUI and that’s what you’d need to use to manage software, edit configuration and setup websites.

Bash Scripting / Other Programming Languages

What I, as well as many others, find to be a better solution is Bash Scripting or scripting using your preferred programming language (anything that can run from the CLI – bash, python, PHP, NodeJS, python, C/C++, etc). Using your preferred language, you’d write a set of wrapper scripts to automate certain tasks such as creating user accounts (creating the user/group, home directory, etc), securing user accounts, security the system, etc. Using such scripts, you’re no longer entering commands by hand, you can simply ./scriptname.ext, or if setup to take on arguments, ./scriptname.ext -arg1 -arg2 and that script will run through the commands you’d normally run from the CLI.

For example (very basic at that), the following could be used on Ubuntu to update the repository packages, upgrade all out of date packages and then install NGINX.

#!/usr/bin/env bash

#+ 01). Clear Current Terminal Screen
#+ 02). Update / Synchronize Packages
#+ 03). Upgrade All Existing Packages (that have upgrades available)
#+ 04). Install NGINX

clear \
&& sudo apt-get update \
&& sudo apt-get upgrade -y \
&& sudo apt-get install -y nginx

#+ NGINX Base Directory:    /etc/nginx
#+ NGINX Configuration:     /etc/nginx/nginx.conf
#+ Starting NGINX:          service nginx start
#+ Restarting NGINX:        service nginx restart
#+ Stopping NGINX:          service nginx stop

To create the file from the CLI:

nano /usr/local/src/

Copy & Paste the content to the open file and hit CTRL + X and then type y to save. Now all you need to do is run chmod +x nano /usr/local/src/ to make it executable and you can now run it using:


… which will output what’s happening as each command is run.

Security – The TOP Priority

Security is a requirement, not an option. Failure to maintain proper security will eventually result in an incident that can range from someone logging in as a user (which should, by default, have very limited privileges) all the way up to someone breaking in and running something as simple as rm -rf /, which will result in the recursive deletion of files & directories, starting at the very root of your server.

In such a case, the OS is shredded and your configuration as well as your users data is gone. Unless you’ve properly planned and have backups readily available, there’s very limited recovery options (most of which are going to be very costly).

Recovering from backups will take time, but backups can reduce downtime and loss of revenue / trust, if they are up to date. Daily + Weekly backups are nice to have, but when it comes to business and any customer data, will day-old data suffice, or will it result in immediate losses?

When it comes to security, you have to think of the OS, the Software (PHP, MySQL, Apache, NGINX), and what you’ll be hosting (WordPress). Each piece of the puzzle is designed to be as secure as it can be, but software, like humans, isn’t perfect. If there’s a hole, someone will exploit it, so your job is to stay up to date on each piece of software you add to your server and in all reality, each piece of software you intend to allow your customers to host.

As @ryanpq said, WordPress is a major target. Way too many WordPress users fail to update, or refuse because the plugins they use simply won’t work because they’ve been abandoned by the author. You have to weigh your options in such a case. If what they use poses a security threat (i.e. has known, publicized security holes), it’s now your job to make one of the toughest calls. You can ask them to upgrade, force them to upgrade or if it’s an immediate threat, suspend the account or ask them to leave (politely and by describing why).

At the end of the day, you have to make the call as to whether one customer is worth potentially endangering the data of X, XX, or XXX+ others.

Sidenote: Even if you do go the control panel route (i.e. cPanel or Plesk), the same still applies. A control panel is still a piece of software that simply bundles other pieces of software together, puts a GUI between them and allows you to simplify some tasks. Even so, a control panel is not proper security maintenance, threat mitigation or even a solution designed to handle what all can happen.

Sorry for the rather large read. I’ve owned 4 web hosting companies/businesses and worked with ~50 others over the last 15 years (mostly private). It still amazes me how many go in to running a web hosting business thinking that once they’ve installed cPanel, their job is done. I don’t want others to make the same mistake.

  • Thank you for the large read :D I read every bit of it and have gained more clarity.

    One thing that’s hit home is that Security is Priority.

    Today, I actually found out and got how ssh works and had it installed. Prior I was just logging in via pw. I then spent the rest of the day trying to figure out how to use different key pairs for different droplets and different users. I found some tutorials online, but couldn’t get it to function. Ended up giving up for today.

    With that my question is, what is the most effective way to learn? With so many tutorials and guides on the web, is there a faster way to make the “right” mistakes? Any suggestions?

    • @rejkpp

      The best way to learn, IMO, is to make mistakes (on a private server, of course :-)). Search on Google (i.e. security best practices linux – or something more precise, such as – securing SSH, setting up sftp, installing nginx from source, etc), StackExchange an various other large sources of information.

      Make mistakes, make more mistakes, learn from them, and always be learning. Whether it’s just a small snippet you can use to speed up what would normally require typing a command in to the CLI, how to install PHP from source without looking at ./configure --help, or a something more in-depth, such as locking down your web server by using automation (via a bash script, or any script).

      I started out 16 years ago. I’m 31 and I’m still learning, as should any sysadmin, developer, designer or [insert-title].

      Try to watch the dates on guides. If they date is 2014, 2013, 2012, or older, there’s a good chance it’s out of date. Very few things server-related are the same from one year to the next and a gap of 2-4 years in a guide could be more of a security issue than simply running a barebones OS.

      • Thank you Jonathan,

        Deeply appreciate it :)

        Today I put in my ssh keys and disabled remote rootlogin. (Previous I was logging in with root via ssh and pw). That is one thing I learned today :)

        Cheers from Holland,


        • @rejkpp - No problem at all! Always happy to help :-).

          Just a side note, make sure you’ve created a sudo user that can escalate privileges if needed so that you can use them to login instead of logging in as the root user. With a properly setup sudo user, 99% of the time, you’ll never need to physically login as the root user.

          For example, running sudo [command] [...args] doesn’t do much when you’re the root user as root should be able to run any command that needs to be ran, however, the sudo user should not unless each command starts with sudo.


          sudo apt-get install -y nginx

          The root user can run the above command or simply:

          apt-get install -y nginx

          As a sudo user, the command above (that can be ran by root) should not succeed if you have setup a standard sudo user unless you successfully enter the correct password. If you’ve enabled password-less sudo (not the best idea unless that user is a non-public user), you can skip password entry. I’d stick with standard sudo setup though, strictly for security.

          You can setup a sudo user using the guide(s) below:

          Ubuntu 14.04*

          Ubuntu 16.04

          by Justin Ellingwood
          When you start a new server, there are a few steps that you should take every time to add some basic security and set a solid foundation. In this guide, we'll walk you through the basic steps necessary to hit the ground running with Ubuntu 14.04.
          • That is the exact tutorial I followed :D

            Thanks for the additional insights, I did not know that. Learned something new again today.

            Are you still in web hosting these days?

As far as your mail issue, simply installing the postfix package on Ubuntu with it’s standard configuration should allow WordPress to send messages though without SPF records in your DNS whether that mail is delivered will not be guaranteed. Personally I prefer to use a WordPress plugin to allow it to support SMTP for mail sending and use it with SendGrid which provides up to 12000 sends per month for free without the headache and potential security concerns of running mail services myself.

Since my websites aren’t getting any significant traffic nor handle any sensitive information, I have not learned nor set up any security for me server yet.

Your low traffic is giving you a false sense of security. WordPress is a major target for attackers who often run scans on blocks of IP addresses without a care for what is running there. It is easier for attackers to simply scan everything than specifically target specific servers. The biggest thing you can do in this area is to make sure that WordPress and it’s plugins are always kept up to date and you take care in which themes and plugins you choose to use.

On the security side I would recommend starting with our new server tutorial series which will help you better secure your droplet in general including taking some steps to protect your SSH service.

It’s awesome to pick this stuff up and a lot of fun to learn. I would recommend the following:

1.) Make security your #1 priority
2.) Keep everything up to date (Linux packages and WordPress)
3.) Have an experienced Linux sysadmin available. - While doing things yourself is great and in time this is likely not to be a required step, but while you are getting started if you intend to offer services to others I strongly recommend having a sysadmin you can call should things get sticky. If your droplet were to be compromised, trying to clean or migrate services and bring sites back online in the quickest time possible isn’t the best time for learning new things. Ideally try to find a sysadmin who has the patience to walk you through what they did and help you to learn.


I am actually. I’m currently working on two projects, one of which is a web hosting service and the other, a web hosting control panel of sorts. There’s a number of control panels on the market, though most are insecure or introduce vendor-lock (i.e. you’re stuck with what the software vendor tells you that you can use – i.e. cPanel, Plesk and similar). Ive never really been all that fond of being locked in so I decided to begin working on my own solution.

  • @jtittle

    Sounds interesting. I love it when people decide to create their own solution and be resourceful :) I’d like to hear more if you’re willing to connect.

    I wasn’t able to send you a message here, so I sent one athabaneroio

    Cheers from Holland,



Feel free to shoot me a message at jonathan.tittle [at] (replace [at] with @). I didn’t see your message come through on, though if you’ll get in touch at the e-mail above, I’ll be more than happy to chat with you!