I want to say that in the terms of service, they always forbade you from using a cron job to keep all of your dynos alive, I heard someone say this once, but I don't believe it's true (I have not read the TOS).
Heroku has offered the New Relic monitoring plugin for free which has this same functionality (pretty much as a checkbox), so it would not make sense for them to forbid this in the TOS.
So, if you're using Heroku to serve up your apps 24/7, how is that not worth $7/mo?
Unless your business is geographically distributed (or otherwise operates 24/7), you can still use Heroku for internal applications for free during business hours (and use monitoring to keep it fast.) If you are serving your public website from Heroku, that's probably worth $7 or more (even as a hobbyist).
So, yes it's a downgrade to users in the free tier, but what's wrong with Heroku attempting to monetize their (most likely very, very) long, free tail?
I am not surprised by this announcement because it was reported on HN a few weeks ago that they were doing something like this in a beta (and the details were not supposed to be released, NDA, blabla). For anyone who was already paying Heroku, your bill is going down.
We actually use the free tier at my business, and this may affect us. Oh well.
It is a downgrade. The whole post sounded like a downgrade since they felt the need to emphasize their commitment to experimentation.
I am one of the people affected by this since I was running a one-page website dyno and had pingdom keeping it out of sleep mode. This is what they are referring to as well in the last paragraph. I didn't know it was that many people doing this, though the solution for me would be a simple one: just allow me to serve static files.
I also used Pingdom to keep my Heroku apps alive, although I found it annoying having a separate free account on pingdom for every site and recently swapped over to StatusCake (https://www.statuscake.com).
Whilst you're right that it is a downgrade, it was clearly iffy to be using Heroku for free 24/7 hosting with essentially no downside on our end. I had no qualms however because it was just so expensive to move up to any other tier and it took so long for the Dynos to boot up.
Since they're adding the Hobbyist tier at only $7 I really don't mind this change and will happily swap over to it.
People wouldn't have been pinging their dynos to remain awake if it didn't take so long for them to spin back up. Know of any alternative places for projects that don't use a lot of resources?
IBM are also putting a lot of resources in to Bluemix which offers a 512MB dyno equivalent in their free tier, it doesn't run on AWS though. (https://console.ng.bluemix.net/pricing/)
If you've got a static files you could still serve it using Heroku free. Put cloudflare or another CDN in front of it and boom you've got 24 hours of fast responses. Though if it's a static site why do you need Heroku? Kind of like using a cannon to kill a mosquito.
A better static files offering is definitely something we've been asked for a few times. Near-term, if you put a CDN in front of a static app your dyno will wake up on release, fill the cache, and go to sleep. You shouldn't see much, if any difference for your apps at all.
Given the blog post calling people who use pingdoms freeloaders for using the service they advertised as free and changing offerings like this, there are other VPS hosts that don't pull a bait and switch after encouraging dependence that are cheaper.
You could call it a side-grade. We're also allowing users to add a worker dyno and use up to 18hrs/day of `heroku run` and scheduler one-off dynos as well. All told you can get quite a few more compute-hours for free applications now than before.
You can call it what you want, but for what I (and others presumably) use it for, the 24/7 uptime is essential. Sure an argument can be made for needing to pay for 24/7 uptime, but it is very clearly a downgrade in such a case where such an argument even needs to be made!
To clarify: I'm particularly speaking about the parent's use of the term "sidegrade." I'm not disagreeing with the idea that 24/7 uptime should be paid for (because I agree), but to call the change in terms of service a "sidegrade" is a misrepresentation of what it actually is: a downgrade in services for my particular use case.
You can have a web dyno and a worker dyno running side-by-side 18h/day for free in the new free tier (unless I've misunderstood something.) You can't have one web worker running 24h/day for free, not as of next January.
18+18 > 24
I understand that your (and my) particular use case are affected negatively by this, but if it wasn't totally clear what he means by sidegrade, that's about the size it. More compute hours for your $0, but less availability.
"We charge less than we pay our upstream, but it's ok because we'll make it up in volume."
Seriously though, they're saying that most deployments use less than 18 hours per day, and if they just let them stay up 24/7 regardless of that, they're basically leaving money on the table. Heroku pays Amazon for all of what we're getting for free. Their free tier is a loss-leader.
If they don't spin down your app when it's idle, it absolutely costs them more than if they do. Regardless of how much (or even whether) they bill you for it.
As one of a small niche group who hosts Hubot on Heroku, this is horrible news. Chatroom bots are useless if they aren't in a room 24/7; that's the only reason why we have a keepalive. It's not as if the chat bot is doing a lot of computation, but this really does make it sound like I'll have to toss Heroku despite the convenience factor with it.
It's for an open source project, not an internal work instance or anything. As a student at uni with no full time job, adding more monthly charges is hard to deal with.
At Georgia Tech we got a very small server space which was used in a few CS classes, it would have been large enough to run hubot. Your university might have a similar setup.
Heroku was basically becoming the go-to place to run thousands of little bots—and more importantly, to advise people to run their little bots—without thinking about marginal costs. It was becoming everyone's little pocket of persistent personal cloud agents. The "launch on Heroku" button on Github pages was a thing you could just press on a whim as a realistic solution to your problem.
IBM's Bluemix has a very generous free tier. If you can run an app or apps using a total of 512M of ram with modest data storage requirements, then that is free.
Old computer, yeah- Raspberry Pi, not so much. Takes hours to compile node from source, and I've only been able to find one source for ARM node binaries.
And after all that, hubot still ran pretty damn slow. :(
Still, Debian only ships nodejs 0.10 (even Sid) for now -- and I'm not sure what the status is for compiling node 0.12 on armv7 (it apparently has issues on armv6 which the rpi v1 runs).
Fwiw, if you can get by with node 0.10 for hubot (Which I think you can[1]?) -- there shouldn't be any problem:
Heroku has great services/integrations and deployment is dead simple but when you commit to them you introduce a level of uncertainty into your stack. Services being deprecated, pricing changes and addons breaking are all very real issues. I initially enjoyed the simplicity of the platform but find myself feeling a little jerked around lately.
A pricing change was long overdue. AWS (which Heroku relies on to host everything) has been getting a lot cheaper in the last few years, but Heroku never changed its pricing and pocketed the difference.
Unfortunately it's strictly a price increase for everyone who bought a second dyno to get out of the freeloader tier. $35/mo (one free + one standard dyno @ $35/ea) to $50/mo (two standard dynos @ $25/ea).
It's only a price decrease for people with 4+ dynos.
For production apps, 2 dynos is the least you need not only because of sleep, but also because of redundancy. So there's no way of downgrading to the Hobby tier for lots of us.
Hey there, we absolutely want to make this the smoothest, easiest pricing change you've ever been through.
We're just announcing the beta today and almost every single customer we have will see savings in some form here. We'll keep the old pricing until the end of January next year and let people opt in at their leisure until then.
Stupid people who were abusing Heroku by pinging the apps caused this, now they might as well suffer. All my hobby apps go to sleep regularly and it is not bad.
I am grateful to Heroku for providing me all this free computing and I hope they get rid of the freeloaders.
I'm pretty sure pinging services and such were out of their ToS anyway. They're better facilitating non-sketchy free users by giving them the Scheduler and a worker, and have given people who absolutely need 24/7 service a great service for dirt cheap.
I bet most people who need the 24/7 service probably have the money to spare, and I bet most people are overestimating the uptime they need anyway.
On the flip side, for a small flat fee, I can now have 10 processes running on a 24/hr server, effortlessly. I'll pay the 7 bucks for an easy deploy. Most of my projects are going to be hosted on Github Pages or Heroku's free tier anyway.
There's a huge difference between 24 hours/day and 18 hours/day, but I don't think there's such a big difference going from 18->12, so I don't think many people will care about this improvement.
We looked at the numbers and it's actually a very, very small percentage of applications that run between 18 and 24 hrs per day.
Eighteen hours a day is enough to keep your app running from 9AM to 3AM every day, and unless your application has a global reach, it should naturally equilibrate into a comfortable place.
We are asking that if you want 24x7 wake-time that you pay for a hobby dyno, but if you can let your application sleep when you do, you won't see any difference at all.
Previously, worker dynos never slept. On the new free dynos, you now get a free worker dyno, but the tradeoff is that the app must sleep for 6 hours/day.
Does that sleeping time include the worker dynos? If it does, when do they sleep? Workers can't "timeout" like web dynos can.
I understand the thoughts about changing the current pricing. However, it would be really good if Heroku would support the community with a 24/7 dyno for open source projects. It hurts if you need to put in additional monetary effort into projects you provide for free.
I've probably posted a similar comment a few times before, but why don't the dynos ever improve? I have no problems with the pricing, but dyno performance and memory has been the same for, what, 5 years? Longer? The whole time I'm getting emails from AWS telling me about cheaper, better instances. Doesn't make sense.
Hobby dynos are real dynos. :) Professional dynos, like the new `standard-1x` will have scale-out, Heroku Metrics, preboot, and mix with other dyno types: all features we have found are most useful for apps at scale.
We hope that between the new `free` and `hobby` dynos you should have good choices that support almost any personal or small scale professional app you might want to build.
So hobby dynos should be able to run the same type of application as a 1x dyno, just with fewer other features more or less?
I have a small scale web application (around 5K pageviews per day) that runs very well on the one free web dyno currently offered. (We do have costs for the DB and SSL). I assume in the next few months I'll have to move it to either a hobby or 1x dyno. Obviously I'd rather move it to the hobby one because I don't need an additional $220 or so cost per year. It would be great to have a few more details on the site about the specs behind the free and hobby dynos!
A real dyno costs $34. So in essence, they're replacing the 24h free tier with an 18h free tier, but lowering the cost of the first paid dyno to $7. At least that's how I'm reading it...
They also lowered the cost of that 1x dyno in the Pro tier, and if I'm reading correctly that $7 actually buys you two full-time dynos (but only one of them can be web, the other has to be a background worker.)
You can use both 1x web and 1x worker in the free tier too, as long as you abide by the new policy of sleeping 6 hours.
I hadn't considered that interpretation, but it's less confusing than mine:
My initial suspicion was that since the hobby dyno has "10 process types", I would think the "1 web, 1 worker" restriction for the free dyno is just another way of saying "2 process types". But would that mean the worker is prorated up to an additional $7/mo?
I think this could be cleared up on the pricing page.
My interpretation is $7/mo buys you two dynos, but not more than one web type, and this seems to be consistent with what the heroku rep here in this discussion seems to be saying.
(eg. comments that Free tier actually potentially gets more compute time under this arrangement)
But it's not at all clear on further reflection (that if you do choose to do this 2-dyno 1 web, 1 worker arrangement on the hobby tier, you don't wind up paying $14/mo rather than the total of $7/mo). I think that's what it says, but I'm not at all sure.
Hobby — Run a small app 24x7 with the Heroku developer experience for $7 per dyno per month. Multiple worker process types for more complex apps. Run a maximum of one dyno per process type. 512 MB RAM.
In your Procfile you can have any type of process you want. The "web" process type is just special because it expects you to open an listening tcp socket on the port it provides in their environmental variable to your app. Aside from that you could say have a worker process, emailer process, etc and scale them independently.
How is this not a downgrade?