[aanand]

Very sorry you had to hear it from HN - we had our email, blog post etc. ready to go out but there was a scheduling mishap. We also emailed our active customers from last month in advance yesterday.

The space has matured a lot, so there are some great alternatives out there. Happy to help you migrate - give me a shout at [e-mail]

[webmaven]

Release Orchard backend as open source? Note: Consider why fig took off and Orchard didn't...

No one wants to be stuck on a provider that might not succeed and have to migrate to a different one unless the new provider is drop-in compatible. It is nice that you are providing migration instructions and help, but the very idea of being at the mercy of an acquired platform's team is what stops me from trying such services in the first place (after being burned by ep.io, 30loops, etc.).

[bfirsh]

The nice thing about using Docker is that everything is drop-in compatible. You can push your images to a provider such as Tutum or Google Cloud and they'll be able to run. If you've written any software that used the Docker remote API on Orchard, you can just point that are your own Docker daemon and it'll keep on working.

[webmaven]

If that were really true, the migration instructions would be more along the lines of "change the endpoint URL to your new provider", or "push this one button and authenticate", instead of https://www.orchardup.com/docs/moving

That said, kudos to the Orchard team for making it as easy as they did, I'll just stress again that the fear that migrating would be even more involved was what stopped me from trying their service in the first place.

There are several ways of addressing that fear:

1. Be so big that you know the service is unlikely to be shut down or acquired (that just leaves the usual lock-in concerns over future price hikes and the like, which isn't going to happen until the market stops growing).

2. Ensure that a fluid marketplace of drop-in replacement competitors exists (an Open Source release of the backend helps with this)

3. Document how easy it is to switch away from the get go, not just when you're shutting down: see https://web.archive.org/web/20140209113413/https://orchardup... and http://www.joelonsoftware.com/articles/fog0000000052.html

[skrebbel]

Not sure that was the reason.

By using Orchard, we allowed ourselves to avoid doing any server management at all. Even without a drop-in replacement, the alternative would have been to set up our own Linux servers somewhere and learn to secure them and to securely send Docker images over and all that. Assuming Orchard wouldn't break overnight, the only real risk we took was that maybe no more decent competitors would pop up in the space and we'd be forced to put our own Docker on an EC2 anyway.

If your biggest risk is to be forced to choose your only alternative, but later, then that's not a very grave risk is it?

[webmaven]

Only if you've eliminated various PaaS offerings from consideration as an alternative for avoiding administration costs.

[skrebbel]

Hi! I admit that when the blog post was down, there was this part of me deep down that feared that it was going to say "we'll pull the plug this weekend, good luck!". That might have made my comment feel a bit too bitter. Sorry about that.

We saw a bunch of nice alternatives pop up actually - and admittedly we were already in the process of moving over to one (Tutum, probably, unless you have better ideas :D), because we realised that you two are much better coders than you are hosting providers :)

Congrats on the move and good luck with the London office!

[ilaksh]

Why are you shutting down Orchard? Seems like a great service.

Is Docker going to have its own thing like Orchard?