DEV Community

99.9% uptime static site deployment with Cloudflare and AWS S3

Alex Barashkov on October 02, 2018

Welcome to our simple guide for those of you looking for 99.9% uptime and an almost free deployment solution for your static websites, without havi...

Read full post

Erebos Manannán • Oct 3 '18

Is there any benefit in this set up over just using GitHub Pages?

You can get a custom domain to work with GitHub Pages, you get SSL, you get your static pages hosted for free, but on top of that with GitHub Pages you can use Travis-CI/Jekyll to build your static pages easily. Since it's a static website it's not like the source is private or anything like that.

Alex Barashkov • Oct 3 '18

I tried Github pages before moved to a described solution.

Reasons:

with GitHub pages, you should keep in the repository compiled version of your website and if you use webpack or gulp, it will cause increasing the size of your repository. So let's say you have in your source code png or svg assets which webpack compile in one sprite, adding each new asset will cause also getting and new version of sprite.
with Github pages your website should be served directly from your root folder or from docs/ folder. I was not happy with it too, because you can't define your folder. And most common folder is "dist".
Github pages not allows you to have multiple deployments, which mean it does not fit for you if you would like to have a "staging" environment.
and the most critical issue I faced few times after pushing new version. I got an error "the page does not exist" and only after 5-10 minutes it became available again. So I suppose there is some sort of cache purge issue.

About the last point, of course, it could be specific my issue because I don't know how to cook Github pages well, but I did not want to spend a whole day trying to figure out how to do it right. I wanted to have a solution out of the box.

Erebos Manannán • Oct 4 '18

with GitHub pages, you should keep in the repository compiled version of your website

Well, you can always just set up a separate repository for the results with Travis-CI, and throw away the history on it.

you can't define your folder. And most common folder is "dist".

Seems like a minor problem - changing the configuration on your build tool seems like a minimal hassle. Also, separate repository with build artifact deployment to GH Pages is not a lot of work, and you can use a separate branch and deploy just your build artifacts there and e.g. always throw away the history on that branch.

Github pages not allows you to have multiple deployments, which mean it does not fit for you if you would like to have a "staging" environment.

This is sort of true, unless you're happy with using subdirectories + scripting. E.g. "if in staging branch, deploy to staging subdirectory". That + local envs + potentially using ngrok / PageKite or similar should cover most uses rather well.

I got an error "the page does not exist" and only after 5-10 minutes it became available again.

No clue what that's about. You could of course try to ask GitHub or Stack Overflow or some such.

I've got repos where I push and changes appear within seconds, and repos where changes go to Travis-CI queue and then the artifacts get pushed to GH pages and those changes appear within minutes. Can't remember witnessing downtime.

I did not want to spend a whole day trying to figure out how to do it right. I wanted to have a solution out of the box.

Sounds like there were quite a few steps that probably took a while to set up your alternative.

As an example of what I've set up there's this for the sources github.com/Lieturd/lieturd-website which deploys build artifacts to github.com/Lieturd/lieturd.github.io (without history) that then gets hosted at lieturd.com/ .. all with the 100% free GitHub Pages + Travis-CI.

If you happen to like writing pure HTML or prefer using Jekyll, then the setup can be even simpler and skip the Travis-CI step, like I did on this earlier work: github.com/lietu/lietunet

ajv • Oct 15 '18

All of those reasons are mitigated with using Netlify + the setup's a breeze and you get mostly the same benefits like you do with AWS/Cloudflare, except you also get total control of server's redirect rules (meaning you can redir everything to your index page for a SPA or properly serve 404s/401, etc. for specific routes) and you also get form submission, authentication and other various goodies that can't otherwise be fitted onto a static page.

Any reason/pros this setup tops that?