Mike was the very first person to come on board when we opened our sponsorships last year. His early support gave me the confidence to commit a dedicated day per week to this project, which helped us achieve everything we did in 2025: shipping our biggest release yet, growing our maintainer team, and beginning to unify our community and ecosystem.

We're excited to continue our work in 2026. This year you'll see us launch our new face to the world, bring you two exciting releases of Hanami, and more! Thank you Mike for helping make this happen.

We’d love to have you to join Mike in support of our work. Visit our sponsorship site to learn more.

I’m very pleased to share our State of Hanami update for 2025! We’re back for our second time. If you want to get caught up, check out our update from last year.

This has been a pivotal year for Hanami, our first steps into a new era: we made a substantial new release, began unifying our ecosystem, expanded our team, launched our sponsorship program, and saw a real uptick in community activity.

I’ll go into all these highlights below, before leaving you with some plans for 2026.

Our biggest release yet

In November we released Hanami 2.3. This was our first major release in a year, and it turned out to be our biggest release yet, with 32 different contributors choosing to make Hanami better. Hanami 2.3 introduced Rack 3 support, resource routing, improved media type handling, along with a wide range of DX improvements. We’d love for you to give it a try!

Our ecosystem came together

Our maintainers this year have been taking care of Dry and Rom in addition to Hanami. We’ve been working towards bringing these projects together under a single banner. As part of this, we’ve chosen a new overall project name, and have been developing a new website and unified branding. Together, these will reintroduce us to the Ruby world and give our users an easier time learning our tools. We plan to launch these in February, but in the meantime, you can check out the source code and the in-progress live site (our guides are already looking particularly fine).

Our team grew again

This year we welcomed nine new people to our maintainers team:

• Aaron Allen
• Andrea Fomera
• Damian C. Rossney
• Josephine Hall
• Krzysztof Piotrowski
• Max Wheeler
• Paweł Świątkowski
• Ryan Bigg
• Sven Schwyn

These joined our existing team members, who have continued to work over the last year:

• Aaron Moodie
• Adam Lassek
• Kyle Plump
• Marc Busqué
• Nikita Shilnikov
• Philip Arndt
• Sean Collins
• Tim Riley

Thank you to all these beautiful people for giving their time to Hanami and for improving our part of the Ruby world!

All up, our maintainers team is now 17 strong. This feels like a good foundation for us to step up and do even better work next year. If you’d like to get involved, we recommend helping to triage issues and evaluate pull requests.

Our community shone through

Our community took things to a new level this year:

• We launched our Discord and saw it bring more community activity than ever before.
• We saw the launch of several new open source Hanami apps, including Princeton University Library’s orcid_princeton_hanami, which is also running in production! Huge props to Carolyn Cole for driving that project and sharing her thoughts on the process. We also saw the release of Pat Allan’s Playsmith, Ryan Bigg’s Twist v3, and our very own upcoming website. Meanwhile, Paweł continues to keep Palaver up to date as one of the most complete example apps out there.
• Edouard launched the new (commercial) Catalogue Studio, after leaving us a brilliant trail of “Tips and notes about [his] journey” from Hanami 1.3 to 2.2.
• Andrea Fomera arrived on the scene with a meteorological level of energy. She contributed some key pieces to Hanami 2.3, and also created hanami-omakase as a proving ground for Rails-alike features.
• Ryan Bigg pointed his big blogging brain our way and penned his “Hanami for Rails developers” series. With Ryan now on the team, we’re looking forward to creating our very own “for Rails devs” guides in the future!
• Andrew Nesbitt shipped hanami-sprockets, an alternative asset bundler and proving ground for the pluggable bundlers we’d like to ship next year.
• Andrew also helped us get our new awesome-hanakai repo off the ground. There’s still a bit of tidying to do, but it exists, and that’s the important thing. If you have something awesome, now you know where to put it!
• Did I mention our Hanami 2.3 release saw input from 32 different contributors? This is amazing! Thanks in particular to Wout and Armin for multiple helpful contributions across the year.
• Starting in August, I’ve also been sharing my weeknotes covering Hanami development. I hope you find them helpful!

Our community is the most important thing to us. To reflect this, this year we made our community values clearer than ever, and placed them front and centre on our website:

We want the Hanami community to be a welcoming place for people who bring kindness, curiosity, and care. A place where people of all backgrounds and experience levels can feel respected, and can share and grow. A place for people to be proud of, and feel safe within.

We do not tolerate nazis, transphobes, racists, or any kind of bigotry. See our code of conduct for more.

We also adopted the Contributor Covenant 3.0, which brings a more approachable text for our worldwide community, and places a helpful emphasis on restorative justice.

I believe our values have played a big part in the health and growth of our community this year. Thank you to everyone for building a space we can all enjoy!

We went out into the world

Once again, we took ourselves to some conferences!

