I believe they were one of the best hosting providers for no-frill Python Django web apps. A lot of Python web app developers like me would appreciate a dedicated, easy migrate Django hosting website. Alas! :-(
back
1 comments
Agree. Heroku appears inferior to Ep.io in terms of how easy you can get a Django website up and running, and less flexible.
In our case, we use Brunch (node.js-based tool) to build client-side code. With Ep.io, we'd just build the code locally and then do `epio upload`. While Heroku requires everything to go through repository. Since it's impossible, I think, to run a Node.js tool directly on Heroku, we'd need to `git push` compiled code. It is not nice.
You can basically do anything you want on heroku because they allow custom buildpacks. You could make your own buildpack that vendors in node.js and your tool and builds at deploy time. Here's a heroku doc article all about it: https://devcenter.heroku.com/articles/buildpacks
Thanks for the correction, I didn't read the docs carefully. Buildpack's a better idea than building stuff locally. This makes slightly steeper learning curve the only weakness of Heroku compared to Ep.io.
No problem. They don't actually talk about buildpacks all that much but I see it as the major differentiating feature on Heroku.
One thing you may be interested in is heroku-buildpack-multi[1] which lets you run multiple buildpacks. You could theoretically use this to include the standard Python and Node.js buildpacks plus a small custom one that just installs and runs Brunch.
dotCloud has a comparable system called custom services. In addition to a custom build script you can also allocate arbitrary custom network ports (tcp/udp/http/websockets), as well as custom system packages.
I definitely agree with other comments in this thread that paas and orchestrated-iaas are on a collision course. Exciting times!
Either of the two workflows you mention are easily doable with dotCloud. Building locally (as you do today) should be fine: the dotCloud command line client uses git or hg (whichever you're using) by default, but can fall back to rsync if you want to push untracked changes[1].
In the long run, though, it's probably better to include the Brunch step as part of your build. With the new version of the dotCloud Python service[2], you can hack the build script[3] to do whatever you want. For simple build tasks, there's one version of Node already installed, but you could also poach part of the Node build script[4] to install another version, if you need it.
---
[1]: http://docs.dotcloud.com/guides/git-hg/#pushing-uncomitted-c...
[2]: https://github.com/dotcloud/python-on-dotcloud
[3]: https://github.com/dotcloud/python-on-dotcloud/blob/master/p...
[4]: https://github.com/dotcloud/node-on-dotcloud/blob/master/nod...