geemus

We take security very seriously, which is why we designed Relay to work so that we never have to see your encryption keys. If Let's Encrypt is working well enough for you, that's great, but we've also heard about rough edges that people struggle with so we are trying to help them out.

Unfortunately auto-scaling is incredibly application specific. It would be a great feature, but it seems likely to be quite difficult to make a particular solution that is useful to more than a small subset of users. You can get some sense of this from the other comments above (ie how analytics wouldn't be a good scaling metric for them).

A number of people definitely found their way through the toolbelt code to use the API previously, which is amazing. We hope by giving a stronger focus and some proper documentation that we can make it much more accessible to more and more people.

Both the format and version are in the same header if that helps. So there are a couple values in there you might have to change, similar to the couple values you would have to change in the url to modify version/format. So in that regard I think the difficulty or complexity of one or the other is pretty similar. Hope that helps explain a bit, but let me know if I missed the point of your question.

Sure. I haven't tried either. Its on my list of stuff to dig into and sort out, so hopefully we have a better answer soon.

We definitely used what you mentioned as a starting point. There are some changes, hopefully for the better, but it should in time provide all the same functionality in a more public and formal way. We definitely love that people were excited and motivated enough to reverse-engineer things as you did, so we hope this makes it easier on you and more accessible to others.

Billing is definitely on our todo list as we progress with the beta. Provisioning new accounts is a little trickier as it could potentially open the door to abuse. Which isn't to say we'll never do it or that it isn't possible, just that it is more complicated.

I was pretty sure that was the kind of thing you meant, but just wanted to clarify. The API should certainly facilitate doing the kind of setup and management that this would require. But it doesn't currently provide a direct way to do the billing portion of things. So I think it could be a ready solution to open source self-hosted stuff, for instance, but you would have to provide your own billing stuff for commercially licensed things.

Thanks for sharing the link. There definitely can be a lot of gotchas and things that are easy to overlook until you see a good talk or are right in the middle of it.

Great, do let me know if there are particular questions you have and we can be sure to cover them. Otherwise I hope to start covering the key things that I think are interesting or important in the not too distant future.

I had not really explicitly considered that possibility in working on this. I suppose this is a step closer to that, but there are still some pieces that we would need to add. What kind of things did you have in mind?

Yeah, that would definitely be an interesting way to use it.

Interesting. I fear I'm mostly a back-end type of guy (ie not much experience with XMLHttpRequest). Sounds like the browser may be at issue to some extent. I certainly find the behavior you describe to be surprising. Is there something we can change to better facilitate this?

Thanks, glad you like it. A ton of thought went into a lot of the little choices like that. We plan to dig more into how and why those choices were made as we move forward.

Sounds like a great approach. What can we do to better support XMLHttpRequest?

Totally. I definitely hope that this will lead to many, many fun weekend projects. Definitely really excited to see what people dream up.

I would be happy to explain.

We did provide a legacy API (v2), the platform API is the next iteration on the design (v3). The legacy API was mostly used just internally and we knew we could do better in providing a great public API for external folks to tie into and use for awesome stuff.

Currently heroku.rb still uses the legacy API, as we did not want to introduce breaking changes to heroku.rb and because the legacy API will still be around for a while. We will build new tools and update existing ones, but plan to do so later in the beta so that we can integrate feedback and see what will best help people.

Exactly. For simple cases just shelling out to the API is good enough, but many of these deployable apps are a bit more complicated. Especially those that need databases or other add-ons to work.

Those repetitive setup tasks are definitely one of the things we wanted to provide an easier solution for. I definitely look forward to simple scripts instead of multi-step manual processes.