Good questions, and I'm happy to answer. I'm going to answer with a philosophical point of view. I'm not trying to dodge the question, but I'm hoping it provide

Good questions, and I'm happy to answer. I'm going to answer with a philosophical point of view. I'm not trying to dodge the question, but I'm hoping it provides you some idea of how we're approaching the problem. If not, just let me know I can try to clarify. The bigger philosophical idea is the centralization of knowledge. How does Otto know how to deploy a PHP application? Because people who can be considered experts in PHP encoded their knowledge of how to do it. You no longer have to be that expert. (Note that 0.1 deploys PHP in an awful way, 0.2 will do a lot better, thanks to the "experts" coming in). Our goal is to centralize dev/deploy knowledge so that we can focus on higher level problems and teach Otto how to do the details. The next question is how do I know its safe? Under the covers, Otto uses a lot of production proven tooling. On top of that, we have a really extensive acceptance test suite to verify behavior against real things prior to release. We're doing the best we can do, but Otto will need to earn a lot of trust. We're going to build that trust over time. Note that you can always inspect the ".otto" directory after compiling your Appfile to see the configurations it generates. You can choose to not use Otto's deployment features. That is completely fine. Our goal is that in less than a year, it does what you'd want it do (help us by teaching it!), and you'll gain trust for it. We have extensive acceptance tests to verify certain behaviors. Of course, we can't cover every edge case but we are going to do our best. This will be a trust building process. And, I don't blame you being afraid. It is a very new tool that is trying something that is threatening to a lot of people. No worries. Just wait a while; maybe it earns your trust, maybe it doesn't. Take a look at our other tools if you want absolute control, Otto might not be for you. :) Finally, and this is not a negative thing: the HN crowd is generally not the crowd Otto is aimed at. HN folks are tinkerers, they want to know how things work. That is what makes HN great. They question things and want to know the full details. Otto scares people like that because it _removes_ power from you (much in the same way compilers removed power from assembly programmers). For these folks, I ask you to take a look at the tools that are under Otto: Consul, Nomad, Packer, Terraform, even Vagrant. They provide absolute control. But, Otto is already making great great adoption in the group of people who think "I don't care how, just deploy this application." Think folks that work with well known technologies like the LAMP stack, Wordpress, Rails, etc. all day. Otto for them is fairly revolutionary, because this is a tool that actually makes them more productive and simplifies thing, vs. a lot of the other tools even we've built which appear to add complexity. And for the folks that want simplicity, what Otto is trying to do is give them industry best practices in addition to simplicity. As an extreme example: we want `otto deploy` to be easier than FTP-ing PHP files to a server, because it isn't a best practice for many reasons. We want you to get an AWS infrastructure designed by experts deployed onto a server that is configured by experts with supporting tools for monitoring, logging, security, and more that only experts would really properly use and configure. These are Otto's aspirations. I believe we can get there, but Otto obviously is new so we haven't proven it yet. But I'm going to try. I hope that clarifies things!