I'm cheap when it comes to hosting. I don't know why, I just always have been. I currently tend to use the $5/Mo cloud servers from DigitalOcean when I do projects and so far really like them. But when Amazon announced that they now have t2.nano instances for as low as $38/yr I started looking for an excuse to use one. Mainly because, 1) Again, I'm cheap. 2) Excuse to play with AWS.
Note: Yes, I know that a t2.micro is in the 'free usage tier', and is free for 1 year. But that is 1yr from when you sign up. I signed up many, many moons ago. So I am no longer eligible. But, if you are eligible, the free t2.micro is a much better option.
If you have never used AWS before, the biggest surprise is that it's quite á la carte. In this case, you have to buy a server, plus storage, plus dns, plus plus++. Granted most of these services cost pennies per month (if not free at low enough volume), but this does lead to lots of button mashing just to set up even the simplest of servers.
So truth be told, once you're up and running and have all your side dishes, actual cost of a t2.nano comes to $5-$6/mo:
- Server: $3.16/month ($38/yr reserved instance)
- Storage: ~$0.80/month
- Transfer: ~$0.50/month
- Route 53 DNS: ~$.60/month
This is why the Digital Ocean offering may make a bit more sense for a hobbyist. It's $5. No surprises. No cpu credit limitations (see below). And the back end is much less intimidating.
On the flip side, AWS also give you the keys to the castle. You now have the ability to add in databases, caching, cdn's, IoT, containers, message bus's, etc -- all at the click of a button. What is nice about this, for instance, any day I don't need to maintain/scale a MySql server is a win in my book. So as a site grows it may make more sense (time and money) to run a t2.small/t2.medium and RDS instead of springing for a t2.large/m4.large and trying to maintain is all on one server.
But, we're nowhere near that point. So, lets continue.
So, what do I wish I knew ahead of time?
First was understanding EC2 Reserved Instances. Reserved Instances are not servers, they are contracts for servers you may or may not be running. So if you just go in and buy a reserved instance, nothing will happen. You must first have an instance running (or, build it after). So me being cheap ended up costing me an hour trying to figure out WTF is going on. So, if you're being cheap -- make sure you understand the proper way to be cheap on AWS ahead of time.
I chose to use the Amazon Linux/CentOS. I really like the Amazon offering, but the package repo is a tad anemic. For instance, there isn't a NodeJs package -- and this is fine, it is simple enough to build from scratch. But here is the problem, a t2.nano barely has enough CPU credits to get you thru the build process. So if you make any mistake (like I did), your server will go into limp mode. You'll need to now wait a few hours to earn back enough credits for the build. So, just be aware that you do get a few extra CPU credits to bootstrap your server, but if you're doing anything that requires some heavy lifting, you're gunna have a bad time.
So, what mistake did I make? I pulled and built NodeJS master -- Which at the time of deploying was 6.0.0-pre. This is not supported by Ghost. And after trying to hand jam support in, the constant 'npm install' kept eating up my CPU credits, and killing the server. So, make sure that if you do build node from scratch you pull a supported version by checking packages.js engine values first.
In hindsight, using nvm or Ubuntu (instead of Amazon Linux) would of avoided this issue .. But no one tells you that ... If I had to choose, I'd probably go the Ubuntu route for the nice juicy package repos, and then install nvm.
You could also use a prebuilt VMI -- but what fun is that?
There are many, many, many walk thrus for this. But try and find a more recent one. EC2 interfaces screens change very quickly, and there are lots of out dated ones that are only a year old. Also, Ghost CMS core is being rapidly developed on. So expect things to change quickly there as well.
The one thing about every set-up guide I found that bothers me, is that Ghost almost always ends up being run as root. Don't do that. Add a user named 'ghost' and run the process as them. And to do this, you just need to add the ' --runAsUser ghost' command line switch to forever:
$ /usr/local/bin/node /usr/local/bin/forever-service install ghostblog -s /var/www/ghost/index.js -e NODE_ENV=production --runAsUser ghost
Seriously though. Don't run it as root.
The last surprise for me was that Ghost is not to be set up and run as a standalone frontend using node based webserver, and instead needs NGinx or Apache set up as a proxy in front of it. I like this, super smart -- why reinvent the wheel. Also, in the long run makes it easier to scale.
What gets me, is installing with SSL support is also not mentioned in most install guides. The Ghost getting started guide does mention it, but ultimately the options are left out of the default config.js file. So, once you get SSL set up, make sure you add in the following options to the production portion of your config.js:
urlSSL: 'https://your.url.com/', forceAdminSSL: true,
Also, if you're looking for a cheap SSL cert -- the Comodo Positive SSL certs can be had for < $10/yr at Namecheap.com .. You can also self sign your own, and use it for admin. Or, use https://letsencrypt.org/ and get a free cert that needs to be renewed a bit more frequently. The Ghost docs have a good guide for what you need to get SSL working w/ NGinx here.
Update: Check out my post on Intermediate certs. This may save you a headache in the long run.
The more and more time I spend with AWS the more I like it. But it is like skinning a cat with a hand grenade for the hobbyist. If something simple like Ghost is all you want to run, honestly go with a provider like Digital Ocean -- Or, go with the Ghost Hosted Solution. They will save you lots of headaches, and will probably be cheaper in the long run.
And Ghost itself is pretty nice. I like what I see, and I hope they keep it slim and light, and not try to be or compete with Wordpress.
tl;dr There are much better ways of doing this. But, it is not impossible. And it's fun.