> And for hosting, Github pages (Jekyll rocks!) do a great job.
Using GitHub pages to auto-build your Jekyll site is great if and only if you have no need to customize your Jekyll build or website environment:
- You must use the versions deployed by GitHub; most of the time they're up to date, but if there's a bug fix you're relying on in any of the libraries, you're out of luck. I ran into this on my own site: RedCarpet had a Markdown parsing bug that was fixed in version 3, but the Jekyll that GitHub Pages uses depends on version 2. Jekyll loosened this dependency weeks ago, but it's not in a full release yet.
- You can't use any Jekyll plugins, even the ones marked safe.
You can avoid the above by building your site locally and uploading the output, there are still a few other caveats:
- Like timrivera mentioned, there is no support for server-side redirects outside the baked-in ones (i.e. www to or from naked domain; name.github.io to domain). S3 has these out of the box.
- You can only use one domain per GitHub Pages repository.
- GitHub will allow Googlebot to index your repository's master branch. If you're used to that convention, you're out of luck: it's hardcoded into github.com's robots.txt. You need to use a different name for your mainline branch.
- You cannot use a private repo for GitHub Pages, and GitHub's terms of service require you to allow other people to fork your public repositories, regardless of license.
- There is no support for SSL.
If you're okay with all of that, GitHub Pages is totally fine. But if you aren't, non-VPS alternatives like S3 are pretty attractive.
That's what I immediately thought when I first read it, especially now that Github Pages are served over Fastly's CDN [1].
Then I realized that Github Pages do not support server side (301) redirects at all. Quite a big turn-off when you move an existing website over a new platform.
And for hosting, Github pages (Jekyll rocks!) do a great job. I think you are still paying too much, Paul.