Git push to your own VPS: what Rubuz does, according to its docs (and what I'd check first)

2026-11-04来源 dev.toEnglish

Disclosure: Links to rubuz.com in this post are affiliate links. If you sign up through them I may earn a commission, at no extra cost to you. It was also written with the help of AI and reviewed by me. I haven't run Rubuz myself yet: everything below comes from Rubuz's public docs and product pages as of November 2026, with links, and I've flagged where those pages disagree with each other.

The trade-off it targets

If you ship side projects or small production apps, you've probably sat on one side of this fence:

  • A managed PaaS (Heroku-style) is easy until the bill grows with every app, database and preview environment.
  • A plain VPS is cheap, but then you are the deploy pipeline: a shell script that pulls and restarts, certbot cron jobs, apt upgrade on a Sunday, and a backup script you hope still runs.

Rubuz pitches itself as the middle: you keep renting the server (Hetzner, DigitalOcean, Vultr, AWS, etc.), and Rubuz acts as a control plane that connects over SSH and handles deploys, databases, SSL, backups and updates. The same idea exists in open-source form (Coolify, Dokku, CapRover, Kamal), so it's worth knowing what Rubuz specifically does and where it differs.

How it works, step by step (per the quickstart)

The quickstart is three steps:

  1. Provision a clean VPS running Ubuntu 26.04 LTS or Debian 13 (or newer). Examples given: Hetzner CPX11 / CAX11 (ARM64), a DigitalOcean Droplet, Vultr High Frequency, AWS Lightsail or EC2.
  2. Connect it in the dashboard: Servers → Connect Server, enter the IP, then either run a single setup command or let Rubuz connect with a temporary SSH credential. It sets up a rootless container runtime and the server turns green.
  3. Deploy a stack: pick an app from the catalog or connect a GitHub repo, give it a domain (or a free rubuz.site preview subdomain), click Deploy Stack.

Server requirements from Connecting your first VPS:

Requirement Value
OS Debian 13+ or Ubuntu 26.04 LTS+, 64-bit
RAM 1 GB minimum, 2 GB+ recommended for app + database stacks
Disk 15 GB SSD/NVMe
Server state Fresh, no cPanel / Plesk / CyberPanel
Open ports (cloud firewall) 80 (HTTP + ACME), 443 TCP/UDP (HTTPS + HTTP/3), 22 optional

The docs specifically warn against starting from a "1-click LAMP/LEMP" marketplace image; use a minimal OS.

Deploys: what happens on git push

According to the git-push feature page:

  • Runtime detection, no Dockerfile required. It looks for package.json (Node.js), pyproject.toml (Python), go.mod (Go), Cargo.toml (Rust), composer.json (PHP) or Gemfile (Ruby). You can also bring your own Dockerfile, or deploy a ready-made image from Docker Hub or GHCR.
  • The image is built on your own server, not on Rubuz's infrastructure. No separate CI runner.
  • Zero-downtime swap: the new container starts next to the old one, passes a health check, then traffic moves over and the old one stops. If the build fails, nothing is swapped.
  • One-click rollback to an earlier commit from the deploy history.
  • Persistent /data: each app gets a /data directory that survives redeploys, for uploads and generated files.

That last point is the classic VPS footgun (uploads written inside the app folder vanish on rebuild), so it's good to see it called out.

Databases and one-click apps

Per the pricing page, you can run Postgres, MySQL, MongoDB and Valkey beside your apps, each in its own container, with credentials injected as environment variables. Apps, domains and databases are not capped; the limit is your server's CPU, RAM and disk.

There's also a catalog of open-source apps; the About page lists n8n, Ghost, Metabase, Umami, Chatwoot, Vaultwarden and Open WebUI. Each gets its own container, domain, SSL and backups.

⚠️ Docs inconsistency: the Deploying Apps & Databases doc page lists MariaDB, PostgreSQL and Redis instead, and the quickstart mentions Next.js, Astro and Go as example app types rather than the six detected runtimes. The product pages look newer, but if you depend on a specific database, confirm it in the trial.

SSL and domains

From Custom Domains & Automated SSL:

  1. Point an A record at the server's IPv4 (and a www CNAME if you want it).
  2. In the app's Domains tab, Add Custom Domain → Verify DNS & Issue SSL.

Certificates come from Let's Encrypt via Traefik. Rubuz runs a DNS pre-flight check before requesting a certificate (to avoid burning Let's Encrypt rate limits on a misconfigured record) and renews 30 days before expiry. No certbot cron to babysit.

