Show HN: A CLI tool I made to self-host any app with two commands on a VPS

Original Article ↗ Hacker News Discussion ↗

A new open-source CLI tool aims to make deploying custom apps to a single VPS as easy as running two commands, bundling Docker-based deployment, automatic TLS via a reverse proxy, and zero-downtime updates. Commenters compare it to tools like Fly.io, Kamal, Dokku, and plain Docker Compose, debating trade-offs between convenience and understanding the underlying stack, as well as registry use, containerization vs “bare metal,” and whether features like Swarm, Firecracker, or Kubernetes are necessary for side projects. Many see it as a promising middle ground for self-hosters who want simpler, repeatable deployments without adopting full-blown PaaS or complex orchestration.

Overall reaction

  • Many commenters are enthusiastic about the tool’s simplicity: “two commands” to get from bare VPS to running app, with zero-downtime deploys and automatic TLS seen as standout features.
  • Several people say they already have custom scripts/Ansible/Docker Compose setups, but would still try this because it lowers friction for side projects.
  • Some feel they’d rather keep manual control (Compose + reverse proxy + certbot) and see this more as a convenience layer than a necessity.

Intended use case & comparisons

  • Target use case is clearly personal apps/side projects on a single VPS, not large multi-node deployments.
  • Compared often to Fly.io (“imagine fly.io on your VPS”), Kamal, Dokku, CapRover, Coolify, Portainer, and homegrown Ansible setups.
  • Distinction from Kamal: Kamal is described as more “one big app per VPS” and more Rails-centric; this tool explicitly aims at multiple projects on one box.
  • Some see it as close to “Dokku + provisioning/setup,” which they consider ideal.

Docker, deployment model, and registry

  • Tool is container-centric; some Docker skeptics argue simple binaries and systemd are easier and more reliable for single-OS deployments.
  • Others strongly defend Docker/Compose for isolating dependencies, simplifying migrations between servers, and running mixed workloads.
  • Question raised: why require a registry? Author’s rationale (from thread) is: build images on the dev machine, keep source off prod, and push images instead of building on the VPS.
  • Alternatives suggested: docker save/load over SSH or a local/private registry to avoid external dependencies.

TLS, reverse proxy, and networking

  • Automatic TLS via Traefik is widely appreciated; several note that nginx + certbot automation is fiddly.
  • Some users describe alternative patterns:
    • Cloudflare Tunnels or similar to avoid exposing ports and offload HTTPS and some security.
    • Caddy as a simpler auto-HTTPS reverse proxy.
  • Concerns raised about Cloudflare lock-in, reliability of tunnels, and extra latency vs. direct nginx/Caddy.

Databases, backups, and reliability

  • Roadmap includes database support; commenters push hard for:
    • Built-in streaming backups (Litestream for SQLite, Barman for Postgres) and possibly a dedicated backup VPS.
    • Clear restore workflows and monitoring of replication health.
  • There is a broader argument that many self-host tools lack robust, integrated backup/restore, which some see as a serious gap and others dismiss as overkill for hobby projects.
  • Suggestions include filesystem-level snapshotting (e.g., ZFS) versus app-specific backup logic; others note most VPS users just rely on provider snapshots or simple dumps.

Swarm, Kubernetes, and orchestration scope

  • Question raised: why not Docker Swarm? Some argue Swarm (in single-node mode) already provides zero-downtime, rollbacks, secrets, etc.
  • Author clarifies the tool targets a single VPS and does not use Swarm; another commenter notes Swarm’s confusing “classic vs new” history but that current Swarm is maintained.
  • Kubernetes is generally seen as overkill here; some report long-term stability issues with managed Kubernetes vs. simple Docker/Compose on a VPS.

Security and VPS lifecycle concerns

  • Requests for extras: basic WAF or intrusion blocking (fail2ban/CrowdSec), VPN/zero-trust access, and clearer explanation of sops/age-based secrets.
  • Some question the value of encrypting env files on the VPS when the decryption key is also there; others point out it still protects against all users who can SSH but don’t hold the key.
  • A few ask for guidance beyond initial deploy: OS patching, Docker upgrades, upgrading stateful services like Postgres, and migrating to a new host. They see this “long-term ops” story as missing in most similar tools.

Platform, multi-app, and OS choices

  • Clarifications sought on whether multiple apps per VPS are supported (they are, per responses in thread).
  • Some want docker-compose support, deploy hooks (pre/post deploy), Mac mini or non-Ubuntu support, and possibly anycast/multi-region in the future.
  • One commenter questions Ubuntu as the base, preferring Debian and disliking snaps; others note recent Ubuntu is “fine by default,” but this remains a taste/ops preference.