I’ve decided to migrate my blog to Jekyll. The majority of Jekyll tutorials recommend using GitHub Pages to host static websites. But what about deployment, site migrations or hosting multiple sites?
Before migrating I’d listed following “must-have” features for my blog:
1. No proprietary software
Silvrback is a minimalist blogging platform. However, it’s impossible to change there even a tiny piece. Decreasing popularity of Silvrback (users migrate to Medium or static sites) can put a person in an unenviable situation if Silvrback decides to close.
I don’t get the hype about Medium. It’s sleek, and I read there occasionally, but I am not a frequent visitor. Also, charging US$75 for setting up a custom domain is no from me.
2. Continuous deployment
Keep it simple. Setting up Travis CI or Circle CI doesn’t require much time, but I expect alternatives for static content deployment in 2017.
3. Site migration and redirects
To migrate from blog.thevaldas.com to valdas.blog I need to set up redirects without unnecessary hustle.
4. Hosting multiple sites
Having all of my project pages being subpages of my page feels weird.
6. Affordable price (Free if possible)
It quickly became evident GitHub Pages doesn’t satisfy all the requirements, and I found an alternative - Netlify (easy to remember the name: Netflix to lift your website). Netlify offers free and paid plans. It is free of charge for personal use. Features like teams, administrator roles, advanced workflows, visitors access, dedicated support cost from US$75.
Netlifly offers some cool features that you wouldn’t expect from a static content platform:
Continuous Deployment Jekyll, Hugo, Grunt, Gatsby? Not an issue. Netlify builds and deploys whenever you push content to your repository.
Redirects This is a valuable feature for all migrating to another domain. Netlify allows for pairing source and destination links with an HTTP status code.
Form handling and webhooks It provides HTML form handling using several built-it notification options (Slack, AJAX)
Custom HTTP headers You can configure proxying so that external API endpoints appear to the browser to be coming from the same domain. It can significantly simplify the headaches around cross-origin resources.