Cuber: a Cuberfile instead of raw Kubernetes manifests

A deployment tool that deliberately offers fewer options

Cuber is a Ruby automation tool that packages and deploys applications written in any language and framework onto Kubernetes. The positioning is unusually blunt about the trade it makes. Where other tools add options and complexity to Kubernetes, Cuber is described as built to simplify and reduce that complexity, so that deployment becomes more standardized and reliable.

The stated argument against Kubernetes is that it is complex and requires many steps and configurations, even though most applications share the same needs. Cuber aims to give you the simplicity of a platform as a service while leaving you the bare infrastructure underneath. The project also frames the cost side of that trade, claiming Kubernetes is up to 80% cheaper than a PaaS like Heroku and that you can choose between cloud providers with no lock-in.

The result is that a deployment is a single file and a single command. You create a Cuberfile, described as roughly ten lines of code, and then run cuber deploy to package the application and send it to any Kubernetes cluster.

Who this is for is fairly clear. It is for a team that has already chosen Kubernetes, or wants to leave a PaaS without accepting that the platform owns the runtime, and that would rather express an application in a small declarative file than maintain a directory of YAML. The audience is also sensitive to a specific operational fact: a PaaS gives you a running application and hides the machinery, whereas a cluster gives you visibility and control but demands expertise. Cuber sits between the two, taking the PaaS-shaped interface without taking the PaaS bill.

The Cuberfile is the whole configuration surface

The quickstart example in the project documentation is the entire model. A Cuberfile is a small Ruby file, and each line declares one thing about the application:

# 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'

Because it is Ruby rather than a bespoke config format, the file can hold logic, and the `app` directive taking just a name is a good example of how little you have to spell out.

The build step is the interesting one. The `buildpacks` directive points at a buildpack image, here heroku/buildpacks:20, and the comment says the Docker image is built automatically, with an alternative to provide a Dockerfile instead. In other words, Cuber does not require you to write a Dockerfile to deploy, which removes one of the most common reasons a team that wanted a simple deployment ended up maintaining container build files anyway.

The `proc` directive is what makes the model feel like a PaaS. It names a process type,:web in the example, and the command to run for it, and the comment says the process can be run and scaled on Kubernetes. That is a process model rather than a container model, and it is why the Cuberfile is roughly ten lines instead of a hundred lines of Deployment and Service YAML.

For anything the file cannot express, the answer is to go back to kubectl. The project points to separate documentation for the Cuberfile configuration and the CLI commands.

Install path, deploy, and the one command that tells you what happened

Cuber assumes a machine that can already talk to Kubernetes, so the prerequisite list comes first: ruby, git, docker, pack, kubectl. The pack binary is the one worth pausing on, since it is the Cloud Native Buildpacks packer that does the image build, and the presence of a Docker requirement alongside it tells you the build path is a container build rather than a native compile.

With those in place, the tool itself is a Ruby gem:

$ gem install cuber

Deployment is then a single command run from the application directory:

$ cuber deploy

And the project offers one more command for checking what the cluster thinks is happening:

$ cuber info

That trio is the whole day-to-day workflow, and it is worth being clear about what each step does. The deploy command reads the Cuberfile, builds the application image using the declared buildpacks, pushes it to the registry named in the `image` directive, and applies the result to the cluster named by the `kubeconfig` directive. The `info` command then reports the status of the deployed application, which is the check you would otherwise do by reading pod status from kubectl.

Because the image is pushed to a registry as part of the deploy, the registry credentials and the kubeconfig both have to be in place before the first run. There is no separate publish step in the documented flow, which is convenient and also means the first deployment fails for reasons that have nothing to do with your application code.

The production claim, and what it rests on

The project makes a specific claim about production use: it was built to scale Pushpad, it has been used in production for many years and is described as stable and reliable, and the author says they reached 100% uptime while saving 80% on cloud costs. It also says the tool is used every day for several projects, naming BuonMenu and Newsletter.page among them.

The cost figure is worth reading carefully. It is presented in the same breath as the claim that Kubernetes is up to 80% cheaper than a PaaS like Heroku, and both are the project's own numbers rather than a measurement you can reproduce from the repository. A 100% uptime claim over a long production run is meaningful in a way that a synthetic benchmark is not, since it implies the deployment path did not break under real traffic. But neither figure tells you anything about how hard the tool is to operate, which is where the real cost of a deployment tool lives.

The release history gives a partial answer to that. The tags are v1.14.0 on 2026-04-12, v1.13.0 on 2024-09-02 and v1.12.0 on 2024-07-27, so the current version is a minor bump after a gap of about a year and a half, with a steady patch cadence inside the earlier series. The last push was on 2026-04-12, the same day as the newest tag, so the working tree and the published version agree.

The gem is Apache-2.0 licensed, which matters for a deployment tool because it is infrastructure code that a team will inevitably want to patch. The repository is a small Ruby project: a bin/ directory, a lib/ directory and a gemspec, with no vendored Kubernetes manifests to read, because the manifests are generated rather than shipped.

Where Cuber is the wrong tool

The first limitation is the Cuberfile itself. It has directives for a name, a repository, a buildpack, an image, a kubeconfig and a process, and that is a deliberately small surface. A real application with several services, an ingress with path routing, a sidecar, a custom resource, a cron job or a service mesh will not fit in ten lines, and the parts that do not fit are back to hand-written manifests that now have to live alongside a generated set. Two sources of truth for the same deployment is a familiar source of drift.

The second is the abstraction cost. The `proc` directive is convenient, and it is also a translation layer between a PaaS process model and Kubernetes objects. When something goes wrong, the question becomes which object Cuber generated and how, and the answer is not in your repository, because the generated YAML is not checked in. Debugging a deployment means reading the gem source or the produced resources on the cluster.

The third is the prerequisite surface. The tool needs ruby, git, docker, pack and kubectl on the machine, and it needs a registry and a working kubeconfig with the right permissions. For a laptop that is five tools to keep installed. For a CI runner it is five tools to keep in the image, and a version mismatch between them and the cluster is a failure mode of its own.

The fourth is the deployment target. Cuber deploys to a Kubernetes cluster, so it does not help a team that wants to deploy somewhere else, and it does not remove the need to understand Kubernetes. The complexity it removes is the complexity of writing manifests, not the complexity of running a cluster. A team that has never operated Kubernetes will find that the hard part is unchanged.

Editorial conclusion

Cuber suits a team that has decided to run on Kubernetes but wants the deployment experience of a platform as a service, since a Cuberfile hides the manifest generation, the image build and the rollout behind one command, and the Apache-2.0 licence lets you read and change all of it. It is the wrong choice for a team whose applications need custom resources, hand-tuned manifests or multiple services with their own ingress rules, because the Cuberfile is a narrow surface and everything outside it is back to kubectl. Before adopting it, install the five prerequisites, write a Cuberfile for one real service, run cuber deploy against a staging cluster and then cuber info to confirm the rollout, and read the Cuberfile configuration reference first, since the last push to the repository was on 2026-04-12 and the newest tag is v1.14.0.

Frequently asked questions

Official sources

1. cuber-cloud/cuber-gem on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases