Piku: Allows git push deployments to your own servers

Original Article ↗ Hacker News Discussion ↗

A lightweight tool called Piku aims to recreate Heroku-style “git push” deployments on your own servers without requiring Docker, appealing to developers who want simple, minimal infrastructure for side projects or small services. Commenters contrast it with alternatives like Dokku, CapRover, Coolify, Kubernetes-based platforms, and custom git hooks, weighing tradeoffs in isolation, long-term dependency management, resource usage, and operational complexity. Documentation quality, installation security (e.g., curl | sh one-liners), support for multiple runtimes, and integration with SSL, secrets, and zero-downtime techniques emerge as key factors influencing whether teams would adopt Piku over heavier PaaS or container-based solutions.

Project purpose and design

  • Piku provides a Heroku‑style “git push” deployment experience on your own server without requiring Docker.
  • It installs a small agent on the remote machine, which also acts as a Git remote; a local CLI is just an SSH shim.
  • Uses Procfile + env files, supports multiple runtimes (Python, Ruby, Node, Go, Clojure, etc.), and sets up nginx + a process supervisor (uwsgi) under the hood.
  • Automatic HTTPS via Let’s Encrypt is supported; some examples use it for small “micro‑apps” and webhooks.

Comparisons to other tools

  • Frequently compared to Dokku, CapRover, Coolify, Kamal, Epinio, and plain docker‑compose + reverse proxy.
  • Some prefer Docker‑based solutions for long‑lived, frozen environments and multi‑container setups.
  • Others value Piku’s minimalism, fewer abstractions, ARM support, and not needing containers at all.
  • Several note Piku’s low visibility compared to competitors despite being ~8 years old.

Docker, dependencies, and longevity

  • Removing Docker is praised as reducing complexity and overhead, especially on tiny or constrained systems.
  • Skeptics worry about OS‑level dependency drift for apps expected to run for many years.
  • Counterpoints: long‑term stability can be achieved with conservative distros (e.g., LTS), runtimes with strong backwards compatibility (Perl/Java), and tools like pyenv/Nix.
  • Some deploy via NixOS or Podman Quadlet instead, citing reproducibility, rolling back, and strong systemd integration.

Deployment workflows

  • Debate between direct git push to server vs CI‑driven webhooks that pull and deploy.
  • Several describe DIY variants: bare Git repos with post‑receive hooks, pm2 reloads, or NixOS rebuilds on push.
  • One view: “git is not a deployment tool” due to concerns about mixing source and production, secrets, and build artifacts; others argue hooks can handle builds and checks safely.

Operational concerns & features

  • Secrets: must be “bring your own”; examples include fetching from external key vaults via hooks or app startup.
  • Zero‑downtime: Piku currently restarts processes after deploy; full blue‑green or socket‑activation schemes are left to users, though ideas around systemd socket activation are discussed.
  • Multi‑node and advanced routing (e.g., wildcard subdomains, DNS challenges) are not clearly addressed; nginx integration exists but fine‑grained routing configuration is described as unclear.

Documentation and UX

  • New docs are praised visually but criticized for assuming prior knowledge; a community tutorial that explains internals and a full webapp example is seen as much more approachable.
  • Suggestions: prominent end‑to‑end tutorial from bare server to custom domain with SSL, and better surfacing of existing guides.
  • Install method via curl | sh raises security concerns; maintainers note alternative install methods (cloud‑init, manual steps) and that many users explicitly request a one‑liner.