Push to deploy. On a server or a cluster.
Connect a GitHub repo and every push builds and ships. Rubuz detects the runtime, builds the image on your server, adds SSL and swaps to the new version with zero downtime. On managed Kubernetes, the same push rolls out across your cluster.
refs/heads/main49c2e0b ("feat(api): add health endpoint")package.json and pnpm-lock.yaml. Selecting Node.js 22 alpine runtime.rubuz/app-green:49c2e0b (size: 94 MB).200 OK (latency: 3ms). Health verified.#b7190f8 (Node 22 • 1h ago)Deploy scripts break. Pushes shouldn't.
A script that pulls the code and restarts the process works until a build fails halfway. Then your site is down while you fix it.
Deploying by hand
- ✕Downtime on every restart: The old process stops before the new one is ready, so visitors see errors until it comes back.
- ✕A failed build takes the site down: If a dependency is missing or the build errors out, the running version is already gone.
- ✕SSL and proxy config by hand: You set up Nginx, certbot and renewal jobs yourself, and fix them when they drift.
- ✕Files lost on redeploy: Uploads written inside the app folder disappear the next time you rebuild.
Deploying with Rubuz
- ✓Zero-downtime swap: The new container starts beside the old one. Traffic moves over once it is up.
- ✓Failed builds change nothing: If a build fails, nothing is swapped. The running version keeps serving.
- ✓SSL included: Every app gets its own domain and a Let's Encrypt certificate, with no proxy config to write.
- ✓Persistent /data: Each app has a /data directory that survives every redeploy, so uploads and files stay put.
- ✓Roll back in one click: Pick an earlier commit and Rubuz deploys it again, so a bad push is one click from undone.
From push to live.
No pipeline to write and no build server to run. The image is built on your own server.
Runtime detection
No Dockerfile needed. Rubuz reads your repo, picks the runtime and builds the image on your server.
Zero-downtime swaps
Your app keeps serving while the new version starts. Rubuz switches traffic once the new container is running, then stops the old one.
Images from Docker Hub or GHCR
Already build images in CI? Point Rubuz at an image on docker.io or ghcr.io and it runs the same way as a repo deploy, under a domain like app.example.com.
Databases beside your app
Add Postgres, MySQL, Mongo or Valkey and it runs in its own container next to your app. Credentials arrive as environment variables.
The same push. Across a cluster.
Rubuz runs managed Kubernetes in your own DigitalOcean, Vultr or Linode account. Your app rolls out across the cluster with high availability and autoscaling, without the cost and complexity of EKS or GKE. Your provider bills you for the nodes directly.
- • Image built on the server
- • Health check, then switch
- • Old container stops
- • Rolling deploy across nodes
- • High availability
- • Autoscaling
Bring the stack you already use.
Rubuz detects the runtime from your repo. If you already publish an image, deploy that instead.
Node.js
package.json
Python
pyproject.toml
Go
go.mod
Rust
Cargo.toml
PHP
composer.json
Ruby
GemfileQuestions about deploying with Rubuz.
Does a deploy interrupt live traffic? ↓
No. The new container starts beside the old one, and traffic switches only once it is running. If the build fails, nothing changes and the current version keeps serving.
Can I deploy to Kubernetes instead of a VPS? ↓
Yes. Rubuz runs managed Kubernetes clusters in your own DigitalOcean, Vultr or Linode account, with rolling deploys, high availability and autoscaling. Start on a VPS and add a cluster when one server is no longer enough; both stay in the same console.
Do I need to write a Dockerfile? ↓
No. Rubuz detects the runtime from files such as package.json, pyproject.toml or go.mod and builds the image on your server, so there is no Dockerfile to write. If you already publish an image, deploy it from Docker Hub or GHCR instead.
How do I connect a repository? ↓
Connect your GitHub account in Rubuz, then pick a repo and a branch. From then on, every push to that branch builds and ships.
Where does the build run? ↓
On your own server. Rubuz connects over SSH, builds the image there and runs it in a rootless Podman container. Nothing else is installed or left running.
What happens to my files when I redeploy? ↓
Anything your app writes to /data stays. Each app's /data directory survives every redeploy, so uploads and generated files are not lost.
What if a push breaks something? ↓
Roll back. Your app's deploy history lists the commits it has run; pick the last good one and Rubuz builds and deploys it again with the same zero-downtime swap. Your next push carries on from the branch as usual.
Connect a repo. Push to ship.
Your first deploy runs on the server you already rent, with databases, SSL and backups handled for you.
✓ No card needed • 14-day free trial