You can find a lot of information and technical documentation on the project website: https://cuber.cloud
Finally note that Kubernetes can be 80% cheaper than Heroku or other PaaS, because it is bare infrastructure. Kubernetes is also offered by most cloud providers, and thus you avoid lock-in with a single service provider.
I’m here or on GitHub if you have any questions or requests.
Very cool to see a project combining Rails with kubernetes. I feel the Rails community has not not (yet) embraced the technology. I’ll give it a go!
One remark I’d like to make on the cost side of things. Running your own infrastructure and not using something like Heroku can be costly in the sense that you’d have to maintain the infrastructure yourself or your team. But this will very greatly from situation to situation.
I think that the main difference is that Cuber deploys to Kubernetes, while the project that you mention deploys on bare servers. Horizontal scaling is very easy with Kubernetes, compared to spinning up / managing servers manually.
the service that would work better for me has a lot less configuration by default
Cuber already has a very compact configuration.
For example writing “worker :sidekiq” instead of “proc :worker, 'bundle exec sidekiq'” is only a limitation in my opinion: with Cuber syntax, similar to a Procfile, you can spin up different working processes with different command line options (and not just one generic sidekiq process). Also note that Cuber allows you to run any process, not only a few pre-defined processed defined as plugins.
Finally note that the example code in your post is not exactly equivalent to my example above: in my example above I have included many configurations that are optional, but usually useful for a Rails app. It’s difficult to discuss this in general: if you see a specific field / command that can be simplified I would be happy to analyze it.
@mvz I have heard about that project but I have never used it in production, so I can’t say if it’s reliable. Probably there are hundreds of small differences and different architectural choices, since they are completely different projects. One major difference is certainly that Cuber is written in Ruby, but it can deploy any app, in any language and framework. Another difference that I see is that, while Cuber is standalone (based only on a few major / stable projects like docker and kubectl), Kuby seems to make large use of external components (e.g. kubedb, plugins, etc.).
Note that Cuber is not a provider, it’s just an automation tool, like Capistrano, that you install locally on your machine or on your CI/CD pipeline.
When you use Cuber, in the cloud you will have only Kubernetes and your app: you can use any cloud provider, including DigitalOcean, Vultr, Google Cloud, AWS, or any other Kubernetes-certified provider.
This means that you don’t have lock-in and you can choose the cheapest / best cloud provider.