10 Years Since Greenkeeper: Early Days at Neighbourhoodie posted Wednesday, July 30, 2025 by The Neighbourhoodie Team releasenews
Chances are you use a dependency update service in your projects, and if it’s good at what it does, you’ve happily left it to its devices. 10 years ago things looked a little different without these services, but the Neighbourhoodies had already started work on a solution, even before “Hoodie” became Neighbourhoodie. Greenkeeper was one of the first dependency automation solutions, and we’re incredibly proud of creating it.
We recently came across our archives again and couldn’t resist the blast from the past — what were we getting up to? And what were your dependency automation feature requests back then?
Some of the articles and properties linked in the original post have been retired, so we’ve indicated where. Grab a beverage and travel back 10 years with one of our quarterly (nearly) updates from 2015.
This is Part 3 of our little series about what has happened in Hoodie-land in the past threefive months. [This previously linked to the Hoodie’s self-hosted blog which is no longer online; luckily the Greenkeeper blog is still around.]
Stop worrying about npm dependencies breaking your build: Greenkeeper saves you time and money by automating dependency updates and notifying you of failed builds so you can spend your development time actually making things.
Greenkeeper came out of something we wanted for Hoodie anyway, and we found it useful in a client project, so we made a product out of it for everyone, why not! :)
We already got interviewed by IBM about Greenkeeper. [This article is no longer available under the domain developer.ibm.com; but you can still read the article thanks to the Internet Archive’s Wayback Machine.]
In the weeks after the release we’ve kept busy improving Greenkeeper based on user feedback:
- Initial release: we pin your dependencies and send you a pull request for every update.
Some folks prefer dependency ranges, and others find frequent updates of some packages and the number of pull requests created off-putting.
- So as a result, we introduced range support with our patented* Real Time Dependency Break Detection. Now you get the best of both worlds: version ranges, so your end-users get the latest updates automatically, and you get fewer PRs, but you are still guaranteed to be told if a dependency sneaks in a breaking change in a valid version range.
- The third release cleaned up a lot of little things and made the backend a lot more reliable. Outward facing, we now support your choice of tabs vs. spaces in your package.json (one of you is wrong, but we don’t care ;) and we added support for enabling Greenkeeper on repo forks, to support more workflows more flexibly.
- This time, we didn’t change anything, but we made all our plans more valuable: every plan on Greenkeeper now comes with support for one private repo. This allows anyone to try out Greenkeeper in any setup without much hassle.
As a result of running this for about 10 weeks now, we are learning a lot about the npm ecosystem. We’ve already sent more than 20,000 pull requests, saving a lot of developer time.
We have a lot more planned for Greenkeeper, so better sign up now!
Look out for our next time-traveling edition, when we’ll share a snapshot of what our early days developing semantic release looked like, from requirements to solution.
« Back to the blog post overview