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

Original Article ↗ Hacker News Discussion ↗

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.