# Preparations for Rails 7.1 **URL:** \ **Category:** General\ **Tags:** rails\ **Created:** [December 21, 2022, 1:05am UTC](https://community.fly.io/t/preparations-for-rails-7-1/9512 "2022-12-21T01:05:17Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![rubys](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/rubys/32/16907_2.png) [@rubys](https://community.fly.io/u/rubys)\ **Post date:** [December 21, 2022, 4:00pm UTC](https://community.fly.io/t/preparations-for-rails-7-1/9512/8 "2022-12-21T16:00:16Z")
> [@DHH](#): > > then there’s no price to pay in the final image? I’ll run some tests, but I believe that you will need the postgresql and mysql client at runtime (but not sqlite3 which is truly just a library); but I don’t think that this anything to worry about. There is a huge difference between “everything a Debian user might need”, and “things commonly used by Rails applications”. And as you say, users CAN edit to strip things they don’t need. I’m quite OK with not including node for importmap applications, but there be dragons here. I went back and checked, and an example where a rails 7 importmaps user had a problem was one where boostrap requires autoprefixer-rails which requires execjs which requires nodejs - even though nodejs is not used at runtime. See: [Rails app `fly deploy` failing with ExecJS::RuntimeUnavailable: Could not find a JavaScript runtime](https://community.fly.io/t/rails-app-fly-deploy-failing-with-execjs-could-not-find-a-javascript-runtime/7904) > [@DHH](#): > > Please cc me on any/all PRs to bring some of these improvements to the new stock Dockerfile Will do. I’m going to take a day or two to plan how to approach this, and then likely produce a steady stream of smaller pull requests. That way I can get feedback and make mid-course corrections without getting deep into the weeds making a change that Rails won’t accept. --- _[View the full topic](https://community.fly.io/t/preparations-for-rails-7-1/9512)._