• Tim visited beautiful Riga, Latvia for Baltic Ruby, where he presented a new Murakami-themed introduction to Hanami, and thoughts on the importance of a diverse Ruby ecosystem. He also ran a hack session, where Ismael Celis used his sourced toolkit to create the world’s first event-sourced calculator built on Hanami, and Krzysztof worked on the db rollback command for Hanami 2.3. Thank you to Baltic Ruby for the invitation!
• Sean attended Rocky Mountain Ruby in Boulder, Colorado, and spoke on Slicing and Dicing through Complexity with Hanami. He also got to spend some quality time with some #HanamiFriends new and old!
• Tim was lucky enough to reprise his talk at both XO Ruby San Diego and thoughtbot Open Summit. Thanks to XO organiser Jim Remsik, the San Diego talk was streamed to the internet, and the Open Summit was a native online event. We saw a good-sized group come together for each one, and I’m really glad I could share Hanami in such an open way. Thank you to Jim and thoughtbot for making these happen!

We launched our sponsorship program

This year we launched our first ever sponsorship program for Hanami, Dry and Rom. These are big and ambitious projects, and they need consistent attention for them to grow. Thanks to the support of the Ruby community, we made this happen! Since February this year, I’ve been able to commit a full business day every week towards the stewardship of our projects.

This could not have happened without our founding patrons. Thank you to Sidekiq, Brandon Weaver, Honeybadger, FastRuby, and AppSignal for your support! Your courage and belief is what got this thing off the ground in the first place.

Thank you also to all the individuals who are supporting us through GitHub sponsors. There are 20 of you right now! There’s real power in numbers, and your support takes us further than we could go alone.

We’ll run another sponsorship drive toward the middle of next year, but we are ready to accept your support at any time! See our sponsorship site to learn more. A few more businesses, or growing from 20 to 40 individual supporters, would make a huge difference to our project. And as you can see from everything in this post, your support goes a long way.

We have also ceased our relationship with Ruby Central as a fiscal host, following their removal of the Bundler and RubyGems.org maintainer teams from those projects, and their conduct thereafter. We stand with every maintainer.

Looking forward to next year

Just like last year, we have some goals we want to pursue across 2026:

• Establish a twice-a-year release cycle for Hanami. Right now we’re aiming for May and November.
• Finish unifying our ecosystem. We’ll launch our new site, finish rolling out our repo sync and release automation, then look at merging our forums.
• Prepare the future for Dry and Rom. We want to reinvigorate these gems and make things easier for new contributors. This means triaging issues, bringing on focused maintainers, and developing roadmaps for the next phase of these projects.
• Enter a successful second year of funded maintenance. Year one proved we could do this. Year two will show us whether we can sustain it. We’re looking forward to your support!

We’ll share more on each of these as we work through the year.

In the meantime, that’s it from us for 2025. Thank you to everyone who contributed to a wonderful year of improvements. We’re looking forward to continuing the work!

Built for Rack 3

We are excited to bring Rack 3 support to Hanami! We now support both versions 2 and 3, so you can use whichever version of Rack suits your situation. We encourage you to upgrade Rack when you can, and we’re happy that Hanami can help you on this path.

When you upgrade to Rack 3, check out the Rack 3 upgrade guide. Hanami already handles the essential changes for you, but you may need to update your app code if you’re working with Rack request/response details.

Streamlined from route to response

More than just Rack, we’ve refined all aspects of our routing and request handling layer. The biggest change is the return of resource-based routing.

To set up RESTful routes, you’d previously add the following lines:

# Previously...
get "/books", to: "books.index", as: :books
get "/books/:id", to: "books.show", as: :book
get "/books/new", to: "books.new", as: :new_book
post "/books", to: "books.create"
get "/books/:id/edit", to: "books.edit", as: :edit_book
patch "/books/:id", to: "books.update"
delete "/books/:id", to: "books.destroy"

Now, all you need is one:

# Now! 🥰
resources :books

Resource routing is integrated with every aspect of routing. Resources can be customized, nested, and combined with scopes and ordinary routes. Learn more here.

The improvements don’t stop there! With this release:

• Route scopes can be given custom name prefixes.
• Routes can be named with a prefix that precedes scope prefixes.
• Router runtime performance is considerably improved for large numbers of routes.
• Multipart form and JSON request bodies are parsed by default.
• Action format and media type config is clearer and more flexible.
• You can access your subdomains via Request#subdomains, and configure your TLD length.
• When you add 'nonce' to your content security policy, nonces are automatically added to script and stylesheet tags.
• CSRF tokens are loaded from the X-CSRF-Token header in addition to request params.

DX in the details

We’ve also improved many more of your day-to-day interactions with Hanami:

• hanami new now initializes a Git repository for new apps. You can also provide --skip-view to skip the view layer, as well as --gem-source, so you can use gem.coop from the get-go.
• New apps get a helpful bin/setup script, as well as an improved README with a handy list of first steps.
• New apps also receive a bin/hanami binstub, so you can invoke bin/hanami without requiring a bundle exec.
• Run hanami db rollback to easily rollback a database migration.
• Add your own methods to hanami console via your own modules: add config.console.include MyModule in your app class.
• Prefer Pry to IRB? Make it the default with config.console.engine = :pry.
• The console now prints a one-time warning when you access the keys for an un-booted app or slice. You can also chose to boot your app preemptively with hanami console --boot.
• The default Rakefile will automatically load custom tasks from lib/tasks/.
• View context classes are generated by default, so you can more easily see where to put custom view logic.
• Run hanami generate command within a slice directory and the generated file will target that slice automatically.

