Josef Strzibny's wroclove.rb 2026 talk (alt title 'Kamal vs PaaS and how to make better steaks'). Argues Kamal isn't harder than a PaaS and can save money if you're already spending a lot. Covers Kamal fundamentals (app vs accessories with separate life cycles, Kamal proxy for routing and health-checking, blue-green gapless deploys requiring more RAM than expected, Docker named volumes vs directories); requirements (SSH keys, Docker, a Rails-style Dockerfile exposing port 80 with a health check, bin/thrust for asset caching, SSSL/force_ssl and host-authorization exclusions for health endpoints); a Digital Ocean Ubuntu droplet bootstrapped via a cloud-init script (apt upgrade, Docker, curl utilities, unattended-upgrades, fail2ban, UFW for ports 22/80/443 + 10.0.0.0/16, chrony time sync, swap space, non-root 'pass_admin' user in the docker group with sudo, disabling root SSH, optional Tailscale mesh VPN); cloud firewall layered on top (HTTP/HTTPS public, SSH or Tailscale UDP, intra-VPC); Kamal config walkthrough (service, image, local Docker registry by default, proxy host, secrets split into clear env + secrets, CPU/memory options for multi-app VMs, aliases like kamal console/logs/apps/nth, builder architecture, non-root SSH user); a demo app using SerpApi to track Google keyword rankings, backed by SQLite with Litestream replicating WAL to Cloudflare R2 as a Kamal accessory (user 1000 to match Rails Dockerfile); kamal setup, kamal audit, fail2ban logs for debugging; Digital Ocean's do-agent for VM CPU/memory/network metrics and alerts; restore flow from Litestream (list snapshots → maintenance mode → stop Litestream → rm files → restore → boot → kamal deploy); rebuild on a new server or host another app by reusing Kamal init with a different service name. Closes with 'Kamal is olive oil for everything' and Gordon-Ramsay analogy, and a reminder that you are not Chuck Norris.