Beyond Deploy: We Handle It All ― How We Grew Kamal into an In-house PaaS

Kaigi on Rails 2026: https://kaigionrails.org/2026/
Japanese version: https://speakerdeck.com/dkan75/no-saki-made-zenbu-mendou-o-miru-kamal-o-shanai-paas-ni-sodateta-hanashi

Transcript

1. Kaigi on Rails 2026 Beyond Deploy: We Handle It All ― How We Grew Kamal into an In-house PaaS Hiroyuki Kanda @dkan75 SonicGarden Inc. / Infrastructure Programmer From rails new to a live service in minutes. Behind it: a Rails app that wraps Kamal.
2. About Me & Today's Agenda Hiroyuki Kanda Infrastructure Programmer at SonicGarden About 15 years in IT infrastructure, mainly AWS Rails for just over a year (Ruby for 10+ years) Hobbies: tennis, DIY cat playgrounds Today's agenda 1. Why we built it 2. What we built 3. How we wrapped and leveraged Kamal 4. Takeaways "Isn't infrastructure management a great fit for Rails?" ― That's what I felt after building it My cats love high places 2
3. Why We Built It ― Our Apps Had Nowhere to Live "It might be shut down soon… hard to ask for a new environment" ― App developers "If apps scatter across outside PaaS and SaaS, we can't keep track…" ↓ ― Infra team What if we had an in-house place, ready anytime, right away? 3
4. What We Built ― Kamaly, a Wrapper Around Kamal Kamal ＋ y ＝ Kamaly Rails 8's default deploy tool One click to run No infra knowledge needed Just one letter (not a typo) Leave it to Kamal We build only "the outside" The in-house PaaS I'm talking about today Share resources wisely Servers and DBs, shared by all 4
5. Demo ― From Click to Running Minimal input Repository, master key, and so on DB, automatically DATABASE_URL already set Domain + TLS Public right away Logs & console In the browser 5
6. What Do You Need Before Using It? You need to write You don't need to write Dockerfile deploy.yml Solid Queue and other configs DB connection settings AI writes it AI writes it Generated by Kamaly Passed as Secrets (env vars) No need to add them to credentials Even for what you do write, we provide ready-made AI prompts. Just tell the AI in your repo 6
7. Who Does What, Step by Step User Add app Deploy Kamaly Kamal EC2 AWS ALB Initialize (create DB / S3) Generate deploy.yml Configure routing docker build docker run Clear lines of responsibility let Kamaly focus on designing "the outside" 7
8. Architecture ― Sharing Resources Across Apps Users / Internet ALB (shared by all apps) server-1 (shared) app-A 2GB app-B 1GB server-2 (shared) app-C 2GB Aurora PostgreSQL (shared) S3 (dedicated per app) Key Share wisely Servers & DBs, for all By design Keep it simple Not as heavy as K8s Low cloud vendor lock-in 8
9. "Sharing Wisely" Was Easier Said Than Done Users / Internet ALB (shared by all apps) A How to route? + New app app-D 1GB server-1 ! app-A 2GB app-B 1GB Kamal = Managed by Kamal server-2 app-C 2GB Kamal server-3 (add?) Apps are spread across servers, and their locations change B Where to place? Apps keep increasing. Humans shouldn t pick placement C When servers change? Added, replaced, or broken. Kamal doesn t handle this Outside Kamal is wider than you d think 9
10. A. Kamaly Decides Where, Kamal Delivers app-a.example.jp Layer 1 by Kamaly ALB app-c.example.jp Forwards to the servers Kamaly chose TG-b (2 servers) TG-a server-1 kamal-proxy Layer 2 by Kamal app-b.example.jp app-a TG-c server-2 kamal-proxy app-b Users only choose how many to run Placement and delivery are left to Kamaly and Kamal app-b app-c 10
11. B. Kamaly Picks a Good Placement ① Required ② Preferred Pick a server with "headroom" Filter by AZ spread Redundant apps always go to 2 AZs az-1 app app az-1 az-2 Different AZs app No AZ redundancy app az-2 → What counts as "headroom" shows the platform's character. For example ― Memory What if it overflows? CPU What if apps fight over it? 11
12. B. Memory Headroom: No Overcommit 8GB Free app-B 3GB app-A 2GB 0GB 8GB OS reserved server If app-A grows app-B 3GB OOM killed app-A 5GB 0GB OS reserved server Running out of memory directly causes outages Kamal enforces each app's limit; Kamaly checks free memory to choose placement 12
13. B. CPU Headroom: Overcommit Is OK A A B server C If app-A hogs CPU Slower B C server CPU contention just slows things down, so we allow overcommit How you share depends on what you value. Kamaly just implements that logic 13
14. B. Rebalanced Automatically on Every Deploy before 8GB after Free Free Free Free Free 3.5GB 4.5GB Free 4.5GB 4.5GB 4.5GB Redeploy 5.5GB app-X app-X 1GB Others 0GB server-1 app-X 1GB Others Others Others server-2 server-3 server-1 app-X 1GB app-X 1GB ← moved Others Others server-2 server-3 Every deploy naturally evens things out. Users just deploy as usual 14
15. C. Replacing a Server: 3 Steps in the Admin Panel ① Add server → ② Stop placement → ③ Drain apps server-1 is unhealthy. Add server-3 in the same az-1 server-1 server-2 app-B app-C app-A app-B (az-1) ⚠ unhealthy (az-2) server-3 (az-1) new (empty) Auto-detached from the ALB 15
16. C. Replacing a Server: 3 Steps in the Admin Panel ① Add server server-1 → ② Stop placement → Stop placement on server-1 Placement stopped server-2 (az-2) app-B app-C app-A app-B ③ Drain apps server-3 (az-1) (empty) Excluded from new placements 16
17. C. Replacing a Server: 3 Steps in the Admin Panel ① Add server → ② Stop placement → ③ Drain apps Apps drained. server-1 is empty and can be deleted server-1 Ready to delete (empty) server-2 server-3 app-C app-B app-B app-A (az-2) (az-1) Step ③ just redeploys the running version kamal deploy -P --version={running version} Then B's placement rules relocate apps. Operators just use the admin panel; users do nothing 17
18. Result ― Our Own PaaS, No Heavy Platform Needed With a heavy platform Cluster design & build A dedicated ops team With Kamaly ↓ 1 Rails app + Kamal Simple infrastructure Built alongside my day job Results 30+ Growing apps running naturally, on our PaaS One place Effortless nothing scattered no per-app tracking 18
19. Takeaways ― Kamal + Rails Can Build a PaaS 1 Only the outside Leave to Kamal what Kamal can do 2 Simple by design → Rebalance → Two-layer delivery by redeploying 3 Tools at hand ActiveRecord ActiveJob Solid Queue Turbo … Write your infrastructure in Rails, too 19
20. Behind the Scenes ― It Started on a Train September 2025 On the train to the venue, decided "Let's build this" After that Learning Rails alongside my day job February 2026 Kamaly goes live https://www.sonicgarden.jp/join_us/blog_articles/hyogo_hackation202510 August 2026 Over 30 apps Hackation = Hackathon × Vacation (a SonicGarden coinage) 20
21. Thank You for Listening