I'd be curious to see why you're having issues setting up Dokku on Digital Ocean. They provide a one click image, so you should be able to just deploy the new instance, setup DNS (the two A records-- one of them is a wildcard), visit the instance's IP address and click Finish Setup, and then deploy your application.

Have you tried doing a really simple sample app? It may take some coercing to get an existing Heroku app to run (there's some differences between Heroku's buildpacks and Dokku, like in the PHP buildpack). I did write a blog post on the topic of DO-with-Dokku specifically not too long ago, which goes over deploying a "hello world" Node app: http://www.andrewmunsell.com/blog/dokku-tutorial-digital-oce...

I've had the same overall experience as kohanz with Rails. Little toy apps do work but details are sparse while trying to troubleshoot things. I'd probably wait for Flynn to mature and look at that before investing much more time in Dokku.

Of note for anyone reading: 1. Since the buildpacks are based on Heroku, if you're having trouble try seeing what it'd take to get your app deployed there. For example with Rails 3.2, if you pre-compile your assets on the production server while deploying an app it will try to instantiate your app and test a database connection; however, Dokku doesn't provide the database configuration until after this step of the deployment so your deploy will fail. This is fixed by either pre-compiling locally or changing a setting in application.rb. In Rails 4 I believe you just have to precompile your assets and check them along with the manifest into your repo. (Ref: https://github.com/progrium/dokku/issues/165, https://github.com/progrium/dokku/issues/202)

2. It's probably easier to just set up a separate database rather than relying on one of the project's plugins. Right now they're just a little too obfuscated and hard to troubleshoot (the dokku-postgresql plugin I used would lose its persistent volume on server reboot).

Part of that, for me at least, was dokku's eternally moving goalposts. It's been under pretty heavy development, and APIs/setup methods changed pretty rapidly. I'd get it going one week, come back in a month, and enough would have changed that I'd have to reinstall.

Now that releases are being tagged (0.2.0, for instance), using it in a semi-stable manner should be easier :).

>Part of the big ease of Heroku is, that you don't have to create Heroku before you use it.

I agree. It defeats the purpose of services like Heroku where users want a place to upload code and have it just work.

You also make a good point on maturity. It took many engineers years to make Heroku a mature product and keep it humming.

I do think this stuff is cool though. There's definitely a place for this sort of thing but I don't know if it should be marketed as PaaS. As soon as something becomes DIY, I would stop considering it SaaS or PaaS.

Full disclosure: I'm an Engineer at Salesforce which owns Heroku

One advantage I can see to something like this is that unlike Heroku, it could be made suitable for enterprise companies scared of the idea of having your software/data on hardware you don't own.

That being said, I agree 100% for pretty much every other use case.