Shared Hosting .vs. Virtual Private Servers (un-managed)
The web hosting provider handles installing, configuring, updating and securing common software needed by clients, such as Apache (or NGINX), MySQL (or MariaDB / Percona), PHP, Dovecot (for e-mail), Software Firewall and so forth. This is often automated by cPanel, a commercial control panel which most shared / reseller web hosting providers provide clients with as a way of easing some of the more complex tasks that would otherwise require interaction with the CLI (i.e. creating e-mail accounts and MySQL databases).
The web hosting provider in this case is essentially handling all backend tasks for all clients on the web server, thus, you’re only focus is on developing your website(s). In a shared hosting environment, you have zero access to the internals of the operating system, are unable to customize anything that falls outside the scope of your account, and are most likely limited to SFTP for uploading files (this is the case with the vast majority of shared hosting providers).
You don’t need a working knowledge of Apache or NGINX, nor MySQL beyond what is required by the application and/or scripts you run.
On the other hand....
Virtual Private Servers
DigitalOcean provides you with a bare operating system. Once your Droplet is online, you’d access the Droplet by connecting to the Public IP Address via SSH on Port 22. You’ll be presented with a command prompt and from there, what the server is used for, how it is configured and what runs on it is entirely up to you.
Apache, NGINX, MariaDB, PHP (or PHP-FPM), Dovecot / Postfix (if you wish to serve e-mail) and any other software you need has to be installed, configured and maintained by you from the CLI. This can be done using the CLI and a package manager which sources pre-compiled packages from the operating systems upstream repository, though you’d still need to configure each piece of software to bring everything together as NGINX, by default, doesn’t have a clue about PHP-FPM, nor does it care that it’s installed until you tell NGINX to use it by configuring a server block for your domain that passes requests for PHP files through.
You can, of course, install a Control Panel to automate much of this (cPanel included - though it does come with a monthly cost which you’d pay to cPanel directly - DigitalOcean doesn’t provide, install or support cPanel in terms of selling you a license, so going directly through cPanel would be the way to go).
There are other alternatives to cPanel, of course, and many are free, though as with any control panel, you’re often limited to what they support and that’s it (which throws any sort of customization out the window in most cases). You are also at the mercy of the project. If it’s discontinued, you’re stuck with what you have and in most cases, would be migrating your data again in such an event so that your server is sufficiently updated as patches and releases are made available for the software you use.
How you’d go about configuring everything really depends on what you need. If you just need to be able to run a WordPress site and don’t need e-mail (which honestly is better off being hosted off your server - zoho.com offers free and reliable e-mail hosting and you can use your domains), then you could get by with simply installing NGINX, PHP-FPM and MySQL, configuring them properly, creating your server blocks + databases, and then uploading your content + testing to make sure all is working.
Security, with a VPS, goes beyond your WordPress installation. Security would expand beyond WordPress and scale down in to the operating system. For instance, you’d want to lock down the
root user as the
root can do anything it wants (see below for a very nasty example).
root User Can Do Anything
rm -rf * /
The above command, when executed as
root, can be interpreted as “Delete anything you find at path /, recursively and with force” where
/ is the base directory of your server (i.e. where all files for the OS, Software and your content exists). Recursively means that it will traverse through all directories removing all files & all sub-directories, without prompting to ask if it’s okay (it assumes it is thanks to the -f).
SSH Keys instead of passwords should be used for all accounts, thus preventing potential “password guessing” / brute forcing and compromise. You’d want to install a Firewall and lock down the server to only allow public access to a limited port selection via your Public IP and then do the same for your Private IP. You’d then ideally use your Private IP for all server-level communication (i.e. requests made by PHP-FPM to MySQL for a connection). You’d also want to lock down your directories by creating a new user & group for each domain name that you host and then assign that user & group to your directories and files, thus (on a basic level) preventing one account from affecting the other.
Of course, the above is just a very brief overview. Much more could and should be done though this post is already about a page or so long ;-).
Is 1GB Enough for 3 Websites?
It may or may not be. It depends on traffic levels and activity. If they are relatively small sites and you’ve been able to successfully host them with your current shared hosting provider without any complaints from them, 1GB should be more than sufficient.
Can I Only Use Transmit and FTP?
No. SSH and accessing the CLI, or Command Line Interface, is a requirement. You can, of course, use Transmit to upload files for your site, or any files for that matter, though you will need to configure all software on the server first and foremost, otherwise there won’t be anything on the server to actually serve incoming requests for your content :-).