Cuber is an Apache-2.0 licensed, Ruby-based automation tool that packages and deploys applications written in any language or framework onto Kubernetes from a roughly ten-line Cuberfile and a single cuber deploy command, aimed at developers and small teams who want the simplicity of a platform-as-a-service without its cost or provider lock-in.

What it is

Cuber is an automation tool written in Ruby and distributed as the cuber gem. It reads a Cuberfile, a short configuration file of about ten lines, and uses it to build a container image, publish that image to a registry, and roll the application out to a Kubernetes cluster. The application itself may be written in any language or framework; the tool imposes no runtime. It lives in the Kubernetes deployment and developer tooling ecosystem, alongside topics such as buildpacks, continuous-delivery, deployment-automation, kubernetes-deployment, and paas, and its documentation is hosted at cuber.cloud.

The concrete problem it solves is Kubernetes complexity. Kubernetes is cheap and portable, but deploying to it normally requires many steps and configurations even though most applications share the same needs. Cuber standardizes that sequence into one declarative file and replaces the manual chain of building an image, tagging and pushing it to a registry, writing manifests, and applying them with kubectl. The stated goal is the simplicity of a PaaS at the cost of bare infrastructure.

Key capabilities

• A Cuberfile DSL with directives such as app 'myapp', repo '.', buildpacks 'heroku/buildpacks:20', image 'username/myapp', kubeconfig 'path/to/kubeconfig.yml', and proc :web, 'your web server command'.
• Automatic image builds through buildpacks, with the option to supply your own Dockerfile instead.
• Registry publishing via the image directive, for example image 'username/myapp'.
• Deployment to any Kubernetes cluster through a kubeconfig path, so no cloud provider is baked in.
• Single-command deploy with cuber deploy, covering both packaging and rollout.
• Status monitoring with cuber info, plus the ability to run and scale arbitrary commands on Kubernetes through proc declarations.
• Apache-2.0 licensing, with the source hosted on GitHub at rb/cuber.

Who uses it and how

• The project was built to scale Pushpad and has been used in production for many years, with a reported 100% uptime and an 80% reduction in cloud costs.
• It is used daily across several projects, including BuonMenu and Newsletter.page.
• It suits teams that already run their own Kubernetes cluster and container registry and want a repeatable deployment path rather than per-app manifests.
• It fits developers who want to move off hosted PaaS pricing while keeping the option to change cloud providers, since there is no lock-in.
• Because the deployed application may be in any language, it works for polyglot teams standardizing deployment without standardizing runtime.

Getting started

Install the prerequisites ruby, git, docker, pack, and kubectl, then run gem install cuber. Create a Cuberfile in the application folder, run cuber deploy, and check the result with cuber info; fuller instructions are in the installation, quickstart, Cuberfile, and CLI pages at cuber.cloud.

How it compares

The README names Heroku as the kind of hosted PaaS that Cuber is an alternative to, and claims Kubernetes can be up to 80% cheaper than such platforms. The contrast is licence, ownership, and cost model: Cuber is Apache-2.0, self-hosted, and run against infrastructure you control, so the code, images, and cluster stay yours, whereas a hosted PaaS is a managed service billed per unit of consumption. The trade is that the cluster, registry, and deployment plumbing become your responsibility rather than the vendor's.

When to use it — and when not to

Adopting Cuber means operating a Kubernetes cluster, a container image registry, Docker, pack, kubectl, and the credentials referenced by kubeconfig, so it is a poor fit for teams that want a fully managed platform with no cluster operations at all. It is also a small project by adoption signals, with 713 stars, 27 forks, and 7 open issues, and its README is short, so prospective users should read the cuber.cloud documentation before committing. Teams without Kubernetes experience, or those unwilling to run their own infrastructure, should look elsewhere.

$ gem install cuber

# Give a name to your app
app 'myapp'

# Get the code from this Git repository
repo '.'

# Build the Docker image automatically (or provide a Dockerfile)
buildpacks 'heroku/buildpacks:20'

# Publish the Docker image in a registry
image 'username/myapp'

# Connect to this Kubernetes cluster
kubeconfig 'path/to/kubeconfig.yml'

# Run and scale any command on Kubernetes
proc :web, 'your web server command'

$ cuber deploy

$ cuber info