Switching a RubyMine Docker Compose remote SDK from baked-in gems to a mounted bundle path

We run a small Rails app in RubyMine using a remote Ruby SDK backed by Docker Compose, so run, debug, and test configurations execute inside the container while editing stays local. This works, but every gem change currently means rebuilding the image before the SDK's gem list re-syncs and code insight catches up.

We are considering moving the bundle path out of the image and onto a mounted volume so bundle install inside the container takes effect without a rebuild. The trade-offs are unclear: rebuild frequency versus container startup behavior, plus the documented file-watching and performance concerns for volume mounts on macOS and Windows hosts. We also need the debugger to keep attaching reliably after the change, and we are unsure whether RubyMine re-indexes gems automatically when the mounted bundle path changes or whether the remote SDK must be manually re-synced each time.

Assuming a current RubyMine release with Docker Compose V2: does switching the bundle path to a volume require recreating the remote SDK, or is re-syncing sufficient? Are there known indexing or debugging pitfalls when gems live on a mounted volume rather than in the image? Is there a recommended way to verify the gem list matches the container after the transition?