Security model

From Rootless Containers & Firewall Management and the pricing page:

  • Each app runs in a rootless Podman container under an unprivileged user namespace (UID 10000+), so root inside the container isn't root on the host.
  • The firewall (nftables) leaves only SSH, HTTP and HTTPS open publicly. Databases listen on loopback or the internal bridge network (10.88.0.0/16), not on the public interface.
  • Brute-force rate limiting on SSH and logins; team roles, 2FA and passkeys on the Rubuz account.

Rootless Podman is a meaningful difference from tools that run a privileged Docker daemon, which is the main thing Rubuz's docs lean on.

Backups

The backups page describes:

  • Restic snapshots, encrypted on your server before upload, of databases, app volumes (including /data) and config.
  • Sent to your own S3-compatible bucket: Amazon S3, Cloudflare R2, Wasabi, Backblaze B2, DigitalOcean Spaces or MinIO.
  • Scheduled, with one-click restore onto the same server or a fresh one (useful if the server itself dies).
  • Monthly restore tests: Rubuz replays database dumps into throwaway databases and alerts you if a test fails.

Automatic restore testing is the part most hand-rolled setups never get around to, so this is one of the stronger points on paper.

Lock-in: what happens if you leave

This is the question I'd ask of any control plane, and the pricing FAQ answers it directly: Rubuz says it installs no agent; it sets up standard Podman containers and system services over SSH. If you stop using it, your apps, databases and scheduled jobs keep running. If the free trial ends without a plan, the Rubuz account is locked but the apps on your servers keep running.

If that holds, the worst case of leaving is "back to managing a plain VPS by hand," not a migration.

Kubernetes, when one server isn't enough

The Managed Kubernetes doc says Rubuz can also run clusters in your own DigitalOcean, Vultr or Linode account (not AWS/GCP for clusters), with high availability, autoscaling and rolling deploys from the same console as your VPS servers. Nodes are billed to you by the provider; Rubuz charges for the platform. This is only in the higher "Kubernetes + VPS" plan.

What I'd check before committing

  1. Price. There is no public price. Both plans say "Talk to us," and the FAQ says pricing depends on how many servers and clusters you run. For a solo dev comparing against a $5–20/month PaaS bill, get a number before you migrate anything.
  2. Database list. Docs and product pages disagree (see above). Verify the one you need.
  3. OS versions. It requires Ubuntu 26.04 LTS or Debian 13+. Older images you already run won't qualify; plan on a fresh server.
  4. Region and provider fit. Any provider reachable over SSH works for VPS, but managed Kubernetes is limited to DigitalOcean, Vultr and Linode.
  5. Compare with the open-source options. Coolify, Dokku, CapRover and Kamal cover overlapping ground for free if you're willing to run and maintain the tool yourself. Rubuz's case rests on being hosted (nothing to operate), rootless Podman, and the backup/restore-testing story.

Trying it

There's a 14-day free trial with no credit card. The cheapest honest test is: a fresh 2 GB VPS, one small repo with a health endpoint, one Postgres database, a test domain, and a backup to an R2 or B2 bucket, then deliberately break a deploy and restore onto a second fresh server.

👉 Start a Rubuz trial (affiliate link: I may earn a commission if you subscribe, at no extra cost to you)

If you try it before I do, I'd like to hear how the build times and the restore-onto-a-new-server flow hold up in practice.

Sources (accessed November 2026)

原文：https://www.a8q9.cn/en/article/git-push-to-your-own-vps-what-rubuz-does-according-to-its-docs-and-what-i-d-chec-656a0c.html

相关文章