We’ve made dozens more small improvements and fixes. Check out the changelogs to learn more.

Try Hanami 2.3

There’s never been a better time to try Hanami. For this release we’ve made our getting started guide more concise and easier to follow. Now you can get up and running faster than ever!

Why don’t you give it a try? Your first Hanami app is just a few commands away:

$ gem install hanami
$ hanami new my_app
$ cd my_app
$ bin/hanami dev
$ open http://localhost:2300

We’d love to hear how you go! Come join our Discord or forum and share your experience with our lovely community.

And if you’re a certified legend already rocking a Hanami app, make sure to check out the upgrade notes for 2.3.

Thank you to our contributors!

Hanami 2.3 is a significant release: it comes courtesy of our biggest contributors group yet. Thank you to all these wonderful humans!

• Aaron Allen
• Adam Lassek
• Alexander Gräfe
• Alexander Zagaynov
• Andrea Fomera
• Brandon Weaver
• Damian C. Rossney
• David Celis
• Hana Rimawi
• inouire
• Jared White
• Jojo Hall
• Krzysztof Piotrowski
• Kyle Plump
• Mathew Button
• Max Mitchell
• Mina Slater
• Paweł Świątkowski
• Petrik de Heus
• Philip Arndt
• Rob Yurkowski
• Ryan Bigg
• Sean Collins
• Simon Thiboutôt
• stephannv
• Sven Schwyn
• Tim Morgan
• Tim Riley
• William Tio
• Wout
• wuarmin
• y-yagi

There’s always room for more. Our community is inclusive and welcoming, and we’d love to have you join us.

Thank you to our patrons! 🌸

This is also our first major release since launching our sponsorship program. I’d like to extend my deepest thanks to our founding patrons: Sidekiq, Brandon Weaver, Honeybadger, FastRuby.io and AppSignal. Without you, this release wouldn’t have been possible.

Thank you also to the individuals supporting Hanami through our GitHub Sponsors. There are now 21 of you!

We’d love for you to become a patron too. Learn more here.

This will be our last beta, and we’re aiming for the full 2.3 release in two weeks. Read on to see what’s new.

hanami run command

You can now can run your own scripts and code snippets with the hanami run command!

$ bundle exec hanami run my_script.rb
$ bundle exec hanami run 'Hanami.app["repos.commit_repo"].all.count'

Improved action formats config

Our previous approach to action formats config (config.formats in action classes or config.actions.formats in app or slice classes) made it too hard to configure and use your own custom formats. We’ve now overhauled this config and made it much more flexible.

This is an important change and we’d love your help with testing. If you configure formats for your actions, please pull down this beta and give this a go!

Use config.formats.register to register a new format and its media types.

This replaces config.formats.add. Unlike .add, it does not activate the format as “accepted” at the same time. This makes it easier to register your custom formats in app config or a base action class, while maintaining control over where you apply your format restrictions.

A simple registration looks like this:

config.formats.register(:json, "application/json")

.register also allows you to register one or more media types for the different stages of request processing:

• Provide accept_types: to accept requests based on specific Accept types in request headers.
• Provide content_types: to accept requests based on specific Content-Type request headers.
• Both the above are are optional. If you do not provide these, then the format’s default media type (the required second argument) is used for each.
• This default media type is also set as the default Content-Type response header when requests match that format.

Together, these allow you to register a format like this:

config.formats.register(
  :jsonapi,
  "application/vnd.api+json",
  accept_types: ["application/vnd.api+json", "application/json"],
  content_types: ["application/vnd.api+json", "application/json"],
)

Use config.formats.accept to accept specific formats from an action.

formats.accept replaces Action.format and config.format. You can access your accepted formats via formats.accepted, which replaces config.formats.values.

To accept a format:

config.formats.accept :html, :json
config.formats.accepted # => [:html, :json]

config.formats.accept :csv # Accepted formats are additive
config.formats.accepted # => [:html, :json, :csv]

The first format you give to accept will also become the default format for responses from your action, but only if you haven’t already configured a default using the approach below.

