How much does it really cost to buy more powerful cloud compute resources for development work? A lot less than you think.
We just rolled out some big improvements to GitHub Pages. Now, when someone visits a Pages site, rather than GitHub serving the content directly, the page is served by a global Content Delivery Network, ensuring that the nearest physical server can serve up a cached page at blazingly fast speeds. As an added bonus, we can now protect your GitHub Pages site with the same kind of Denial of Service mitigation services used for GitHub.com.
If you are using a subdomain, custom subdomain, or an
A record with GitHub Pages, you may need to make some changes.
Default User Domain –
Default subdomains are automatically updated by our DNS, so we’ve got you covered.
Custom Subdomain (
www.example.com) – with
If you are using a custom subdomain (like
www.example.com), you should use a
CNAME record pointed at
username.github.io as described in our help article.
Apex domain (
example.com) – with
If you currently use an
A record, you can tell if you need to move if your
A record is pointed to
220.127.116.11. You can check using:
$ dig example.com example.com. 7200 IN A 18.104.22.168
$ dig example.com example.com. 7200 IN A 22.214.171.124
Some DNS providers (like DNSimple) allow you to use an
ALIAS record to point your custom apex domain to
username.github.io. If your DNS provider supports this configuration, it will allow us to provide the full benefits of our Content Delivery Network and Denial of Service protection to your Pages site.
If you are using an apex domain (e.g.
example.com) instead of a subdomain (e.g.
www.example.com) and your DNS provider does not support
ALIAS records, then your only option is to use
A records for your DNS. This configuration will not give your Page the benefit our Content Delivery Network, but you will still be protected by our Denial of Service mitigation. Configure your
ALIAS records as described in our help article.
Happy (and faster) publishing!