// framework · padrino

Padrino: Sinatra, all grown up.

Admin panels, mailers, and mountable subapps — deployed with the same care as any modern Ruby stack.

Padrino occupies a lovely niche: bigger than Sinatra, smaller than Rails, and still shipping. Most Padrino apps in the wild are 5–10 years old — this guide focuses on migrating them onto a modern container platform without a rewrite.
2.7 → 3.3
typical Ruby version bump
2–5 days
container migration effort
0
downtime required
01 / 03

Modernize the Gemfile first

Before touching infrastructure, bump Ruby to 3.3 and Padrino to the latest 0.16.x. Run the test suite. Fix the deprecation warnings. This is 80% of the work.
02 / 03

Containerize without rewriting

Padrino apps often assume writable local directories for tmp/ and log/. Redirect logs to stdout and mount tmp/ as tmpfs — no code changes required.
ruby
# config/boots.rb (bottom) Padrino.logger = Padrino::Logger.new( stream: $stdout, log_level: :info, format_datetime: "%FT%T%z " )
03 / 03

Subapps as one container

Padrino's mountable subapps all share a single process. Don't try to split them into separate services during the containerization step — do it later, if at all.

Gotchas we learned the hard way

  • !The Padrino admin uses cookie-based sessions signed with a secret. Rotate it via env var, not by editing config/apps.rb.
  • !Older Padrino apps often use `padrino rake …` — use `bundle exec rake …` in containers, since padrino rake wraps in a way that eats signals.
  • !Legacy assets: precompile with `padrino rake sprockets:precompile` at image build. Do NOT try to migrate to Propshaft in the same PR as the containerization.

Official resources

Docs, repos, and training materials for this framework.

Related guides

Ready?
Move Padrino to the cloud

Heroku is often the gentlest first step — the buildpack still works. Then containerize when you're ready to move.