raw.githack.com serves raw files directly from GitHub, Bitbucket or GitLab with proper Content-Type headers

Use this URL in production

  • No traffic limits or throttling. Files are served via CloudFlare's CDN.

  • Files are automatically optimized.

  • Use a specific tag or commit hash in the URL (not a branch). Files are cached permanently based on the URL. Query strings are ignored.

  • The catch: this is a free service, so there are no uptime or support guarantees.

Use this URL for development

  • New changes you push to GitHub will be reflected within minutes.

  • Excessive traffic will be throttled.

Why is this necessary? Can't I just load files from GitHub, Bitbucket or GitLab directly?

When you request a file from raw.githubusercontent.com, gist.githubusercontent.com, bitbucket.org or gitlab.com, they are usually served (in the case of JavaScript, HTML, CSS, and some other file types) with a Content-Type of text/plain. As a result, most modern browsers won't actually interpret it as JavaScript, HTML, or CSS.

They do this because serving raw files from a git repo is relatively inefficient, so they want to discourage people from using their repos for static file hosting.

raw.githack.com acts as a caching proxy, forwarding requests to GitHub, Bitbucket or GitLab, caching the responses either for a short time (in the case of development URLs) or permanently (in the case of CDN URLs), and relaying them to your browser with the correct Content-Type headers.

The caching layer ensures that minimal load is placed on GitHub, Bitbucket or GitLab, and you get quick and easy static file hosting right from a repo. Everyone's happy!

Is raw.githack.com associated with GitHub, Bitbucket or GitLab?

No, raw.githack.com is not associated with GitHub, Bitbucket or GitLab in any way. Please don't contact their support asking for help with raw.githack.com. They'll give you a weird look and back away slowly.

What's the difference between development and CDN URLs?

When you make a request to a development URL, the server loads the requested file from GitHub, serves it to your browser with the correct Content-Type header, and caches it for a short time. If you push new changes to GitHub, you can reload and see them within a few minutes, which makes development URLs useful for low-traffic testing or sharing demos during development.

Requests to CDN are routed through CloudFlare's content delivery network, and are cached for a year the first time they're loaded. This results in the best performance and reduces load on raw.githack.com and on underlying service, but it means that reloading won't fetch new changes. Furthermore, JS and CSS files will be minified for the sake of performance.

During development, when traffic is low and freshness is more important than performance, use development URLs. For anything you share with the public or push to production, use CDN URLs.

Can I use a development URL on a production website?

No. Please use CDN URLs for anything that might result in heavy traffic. Only use development URLs for low-traffic testing and sharing temporary examples or demos during development. When people misuse the service, it costs me money. Please don't be a jerk.

What will happen if I send large amounts of traffic to a development URL?

The service will start serving an error page instead of the requested file.

This is designed to get your attention as quickly as possible before the excessive traffic becomes a major problem for the service and starts costing me large amounts of money or impacting other users of this service.

Remember, only use CDN URLs in production; never development one.

How long does the CDN cache files? How can I make it refresh my file?

The CDN caches files for one year based on their path. It ignores query strings. This is done both to improve performance and to make it possible for the CDN to handle massive amounts of traffic without causing excessive load on raw.githack.com, GitHub's, Bitbucket's or GitLab's servers.

To ensure that the CDN always serves the version of the file you want, use a git tag or commit ref in the file's path instead of a branch name, and update the URL if you push a new version of the file.

So, instead of a URL like /user/repo/BRANCH/file, use a URL like /user/repo/TAG/file or /user/repo/COMMIT/file.

I need guaranteed 100% uptime. Should I use raw.githack.com?

Probably not.

raw.githack.com is a free service and cannot provide any uptime or support guarantees, even for CDN URLs. While I do my best to keep things running, things sometimes go wrong. Sometimes there are network or provider issues outside my control, sometimes abusive traffic temporarily affects response times, and sometimes I break things (although I try really hard not to).

Since I run raw.githack.com in my spare time, with my own money and with free CDN hosting by CloudFlare, it has a budget that's probably less than you pay for coffee in a given month. My goal is to help other open source developers get their projects up and running, but if you need to serve files that are crucial to your business, you should probably pay for a host with well-funded infrastructure and uptime guarantees.

I have feedback or want to report a bug! Who can I contact?

To report a critical issue like raw.githack.com being broken or to share general feedback, send a tweet to @neoascetic. I try to respond quickly when I'm awake and near a computer, but sometimes I do have to sleep. To report a non-critical bug, please file an issue.

How raw.githack.com differs from RawGit?

The idea of this service is inspired from rawgit.com (formerly rawgithub.com). I just realized that using a whole framework (node.js with express.js) for such simple thing as requests proxying is overkilling, and made same stuff using nginx only.

RawGit supports only GitHub while raw.githack.com supports Bitbucket and GitLab as well.