The start has been made: the blog is live now. After the prenatal phase that would decide whether this blog would ever exist at all, it’s now in the second critical phase: “the second post”.
To quickly get over this, I would like to write a little bit about the tech stack that runs this blog. So let’s jump right into it:
There are plenty of options to run a blog, so I’ll only name my requirements: the site should …
- have no server-side part, but be static
- be hosted on a scalable service, not on a single server
- run solely on SSL
- let me focus on the content
- offer convenience (no html, no xml)
That’s why I chose this setup:
hugo as a static site generator
I always knew that when I would write a blog, I’d want to have absolute peace of mind about the blogs hosting infrastructure. I also knew I wanted it to be as lightweight as possible. That’s why I chose a static side generator. The most prominent one is Jekyll, but I like hugo’s speed and simplicity as a go application and went with it.
Stored on AWS S3
When it comes to hosting the site, there are many hosters where you can put the files to. I chose AWS’ S3, because it offers great scalability, scriptable uploads via AWS’ API and no upfront costs (though you pay pennies for storage consumed and some more pennies for egress traffic (outgoing traffic).
Content delivered by AWS Cloudfront
S3 does offer hosting a site, but it only offers TLS encryption (aka. SSL) for domains on *.s3.amazonaws.com, their own domain. As an author, I obviously don’t want to host on their domain - it would take any option for me to host somewhere else in the future and it just doesn’t look right. AWS consequently offers CloudFront, which you can use in front of S3 with the ability to do TLS-termination at that endpoint for any domain you need.
If you think of Cloudfront as a reverse proxy, it would be quite accurate. In addition, it is a distributes service, meaning that traffic will hit the data center the nearest to the requester; internal traffic between Cloudfront and S3 will use the inter-datacenter connections and not public internet and AWS claims this to be faster.
There’s an excellent article out there on what the exact steps are to setup Hugo hosting on S3 with cloudfront, so I won’t repeat all these again (note that the setup with a hugo website is not straightforward for CloudFront & S3, so read carefully).
TLS / SSL certificates
In the days of Let’s Encrypt, a free & automated certificate signing system, it would be the go-to option for self-hosted services. However, its even easier to use AWS to create valid certificates that you can use with many of their services, such as Cloudfront. With domain validation, setting this up can be managed automatically.
Conclusion
I do like this setup, as there are no parts in it that I do have to take special care of myself. They’re all hosted services that I can just use and they offer performance that would be hard to get with traditional server based hosting or shared webhosting. Please don’t misunderstand this as an endorsement for AWS - you can problably create a similar setup with Google Cloud, Microsoft’s Azure and also with Cloudflare.
