4 ms·

This is intriguing, but it kind of goes against the essence of running Dokku. We run Dokku because it's absolutely dead simple. It's not the fastest nor is it

This is intriguing, but it kind of goes against the essence of running Dokku. We run Dokku because it's absolutely dead simple. It's not the fastest nor is it particularly scalable, but it works. There will be a point where we can't scale with just Dokku, but we'll cross that bridge when we come to it.

pawurb 8y ago
What you mean by essence ? It's a relatively simple config tweak that significantly increases comfort and stability of Dokku deployments, even in production environments. Going for a more "serious" deployment platform you would have to learn from scratch would be a better solution ?
- undecisive 8y ago
  Thanks for the blog post - it has opened my eyes to something dokku can do - I didn't even consider looking at it from that angle! For me, the down side is flexibility. If I have a single project that I'm working on that pays all my bills, this approach is perfect. But buildpacks do a lot more than just bundling and assets - and I like the fact that I can change the ruby version in my Gemfile and suddenly my server is using a different version of ruby. That doesn't make this suggestion bad - I like that Dokku can be used in these two very different ways, and I have a couple of projects where this approach could be very useful. So thank you again!
undecisive 8y ago
Agreed. As someone currently moving my infrastructure to Dokku, where I have legacy apps on a range of ruby and non-rubies, this approach isn't scalable for my needs. That said, I wonder if there is a middle ground - where we can use this technique to build a docker container that keeps the copy of ruby, holds known gems, sass caches, etc... all the expensive operations get quietly persisted, but the buildpacks still get run. This container could be created on a per-project basis, so maybe the first push would take longer than the others and that's fine, but instead of it taking 10-15 mins to push a project update, it could take less than 5? One day I might even find the time to try...

pawurb 8y ago

What you mean by essence ? It's a relatively simple config tweak that significantly increases comfort and stability of Dokku deployments, even in production environments. Going for a more "serious" deployment platform you would have to learn from scratch would be a better solution ?

undecisive 8y ago
Thanks for the blog post - it has opened my eyes to something dokku can do - I didn't even consider looking at it from that angle! For me, the down side is flexibility. If I have a single project that I'm working on that pays all my bills, this approach is perfect. But buildpacks do a lot more than just bundling and assets - and I like the fact that I can change the ruby version in my Gemfile and suddenly my server is using a different version of ruby. That doesn't make this suggestion bad - I like that Dokku can be used in these two very different ways, and I have a couple of projects where this approach could be very useful. So thank you again!

undecisive 8y ago

Agreed. As someone currently moving my infrastructure to Dokku, where I have legacy apps on a range of ruby and non-rubies, this approach isn't scalable for my needs. That said, I wonder if there is a middle ground - where we can use this technique to build a docker container that keeps the copy of ruby, holds known gems, sass caches, etc... all the expensive operations get quietly persisted, but the buildpacks still get run. This container could be created on a per-project basis, so maybe the first push would take longer than the others and that's fine, but instead of it taking 10-15 mins to push a project update, it could take less than 5? One day I might even find the time to try...