
Runbook – DevOps, automated - spking
https://runbook.io/
======
feld
Why would anyone want this in the cloud? Self hosted, absolutely. I wouldn't
want any service to store credentials that can remotely bounce my VMs or login
and restart services.

edit: If I wanted to run my own instance what things are missing? That doesn't
seem very clear.

~~~
madflojo
Thats a good point, right now we work solely off of API's and don't offer any
way for us to store usersnames/passwords. The thought is that API credentials
can be revoked easier. In general we are looking to meet the market of folks
who are 100% in cloud environments, where the adoption of a SaaS solution is
not as much of a concern. But in the future there are some ideas on how to
handle self hosting and not sending credentials to the SaaS environment.

But we are open source, and our license does allow for self hosting:
[https://github.com/asm-products/cloudroutes-
service/blob/mas...](https://github.com/asm-products/cloudroutes-
service/blob/master/LICENSE)

~~~
mason55
_> In general we are looking to meet the market of folks who are 100% in cloud
environments, where the adoption of a SaaS solution is not as much of a
concern_

In theory you could meet this need via a prebuilt AWS image or something. Then
people can still get up and running with one click but within their own cloud
environments.

~~~
madflojo
True, that is something worth looking into. We are also of course looking at
setting up some Docker images for quick and speedy deployments.

------
mskierkowski
Few more options for "IFTTT for DevOps":
[http://docs.factor.io/](http://docs.factor.io/)
[http://stackstorm.com/](http://stackstorm.com/)
[http://www.airstack.io/](http://www.airstack.io/)
[https://www.cloudmunch.com/](https://www.cloudmunch.com/)

~~~
madflojo
All interesting projects with their own twist on it. The space we are aiming
to hit can be equated to IFTTT + Nagios.

~~~
mskierkowski
I can't speak for others, but I can for Factor.io’s twist... (1) It is Open
Source + Hosted + Pro. (2) The recipes ("workflows") can include multiple
steps, sequential, and parallel activities; not just limited to if-this-then-
that. (3) Workflows are defined programmatically using a Ruby-DSL. (4) You can
create both actions and listeners (like events/monitors), though some of the
others support this too. (5) It's been around for 2+ years, built with
feedback from 100+ dev teams, and used by 1000s.

------
yellowapple
I was worried there for a second when the page mentioned Runbook was built on
Assembly, at least until I realized that Assembly was some website rather than
the programming language we all know and love.

Looks interesting, whatever the case.

------
encoderer
I think your pricing is honestly too low. First, nobody here is complaining
that your pricing is too high. Second, when evaluating pricing, it's useful to
ask "what serious customer would pay $5/mo but not $15 or $25 if we are
providing real value to them?"

I run Cronitor.io, a monitoring service for scheduled jobs. In our case, we
have about as many users on our mid-priced plan as we do on our entry level
plan. The message our subscribers send us is: we're not shopping on price,
your fees are reasonable, just keep building your product.

~~~
beecup
Interesting project! Can you tell a bit more about cronitor.io? Is this a side
project or a full time project? How many users are using your service? 100,
1000, 10000 ?

------
vailripper
Looks interesting - how does this compare to something like Monit?

~~~
madflojo
At the moment we are taking a very IFTTT style approach where we have monitors
that are external facing that can test things like TCP ports, HTTP status
codes and anything we can get at with a webhook or API (i.e. Datadog,
Papertrail, Heroku). When we resolve things it is all via external services
that we can integrate with via API's or webhooks (Commando, DigitalOcean,
Rackspace, AWS and so on).

On our roadmap is building an agent (and there is a wrapper for our webhooks),
this would allow us to run monitors and reactions locally on the server
itself. Where we would shine over a tool like Monit is that once we have an
agent you could define that reaction to happen on any server.

So for example if we detected a database error using a keyword search on the
web app. You would be able to execute commands to fix it on whatever servers
you define.

So think of it like, being able to run the actions across as many servers as
you want.

------
bitsweet
Congrats @madflojo! We're integrating with Runbook with two of our apps right
now.

I'm super excited to see Runbook launch. It has been exciting to watch
@madflojo collaborate with the rest of the Assembly community towards this
launch.

Since Runbook is a product built on Assembly, anyone can help out. If you have
any suggestions or feedback the conversations and future roadmap are here:
[https://assembly.com/runbook](https://assembly.com/runbook)

------
mdonahoe
Higher level product concept aside, here is some minor visual feedback.

I think one or more images overflow the main content container, causing the
site to look broken on my iPhone 6 plus. I don't know how much cross platform
testing your done, but it's a data point. I wasn't too excited to read the
marketing copy as a result.

I don't love your logo. It's a book on a cloud with some kind of diagonal line
for some reason.

~~~
madflojo
That is some good feedback, we have a bounty open to revise the
"responsiveness" of our site. To make it work a bit better cross platform. We
move pretty fast I doubt it would take us very long to have that fixed up.

------
jprince
Kind of didn't work. I signed up, and i was trying to set something up on my
staging to scale it out if a dyno was idle, but it didn't appear to work. I
had it at zero dynos, so you'd expect it to scale up immediately.

Also, not great UI design. I kept wanting to manage my monitors, but to do so,
I had to hit Status, and then hit Manage Monitors. I'd rather have had it on
the sidebar, like Add Monitor was.

~~~
madflojo
Hey jprince, I'd have to look at the "Not Idle" monitors for dynos that don't
exist. The way that monitor works is it looks at the monitor status to see if
any are idle, if there are no dynos then there would be none idle.

The UI is also something that we are working on, in fact it is our next big
project. We are a growing app so some things aren't exactly perfect but were
working towards it.

~~~
jprince
Ok, I had a feeling this was an edge case.

------
toomuchtodo
It says its open source at the bottom of the page, but no link to a repo.

EDIT: My apologies, I should've looked around more first before posting.

~~~
madflojo
Hi, We are an assembly product so there is a link to our Assembly page:
[https://assembly.com/runbook](https://assembly.com/runbook) which is where we
lead the development and you can find a link to our repo. Also:
[https://github.com/asm-products/cloudroutes-service](https://github.com/asm-
products/cloudroutes-service) we just changed our name from CloudRoutes to
Runbook so forgive any old references.

------
clark-kent
Kudos for successfully launching such an ambitious project, I've been
following the project on Assembly.

------
dwightgunning
That CTA button is pretty epic, though.

