51–60 of 101 posts
Is this not a chance for github to make some money? I'm about to launch a site on github pages (simple html site, no backend) and there's a tiny chance of it going viral. If it were to reach the 100k limit for requests I'd be more than happy paying github to keep it hosted there. I already have hosting with the likes of hostgator but they probably couldn't even handle 100k like github would.
Is this not a chance for github to make some money? I'm about to launch a site on github pages (simple html site, no backend) and there's a tiny chance of it going viral. If it were to reach the 100k limit for requests I'd be more than happy paying github to keep it hosted there. I already have hosting with the likes of hostgator but they probably couldn't even handle 100k like github would.
This is a classic case of "this is why we can't have nice things". If you're using GitHub Pages for your personal site or to document/talk about the work you're doing on GitHub, in general, you should be fine, even if you get HN-level traffic every once in a while.
The problem comes when a small handful of users use GitHub Pages for things like automated version checks or configuration distribution, as a makeshift ad CDN for for-profit sites, pushing an automated build every minute, or to distribute large assets (for which things like Releases are a better fit).
When a user (ab)uses GitHub Pages in a way that threatens our ability to build or serve other users' sites, technically or practically, we need to step in, and those posted limits are intended to help set expectations as to what you should and shouldn't use GitHub Pages for. But again, the vast majority of the nearly 1M users that use GitHub Pages will never hear from us (and in most cases when they did, we proactively reached out and provided ample warning/offered to help).
##### EDIT: The title for this link started as "GitHub Pages sets usage limits", but was changed to "What is GitHub Pages?" by an HN moderator, putting this post (and most of the discussion going on in here) completely out of context. I don't agree with this decision. Most HN readers know what Github Pages is - it's the new usage caps that are the news here. Those caps are new - I've been tracking Github Pages for ye…
Does Neocities support anything like webhooks, so people can do normal workflow of pushing to GitHub and having it be auto-deployed. Or even pushing to a Neocities remote would be fine too. I currently use a Raspberry Pi server that uses webhooks and it's very nice.
You could also create a webhook using their API and AWS API Gateway + Lambda.
Earlier quoted context omitted.
My blog gets about 19k uniques a month for which linode shows bandwidth as 39GB. I have a side project ( https://www.findlectures.com ) that got 60k page views this month, but only because it was linked in lifehacker & The Next Web. Between scrapers and HTTP requests that do feature detection, the number of requests would easily be 10x the number of users.
And since you mention Linode, which has no free tier, you must be able to afford to host your site somewhere other than Github Pages. So that works out quite well!
I am the Product Manager for GitHub Pages. As has been mentioned multiple times here, the usage limits were not in response to a specific external event. The limits have been an internal policy (in one form or another) for as long as I've been involved (nearly 4 years now), and we chose to publicize them in a series of updates beginning early this summer. This is a classic case of "this is why we can't have nice thin…
Github really needs to add https support for custom domains. It's 2016, https should be the default.
[Reposting my comment]
If you're getting over the bandwidth limit of 100GB or 100,000 requests per month, you could definitely afford to host your site elsewhere...
Spot on. They're PAGES for info and such, not free WEBSITES. This is why we can't have nice things. People don't accept a no that's free, when clearly they should.
https://pages.github.com/ advertises Websites for you and your projects., and I imagine most of the examples they show at the top get more than 100k requests, since that's not all that much for e.g. documentation or demos for a reasonably popular project. (Although it is possible that the corporate-backed projects in there actually pay for Github, just not specifically for Pages).
Just to make it clear, I'm not criticising GitHub here: It seems like they uses this a guideline/reasoning help for when someone doesn't play nice, not as strict rules to enforce, which seems totally fair. They should absolutely do something against sites misusing this service. Demanding money for commercial use would also be possible option. (they of course are also free to make strict rules for all pages, but that would have a large impact for quite a few projects I imagine)
I've definitely seen postings here and elsewhere about CloudFlare having to deal with sites whose usage is so much that it impacts other customers. While it's in their ToS, it isn't stated as a limit and there's often a backlash.
I'm guessing that the GitHub "limits" are likely soft. As long as the usage doesn't start adversely impacting their systems, they might not care. But there are certainly cases where an individual customer might do something that they would want the ability to shut down because it is getting to the point that it causes reliability or performance issues and these limits give them cover to do that. User expectations were set that this isn't an unlimited free-for-all.
When you architect any system, you do so with certain usage patterns in mind. If you're running a SaSS project, customers might (quite innocently) not understand your intention for the service and use it in a different way that works for them, but puts your systems in pain and adversely impacts other customers.
http://githubengineering.com/rearchitecting-github-pages/
Based on that post, it seems that any individual file is located on one active fileserver and one standby fileserver. That means that if any one individual file becomes extremely popular, it has the potential of impacting other customers located on the same box. It seems reasonable that this architecture works well for the vast majority of GitHub Pages sites, but that it wouldn't work well for some users. Yes, there are ways of mitigating the problem. You could write a balancer that isolated high-volume customers. You could do a more complex replication scheme to more locations. But that's work not needed for the vast majority of users and their intention probably isn't to become a high-volume webhost.
Similarly, one can imagine a customer with a multi-GB repository making automated changes every few seconds. It's a little hard to imagine, but in a long tail of SaaS customers, people do all sorts of weird things. Now they're potentially having more data to be copied faster than they can actually copy (a spinning disk won't write multiple GB in under a few seconds). Or maybe they have a certain number of "copy workers" and they don't want loads of large jobs from one customer backing up the queue.
We've definitely had customers ask our support about usage that's 1.5x some of our "limits" and honestly we probably wouldn't have even noticed. The limits are there for us to set expectations that resources cost money and we've architected our systems in certain ways that we expect certain types of usage. But in a SaaS world, someone has always (usually innocently) found something they think is a perfect fit for what they want when it really isn't made for that.
I'm not positive to the extent and what internal rules may apply. But out of curiosity I emailed the GH legal dept and they said it was fine (after checking around and getting back a couple weeks later).
So if you want to monetize your open source projects with Adsense or otherwise, that's actually an option! (Not that I have or ever will)