Use config.formats.default=` to set an action's default format.

This is a new capability. Assign an action’s default format using config.formats.default=.

The default format is used to set the response Content-Type header when the request does not specify a format via Accept.

config.formats.accept :html, :json

# When no default is already set, the first accepted format becomes default
config.formats.default # => :html

# But you can now configure this directly
config.formats.default = :json

Previous format config methods are deprecated.

The previous format config methods (Action.format, config.format, config.formats.add, config.formats.values, and config.formats.values=) continue to work, but are now deprecated and will be removed in Hanami 2.4.

Switching to the methods above should be straightforward, and they give you significantly more flexibility. We hope you give them a go!

Thank you to our patrons 🌸

Thank you to our Hanami patrons who made this release possible! That’s Sidekiq, Brandon Weaver, Honeybadger, FastRuby.io and AppSignal.

Thank you also to all the community members supporting Hanami through our GitHub Sponsors. There are now more than 20 of you!

We’d love for you to become a patron too. Learn more here.

Improvements & fixes

We’ve got even more improvements and fixes in this release:

• The router sees a big runtime performance boost for large numbers of routes, addressing a performance regression that was introduced as part of some fixes in Hanami 2.2.
• hanami generate action now accepts a --skip-tests flag.
• hanami generate action will add routes to slice-specific config/routes.rb files, if present.
• hanami generate commands now graceully handle names given with mixed cases.
• In new apps, the Types module now uses Dry.Types(default: :strict).
• In new apps, the generated Guardfile now passes the environment from ENV["HANAMI_ENV"].
• The view context no longer includes "settings" as a default dependency. You can include this yourself if you need it.
• Errors for missing actions in routes now show friendlier, relative file paths.

With this release, we’ve also dropped support for Ruby 3.1. Hanami 2.3 will require Ruby 3.2 or later.

We need your help!

We need your help with testing! In addition to the new action formats config, we’re still keen for feedback from people navigating the upgrade to Rack 3, which we enabled as part of beta1.

If you have a Hanami app, please try upgrading to 2.3.0.beta2, adopting Rack 3, and improving your action formats. We’d love to hear how you go!

How can I try it?

> gem install hanami --pre
> hanami new my_app
> cd my_app
> bundle exec hanami dev

What’s included?

Today we’re releasing the following:

• hanami v2.3.0.beta2
• hanami-assets v2.3.0-beta.2 (npm package)
• hanami-assets v2.3.0.beta2
• hanami-cli v2.3.0.beta2
• hanami-controller v2.3.0.beta2
• hanami-db v2.3.0.beta2
• hanami-reloader v2.3.0.beta2
• hanami-router v2.3.0.beta2
• hanami-rspec v2.3.0.beta2
• hanami-utils v2.3.0.beta2
• hanami-validations v2.3.0.beta2
• hanami-view v2.3.0.beta2
• hanami-webconsole v2.3.0.beta2

For the full list of changes, please see each package’s own CHANGELOG.

What’s next?

We have a short list of remaining fixes and improvements to make before our proper 2.3 release. See this GitHub project for details.

We expect to be back with 2.3 in a couple of weeks.

Thank you to our contributors!

Thank you to all these amazing people who contributed to this release!

• Andrea Fomera
• Brandon Weaver
• Kyle Plump
• Mina Slater
• Sean Collins
• stephannv
• Tim Riley

And thank you again for giving this beta a try! We’re looking forward to hearing your feedback. 🌸

Rack 3 support

This one goes up to eleven three.

With this release, we introduce Rack 3 support to Hanami!

We now support Rack versions 2 and 3, so you can use whichever version suits your situation. We still encourage you to upgrade Rack when you can, and we’re happy that Hanami is no longer a blocker on this path.

To upgrade your app to Rack 3, update your Hanami gems to this beta release, then bundle update rack. You should also check out the Rack 3 upgrade guide. Most changes will be handled for you by the Hanami gems, but you may need to update some of your app code if you're dealing with lower-level request/response details.

Thank you to our patrons 🌸

This is a our first release since launching our sponsorship program. I’d like to extend a very warm thank you to the patrons who made this possible: Sidekiq, Brandon Weaver, Honeybadger, FastRuby.io and AppSignal.

Thank you also to all the community members supporting Hanami through our GitHub Sponsors. There are now 20 of you!

Improvements

This beta also brings a range of nice improvements to your Hanami experience:

• Add your own methods to hanami console via own modules. Add config.console.include MyModule, AnotherModule to your app class.
• Prefer Pry to IRB? Make it the default with config.console.engine = :pry.
• When you specify 'nonce' in your content security policy, a nonce is automatically added to javascript_tag and stylesheet_tag.
• Access subdomains using Request#subdomains, and configure your default TLD length with config.actions.default_tld_length.
• Redirect to absolute URLs in route definitions: redirect '/example', to: https://example.com, code: 302
• You can now use single-character slice names.
• Run any hanami generate command inside a slice directory and the slice will automatically be used as the target for the new files.
• Run hanami db rollback to easily rollback a database migration.
• Running hanami new will now initialize a Git repository in your new app.
• Run hanami new with --skip-view to skip generating the view layer.
• The default Rakefile will automatically load custom tasks from the conventional lib/tasks/ location.
• The README.md in newly generated apps now includes some helpful instructions for next steps.

Fixes

We’ve also fixed a bunch of bugs:

• Allow access to autoloaded constants in config/routes.rb.
• Support include Deps in repo classes.
• Avoid false negatives for content type matches in actions.
• Properly show database errors arising from hanami db commands.
• Skip ENV var processing by Foreman (run via hanami dev by default) to ensure consistent ENV loading across environemnts.
• Respect app inflections when running hanami generate commands.
• Prevent generate commands from overwriting files.
• Convert special characters to underscores in route helper names.
• Include all necessary gems when running hanami new with the --head option.

We need your help!

Our Rack 3 upgrade is one of the more intricate changes we’ve made, especially considering the broad ecosystem that depends on Rack. We need your help to make sure this goes smoothly!

If you have a Hanami app, please try upgrading to 2.3.0.beta1 and Rack 3, and let us know how you go!

How can I try it?

> gem install hanami --pre
> hanami new my_app
> cd my_app
> bundle exec hanami dev

What’s included?

Today we’re releasing the following:

• hanami v2.3.0.beta1
• hanami-assets v2.3.0-beta.1 (npm package)
• hanami-assets v2.3.0.beta1
• hanami-cli v2.3.0.beta1
• hanami-controller v2.3.0.beta1
• hanami-db v2.3.0.beta1
• hanami-reloader v2.3.0.beta1
• hanami-router v2.3.0.beta1
• hanami-rspec v2.3.0.beta1
• hanami-utils v2.3.0.beta1
• hanami-validations v2.3.0.beta1
• hanami-view v2.3.0.beta1
• hanami-webconsole v2.3.0.beta1

For the full list of changes, please see each package’s own CHANGELOG.

What’s next?

We have a short list of remaining fixes and improvements to make before a proper 2.3 release. See this GitHub project for details.

I anticipate we’ll do one more beta release, followed by the final 2.3 release.

Thank you to our contributors!

Thank you to all these amazing people who contributed to this release!

• Aaron Allen
• Adam Lassek
• Alexander Zagaynov
• Andrea Fomera
• Hana Rimawi
• inouire
• Krzysztof Piotrowski
• Kyle Plump
• Max Mitchell
• Paweł Świątkowski
• Sean Collins
• stephannv
• Sven Schwyn
• Tim Morgan
• Tim Riley
• William Tio
• Wout
• wuarmin
• y-yagi

And thank you again for giving this beta a try! We’re looking forward to hearing your feedback. 🌸

We want the Hanami community to be a welcoming place for people who bring kindness, curiosity, and care. A place where people of all backgrounds and experience levels can feel respected, and can share and grow. A place for people to be proud of, and feel safe within.

It’s also why we govern our community spaces under the Contributor Covenant code of conduct. This is the gold standard for community codes of conduct, and it’s served us well for over ten years.

Today we’re delighted to adopt the new Contributor Covenant 3.0, released just last month. This new version brings a number of improvements:

Contributor Covenant 3.0 is designed to be more adaptable to different kinds of communities, both online and offline. It is written with clearer, less US-centric language, intended to be easier to understand and translate. The enforcement guidelines section has been reimagined as “Addressing and Repairing Harm,” reflecting an alignment with principles of restorative justice, including finding ways to safely reintegrate someone back into a community after an incident occurs.

We’re pleased that this new version is more approachable for our worldwide community. We also welcome the focus on restorative justice. The examples of how people can make genuine amends to grow and rejoin a community are clear and well explained.

These changes won’t affect how we interact day-to-day in our already lovely community, but do give us better tools for the rare times when conflicts need thoughtful resolution.

Thank you to the Organization for Ethical Source for their work on this new version!

You can find our instance of the Contributor Covenant on our community page.

How’d we go?

Thanks to your support, we’ve entered a whole new era for Hanami, Dry and Rom. For the first time ever, Ruby has a second framework backed by funding!

Granted, we’re at only 0.2 of a full-time role, but a start is a start! We’re here for the long haul, and going from 0 to something is one of the most important jumps we will make.

We have you—the Ruby community—to thank for this.

Thank you especially to Mike Perham and Sidekiq, Brandon Weaver, Joshua Wood and Honeybadger, Ernesto Tagwerker and FastRuby, and Roy Tomeij and AppSignal.

These are our founding patrons, and without their support, this whole thing would never have got off the ground. They’ve committed $26k towards our first year of paid maintenance.

These people are visionaries, going out of their way to support a brighter, better Ruby. Just look at how Brandon describes it:

In Ruby diversity is our greatest strength, whether that be the people, the ideas, or the technologies we use. Ruby is not just one framework, nor is it just one person, it is a community of passionate people pushing the boundaries of what’s possible not just as individuals, but as a collective. I am happy to continue to fund efforts building upon that vision of the future.

Who wouldn’t want this for Ruby? We’re doing everything we can to make this real.

We’ve also been buoyed by new support from fellow community members. We’ve been delighted to welcome 15 new community patrons via our GitHub Sponsors. These are individuals who’re putting their own money towards Hanami, and together they’re contributing $260/month. Thank you!

We’ve also established a partnership with Ruby Central as our fiscal host. Ruby Central gives us a very attractive fee structure (5% vs the 10% that Open Collective charges) and they have already handled the funds for most of our business patrons. This means more of your money goes directly to our work on tools for Rubyists.

Ruby Central went out of their way to set this up for us, and I couldn’t think of a better partner for this. We share the same vision for Ruby’s future, and I’m excited to collaborate with them for many years to come!

After all of this, how did we go? We’ve raised $29k (so far!). This is short of our initial $40k target, but fortunately, it’s still enough to support me at 1 day/week for this first year of paid maintenance.

We’re ready. Are you?

While our sponsorship drive may be coming to an end, we’re ready to bring in new supporters at any time.

Does your business already depend on our gear? (I’m sure there are a lot of you out there, with our billion gem downloads and counting across Hanami, Dry and Rom). Or do you want to step up and count yourself among the brave few willing to forge a healthier, kinder future for Ruby? If so, then come talk to us!

What’s next?

Establishing our sponsorship was one of our most important goals for 2025, and I’m very happy we’ve managed to get that done. While it did take a lot of time and brain space, we’ve still managed several other initiatives:

Upcoming release:

• Moving towards a Hanami 2.3 release. Rack 3 support will be the centrepiece here, but this will bring in a range of small improvements and fixes too.

Brand and community:

• Preparing new branding for our projects, along with a way to bring them together as a unified family. You’ve seen a preview of this already!
• Building our brand new website, which will provide a one-stop shop for everything Hanami, Dry and Rom. Guides, docs, news, community info and more.

Project maintenance:

• Catching up on housekeeping. First order of business is rolling out a tool to keep our 50+ GitHub repos in sync.
• Working on new contributor guidelines that will make it clear how you can become a maintainer, and empower our existing maintainers to take our gems to the next level.

One more thing:

• Personally, I’ve (finally!) found some time to work on my open source Hanami example app, Decaf Sucks. My current focus is adding streamlined Rodauth integration, something that feels completely “Hanami-native” and can serve as the foundation for an eventual rodauth-hanami gem.

With sponsorships in place, I can’t wait to bring you all of the above!

Exciting stuff is on the way. If you want to help out or follow along, come say hi in chat or our forum!

Let’s make sure you’re all caught up. So far, we have:

• Launched the sponsorship drive
• Heard from our founding patrons
• Shared a podcast and field report
• Met Tim and Sean
• And addressed elephant in the room, Rails

There’s a lot of words across those posts. So today I want to share something different, something visual. Behold, cuteness!

Here you have your very own preview of the new faces we’re creating for Hanami, Dry and Rom.

I’m so excited for this. These logos will unify our projects while allowing each to maintain its own identity. They’re also the visual representation of the culture we’re building, of kindness, curiosity and care — and also, delight! Ruby is fun, after all!

We’ll have more to share on this in due course, but if there’s one thing I already know, it’s that the future is looking bright (and cute!). We’d love to have you join in. 🌸

A huge thank you to Aaron Moodie for his work in bringing this to life!

Sponsorship updates

Since our last update, we’ve had a slew of community patrons join via GitHub Sponsors. Thank you for your support, Aaron Allen, Pericles Theodorou, Robert Pawlas, Nick Gorbikoff and Jared Smith!

We’d love for you to join them and become a patron. Learn more here.

We’re nearly at the end of our inaugural sponsorship drive. In my next post, I’ll come back to wrap everything up. See you then!

Thing is, I’m a fairly restrained person, and I always try to be thoughtful and positive. Sometimes I wonder what this means for my cut-through, especially when so far I’ve tried to stay focused on our gear and its benefits, rather than the elephant in the room — Ruby on Rails.

Today I’ll share my reasons again, but this time directly acknowledging Rails, and trying not to pull any punches. So, let’s imagine ourselves in the hallway track at one of those conferences, having a chat, and you ask...

Ruby has Rails. I use Rails! Why should I support you?

This is about creating a healthy future for Ruby. This is good for everyone who cares about Ruby. Rails users should care about this too.

A healthy future for Ruby is a more diverse one. Monocultures are fragile and bad for people. We want to make it so both Rails and Hanami become part of a broader range of offerings for Rubyists new and old. This will help Ruby grow, because we’ll have the tools and communities to suit a wider range of needs and wants.

For this to work, these other tools and communities can’t all remain the tiniest of tiny niches. They need to be attractive and self-sustaining. They need a certain critical mass.

This is where we are with Hanami, Dry and Rom. We’ve put ten years into constructing this ecosystem. It’s already complete and capable. We have a turnkey framework and a whole bunch of useful standalone gems. We have an active and growing community of contributors and users. With a bit of help, we can cross over this threshold and turn this into something that can really change Ruby for the better.

That’s all well and good. But how does it help me now?

We’re already helping thousands of Rails developers thanks to our Dry gems (a billion downloads and counting!). These bring structure and precision to your app’s business logic. To get a taste, check out dry-validation, dry-types/dry-struct and dry-operation.

If you’re in a Rails app and you aren’t using these tools, or if you haven’t yet played with Hanami, I think you should give them a try!

Why? Because they’ll stretch your brain in new and helpful ways. You’ll practice different patterns and see new ways of working with Ruby. The experience will make you a better developer.

Better how? You’ll see how separation of concerns and object composition form the foundation of good software practice. You’ll see the freeing benefits of working with immutable objects and clear data flows. You’ll see how apps can be clearly layered rather than blended to the point where you’re concerning yourself with database queries while writing view code.

I’m certain you’ll come out of the experience with some new ideas for improving your day-to-day Rails apps.

You might even decide you want more of this in your future, in your apps, or even as a contributor. I know this can happen, because I lived it.

I know this matters because it’s why I’m still here

I got lucky. I found Ruby very early on. And I loved it. Ruby and me, we just clicked.

But ten years ago, I began feeling disillusioned in my work writing Rails apps. I felt I’d stopped growing and learning as a software developer.

I knew I needed to try something different to break out of that rut, to expose myself to new ideas. But I also didn’t want to leave Ruby, because Ruby felt like home.

Instead, I looked around for the people doing things differently within Ruby. I tell you, it felt like a wilderness! But I did find some folks. Peter Solnica and his projects. Jeremy Evans with Roda. And of course, Luca Guidi in his early days with Hanami.

From there I started cobbling things together and building and shipping completely different kinds of apps in Ruby. And I learnt so much along the way! Actual software design things, more than just colouring in the MVC lines.

Hanami, Dry and Rom are why I’m still with Ruby today. They let me write the Ruby I want to write. The Ruby that fits the way I think. The Ruby that helps me build apps I feel confident to maintain.

Thanks to our work, it’s no longer a wilderness out there! Today if you want or need something different, you can install a gem and start playing and learning in minutes.

It all comes back to people

A big reason many of us click with Ruby is the idea of “programmer happiness” that Matz imbued into the language. Matz created Ruby for people.

But our experience with Ruby doesn’t start and end with the language itself. It’s further defined by the tools we use on top of it, and the communities we inhabit around it.

With Hanami, Dry and Rom, our goal is to provide healthy alternatives at every level. We’re here to offer more than just a new flavour of technical tools. We care even more about the community that we’re building around them.

We want this to be a welcoming place for people who bring kindness, curiosity, and care.

We want this to be a welcoming place for people who bring kindness, curiosity, and care. A place where people of all backgrounds and experience levels can feel respected, and can share and grow. A place people can feel proud of, and can feel safe within.

This means being clear on what we won't tolerate. It’s why we put “No nazis, no transphobes, no racists, no bigotry of any kind” front and centre on our website and in all our community spaces.

So if you’re a Rails dev tired of the bile coming from dear leader’s bully pulpit, now you have another place you can invest your energy, knowing it will go towards something that feels right, like the Ruby that called to you in the beginning. Perhaps it’s time you gave it a shot?

Support your future with Ruby

So if you’re currently on Rails, those are your reasons for supporting our work with Hanami, Dry and Rom: we’re helping to create a healthy thriving future for you as well as all of Ruby, Rails included.

We offer essential variety to Ruby: gems to help your Rails apps today, opportunities to learn and grow, a framework for when you want the next level, and a caring community to back it all up.

Our community has had its ups and downs, but right now we’re riding a fresh wave of energy and growth. If you love Ruby, this is where you can learn, share, and belong, now and for years to come.

When you sponsor our work, you’re not just supporting our projects, you’re investing in your own future. As you grow and your needs change, we can make sure Ruby grows with you.

What are you waiting for? Let’s do this! 🌸

That’s Sean on the left, me on the right. Now let’s get into it!

Meet Tim

Tell us a bit about yourself

I’m a software developer living in Canberra, Australia with my wife and two children.

I’ve been toying with computers since I was a kid. After years of playing newsagency-bought shareware games, teenage me found Linux (thank you APC Mag Pocketbook). After another few years, mostly spent reinstalling distros and theming Openbox, I eventually found Ruby! That was in 2002. I’ve been lucky to work with it ever since.

What’s your story with Hanami?

My path towards Hanami started 10 years ago. Back then I was helping to run Icelab, a design and development agency here in Australia. Our team would build apps for our clients in their entirety, and go on to maintain them thereafter. Our tool of choice was Rails, and it had served us well.

After shipping and maintaining dozens of Rails apps over the years, I felt like I had begun to stagnate as a developer. I was no longer growing and learning in the way I wanted to. The code I’d been writing no longer felt right for me.

I knew I needed some kind of change to break out of the rut and begin a new stage of growth. But I loved Ruby, and didn’t want to leave. So instead I looked around for people who were doing things differently with Ruby. I found Roda from Jeremy Evans. I found Peter Solnica. It was this that set me off on my journey to Hanami.

In 2015, I was part of the team that founded the Dry project. I spent the following years building production apps at Icelab composed of Dry, Rom, and Roda. This was exactly the experience I hoped for! We built great things, and I learnt so much along the way.

A few years later, the Dry and Hanami teams joined together to build the next version of Hanami. This is where I’ve focused my energy since. I drove most of the development towards 2.0, 2.1 and 2.2.

I’m very proud of the experience we’ve created with Hanami. We provide essential diversity to the Ruby community. Today, anyone who reaches that same moment of needing something different doesn’t need to feel like they’re in the wilderness, and possibly leave Ruby entirely. They now have an easy step to take: gem install hanami. Within minutes they can be playing and learning.

What are you looking forward to for the future?

I’m excited to set Hanami up for a successful second decade! We’ve spent years preparing a good foundation with version 2. Now we get to build upon it.

In the near term, this means making these goals happen: unify Hanami, Dry and Rom, help our users be more successful, and fundraise for sustainable maintenance. You’ve already seen the launch of our fundraising, and we’re already making big strides towards the others. I can’t wait to share more later this year.

Together, these efforts will help us find our critical mass, across all parts of our community: users, contributors, and financial supporters. And the more people we bring together, the more their ideas and passion can help make Hanami (and Dry and Rom) better for everyone, all while having fun and learning along the way!

Looking a little further ahead, there are a couple of other bits I’m particularly excited to drive: a first-class extensions API for Hanami, and the establishment of a clear and trustworthy governance structure for our projects.

There’s lots to do, and it’s occasionally overwhelming, but I’m happy to be here. The future is bright!

Meet Sean

Tell us a bit about yourself

I’m an independent contractor who lives in Denver, Colorado. I’ve been working with Ruby for over a dozen years. I’ve also done some purely functional programming with Elm. I’m interested in pragmatic software architecture, helping codebases stay healthy as they grow.

What’s your story with Hanami

I moved to Colorado in 2015 and the timing was auspicious: Rocky Mountain Ruby took place shortly after I arrived. On the first day, I participated in a workshop about “Component-Based Rails Applications”, which used Rails Engines to split up large codebases. This was novel to me, managing scope and thinking about your dependencies from a higher level. I tried that approach on a couple projects but it was difficult: I was constantly fighting against the framework, and few gems supported Engines because they were used so rarely.

A couple months later, at the Boulder Ruby meetup, a speaker mentioned a new Ruby web framework called “Lotus.” It supported modularity as a first-class feature. Beyond that, it broke things into more layers than Rails did, and encouraged writing small classes with limited responsibilities. This was exactly what I had been looking for! A more measured approach to writing large Ruby apps.

I started contributing to the project: first documentation fixes, then with a generator. It was later renamed to Hanami and I joined the core team for the 1.0 launch. My level of involvement has fluctuated over the years, but I've been more involved again since early last year. I'm excited and energized by the community interest increasing as we are promoting our sponsorship drive!

What are you looking forward to for the future?

I'm excited about the potential that AI-assisted development holds for Hanami. I know this is controversial but I really think AI can help speed up Hanami’s adoption and reduce much of the friction users have faced in the past.

In particular, AI can help us address some of the framework’s current challenges, while also amplifying its architectural strengths.

Challenges, mitigated by AI:

• Smaller knowledge base. There’s less information available on the web about Hanami than Rails: complete apps, blog posts, Stack Overflow questions, and more. This means there’s less training data available for LLMs to be aware of Hanami. However, Hanami’s simple APIs and more modular architecture means documentation and source code can be brought into the LLMs context window. That means you can ask questions and get tailored answers that apply to your specific project. That said, hallucinations are still a real concern, so AI isn’t a substitute for understanding the framework yourself. At best, it’s an accelerant and can help you find the documentation you need.
• Fewer third-party gems. Hanami has a smaller ecosystem of ready-made gems compared to Rails. Over the years, I’ve heard this as a sticking point for why people have trouble succeeding with Hanami. Now in the age of AI, many people are generating the code they used to pull in as a dependency, in the style that matches the rest of their codebase. You can generate bespoke code that you can bring into your codebase (after you review it!!) instead of adding a dependency.
• More boilerplate. Hanami encourages writing classes that are small, with a tight scope of responsibility. This means Hanami projects have more files and more code, requiring switching between files more. When you’re the one typing everything out, this can be annoying. When AI is writing and modifying the code, this is less of an issue.

Advantages in the AI era:

• Functional, immutable style. Hanami enables and encourages a more functional and immutable style of writing Ruby. Instead of internal state determining behavior, code’s flow can often be inferred lexically, which makes it easier for LLMs (and humans) to reason about.
• Modularity with Slices. The framework’s architectural boundaries (via Slices) reduce cross-cutting concerns, making it easier for different humans and AI agents to work in parallel without unintended side effects. Agents can be made to ignore everything but the Slice they’re working on (and its dependencies), to keep them focused on the code that matters.
• Explicitness and structure. Hanami leans towards being explicit, instead of adding a lot of implicit ‘magic’ behind-the-scenes. This is similar to Python and Django, which LLMs tend to perform well with. That explicitness pays dividends in both AI-generated and human-reviewed code. It also has a cost, with more lines of code, but when those lines are written by the computer, they’re less costly to write (though still need to be reviewed carefully).
• Scalability of complexity. As individual developers become more productive with AI, the ability to manage complexity becomes more important. If developers start reliably writing 10 times more code, then codebases will naturally grow much faster. Hanami’s modularity and built-in tools for architecting large codebases will be invaluable in those situations.

Looking ahead, I also see opportunities where we can leverage AI to help us audit, fix, and maintain our documentation. This could free us up to work on other activities, and increase the quality of our documentation.

To be clear: we’re not at the point where AI agents can write Hanami apps as well as they can write Rails apps. Rails has been more exposed to the world, so LLMs have “seen” it more. But I believe we can close that gap to make Hanami a fully viable alternative to Rails. Beyond that, I can imagine a future where Hanami’s modularity, explicitness, and functional/immutable style help it become the preferred framework for writing Ruby apps.

Sponsorship updates

(What is all of this? Read our sponsorhip site to learn more.)

Since week 3, we’ve had one new person become a community patron and support our work on Hanami, Dry and Rom. Thank you very much, Mathew Button!

Bit by bit, we get closer. If you’re a human being who cares about a diverse, thriving Ruby, we’d love for you to join Matthew and all our community patrons. And if you’re a collection of human beings in a business, we’d love to hear from you too!

As of this week, we’re still sitting at $27.5k:

🟩 🟩 🟩 🟩 ⬜ ⬜ ⬜ ⬜ ⬜ ⬜
$27.5k of $70k — 39% to our goal…

Next week, I think it’s time I address the 800-pound elephant in the room. I’ll see you then.