Deploying Hanami: modern Ruby, production-ready.: what should I watch out for? (#1)

Hanami's autoloader is Zeitwerk-compatible but strict — mis-named files fail at boot, not on first request. Good for prod, painful in monorepo migrations.

Deploying Hanami: modern Ruby, production-ready.: what should I watch out for? (#2)

Don't use `bundle exec hanami console` as a container entrypoint. Use `bundle exec hanami server` (or Puma directly).

Deploying Hanami: modern Ruby, production-ready.: what should I watch out for? (#3)

ROM connections are lazy. If your health check doesn't touch the DB, a broken DATABASE_URL won't surface until first traffic.

// framework · hanami

Hanami: modern Ruby, production-ready.

Slice-based architecture, dry-rb composition, ROM persistence — Hanami 2 is what a lot of Ruby people quietly wish Rails had become.

Hanami 2 is stable, opinionated in the good way, and ships beautifully. The deploy story looks a lot like Rails without the historical baggage — a container, a config, and a Postgres URL.

~0.9 s

boot time

68 MB

memory at idle

3–5

slice count you'll want

01 / 03

The Hanami container is your friend

Hanami's DI container means every dependency is explicit — which makes it trivial to swap in cloud-provided services (SES for mail, S3 for storage, Secrets Manager for keys) at boot time via providers.

ruby
# config/providers/mailer.rb
Hanami.app.register_provider(:mailer) do
  prepare { require "aws-sdk-sesv2" }
  start do
    register("mailer", Aws::SESV2::Client.new(region: ENV["AWS_REGION"]))
  end
end

02 / 03

Assets via esbuild

Hanami's asset pipeline uses hanami-assets + esbuild. Precompile at image build time (`bundle exec hanami assets compile`) and serve them behind a CDN — CloudFront, Cloud CDN, or Front Door.

03 / 03

Slices as deployment units

A large Hanami app can be split into multiple deployables that share the codebase but boot only certain slices. Use `HANAMI_SLICES=api,admin` to control what loads.

Gotchas we learned the hard way

!Hanami's autoloader is Zeitwerk-compatible but strict — mis-named files fail at boot, not on first request. Good for prod, painful in monorepo migrations.
!Don't use `bundle exec hanami console` as a container entrypoint. Use `bundle exec hanami server` (or Puma directly).
!ROM connections are lazy. If your health check doesn't touch the DB, a broken DATABASE_URL won't surface until first traffic.