Static Website Deployments on AWS the easy way
tldr; checkout static, a tool to deploy to S3 + CloudFront in a single cmd.
Last month at Planes we started a project for a client that was prime for static hosting, a very small piece of UI that would be used globally and need to scale to 100,000 concurrent users. I began browsing options and narrowed it down to the following:
- Surge.sh — easy deployment, files are served over a CDN and it seemed like I’d only need the free tier for this project.
- GitHub Pages — super fast and very easy to deploy but lacks some functionality I’ve needed for other projects such as the ability to add client-side routing— this won’t be a blocker for this project.
- Some sort of AWS setup — I had no idea what this would look like at this point but knew that it would be the ‘legit’ option.
Deploying to AWS S3 and CloudFront isn’t easy, or at least, a faff! You’ll find yourself dipping in and out of the AWS dashboard hourly, and if you are like me, not enjoying it. Deploying involves tying in a number of different services that all seem daunting and over-cumbersome in the age of development we are in. Im a sucker for things either being automated or beautiful, and using the AWS console is neither for me 😬.
Surge.sh
Surge allows developers to deploy to a CDN in seconds and prides its self on allowing developers to ‘not leave the command line’ — ka-ching! I’d already loved using Surge.sh on another project so jumped straight to it.
$ surge ./build my-domain.com is all you need to deploy.
Naturally I had some overriding worries (although unfounded) that Surge wouldn’t handle the project’s requirements of up to 100,000 concurrent users, it seemed too good to be true. I took this worry to Surge’s slack channel but was quickly defused by the creator who responded with “just let us know when you are going live, shouldn’t be a problem”, 😍, wow. Although I was feeling more-or-less confident, it didn’t seem right to risk the project and add workload to Surge when Im not even a paid plan customer!
This led me to compare against GitHub Pages…
GitHub Pages
To publish to GitHub Pages its as easy as creating a branch with your built site and pushing to it, or with the gh-pages cli with command gh-pages -d ./build. Simple.
I did some very basic performance load time testing to compare with Surge, the results were pretty conclusive; Surge.sh was loading in about 300–500ms, whereas GitHub was under 100ms.
It has lightening page load times and is easy to deploy, and although I don’t need to use client-side routing for this project GitHub Pages does have limits on bandwidth. Best not risk it.
With this in mind, the ‘legit’ AWS setup seemed the only option.
AWS S3 and CloudFront
AWS’ S3 provides a way of hosting static assets most frequently used to serve images on the web. As with most services on AWS it can be configured to fit almost any use case.
I began searching the plentiful articles on the topic of deploying static sites, they pretty much all boiled down to the following:
- Create a new S3 bucket called whatever your domain is (if you are using a custom domain)
- Upload your site’s files to the bucket
- Enable ‘Static Website Hosting’ for the bucket
- Create a new CloudFront Distribution
- Fill out the distribution config to point to the S3 bucket
After re-releasing you’ll then need to create a new ‘Invalidation’ for your CloudFront distribution to update the cache in your CDN. This process is the cost of using incredibly powerful tools.
Asides from the cumbersome setup process, AWS was the perfect fit for my project, I had the performance and scalability whilst retaining control if things blew up, but I missed Surge… 😩. This is where I decided to build Static, a single command to bring me (and others if they so desire) the joy of Surge’s simplicity alongside the power of AWS. Here’s a few things that Static provides:
- Deployed to S3: Deploys your directory to an S3 bucket.
- Custom domains: prefixed with your domain name (or a random string if none is provided).
- Automatic Static Hosting: Enables Static Hosting for your bucket.
- CDN’d via CloudFront: Creates a CloudFront distribution so that your site is served over a CDN, making it speedy wherever you are in the world.
- Invalidates cache on each deploy: It will update the cache of your CloudFront distribution if one exists.
- Client Side Routing: It’ll handle both standard static routing OR client side routing.
- Custom error pages: If you aren’t using client side routing you can add your own 404 page by adding a 404.html document to the route of your directory.
- Clean URLs: All URLs will be ‘cleaned’, i.e. your-domain.com/hello.html is reached via your-domain.com/hello.
So we’ve got almost exactly the same functionality as Surge in a single command (static ./ domain.com) with all of the benefits of using AWS, 🎉.
I hope you enjoy.
p.s. To install: npm i -g sttc
Munity
This project was part of our (Planes’) 12 month mission to build a product a month. Last month‘s product was Munity, a platform for sharing ideas with other product peeps — and hopefully collaborate and get them built. We’ll mostly be picking the top voted project each month from Munity and will be working with the poster to get it released.
