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

Question

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?

Siddharth · Answer

Answer to the question
Switching the bundle path to a volume does not require recreating the remote SDK; a re‑sync of the existing SDK is enough.
Why re‑sync is sufficient

The remote SDK stores only the interpreter path and the list of gems it sees inside the container.
Mounting vendor/bundle (or whatever BUNDLE_PATH you use) changes the gem environment that the interpreter sees, but the interpreter binary itself stays the same.
When you re‑sync, RubyMine re‑reads the gem list from the interpreter and updates the External Libraries view.

Potential pitfalls when gems live on a mounted volume

On macOS or Windows the Docker volume introduces a file‑system translation layer; frequent bundle install runs can make container start‑up and debugger attachment noticeably slower.
RubyMine does not automatically re‑index gems after a bundle install on the volume – you must trigger a manual re‑index (see the steps below).
If the Ruby interpreter path inside the container changes (e.g., you switch to a different Ruby version image), you must point the remote SDK to the new interpreter before re‑syncing.
File‑permissions mismatches between host and container can cause bundle install to fail or produce incomplete gem sets, which will then be invisible to RubyMine.

Recommended workflow after changing the bundle path

Update docker‑compose.yml to mount the desired bundle directory:
services:
  web:
    volumes:
      - .:/app
      - ./vendor/bundle:/app/vendor/bundle   # new mount

Restart only the affected service (e.g., docker compose restart web). No full image rebuild is necessary.
Re‑sync the remote SDK in RubyMine: open Settings/Preferences | Languages & Frameworks | Ruby SDK and Gems, select the SDK, click Re‑sync.
Force a re‑index of gems if the External Libraries view still shows the old list:

Right‑click the SDK in the Ruby SDK and Gems dialog and choose Show Gems List to view the current gem names.
Alternatively, use the Reindex Gems action in the same dialog.

Verify the gem list matches the container:

Inside the container run docker compose exec web bundle list and compare the output to RubyMine’s gem list.
Or run ruby -e "puts Gem::Specification.map(&:name).sort" inside the container and diff the sorted list against the gem names shown in RubyMine.

Run a quick debug session to confirm the debugger attaches correctly. The ruby-debug-ide or debug gem must still be present in the mounted bundle.

What to ask for a more tailored recommendation
Could you tell me which host OS you are using (macOS, Windows, or Linux)?  Performance and file‑watching behaviour differ significantly across these platforms, and that may influence the best mounting strategy.

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

1 answer

Answer to the question

Why re‑sync is sufficient

Potential pitfalls when gems live on a mounted volume

Recommended workflow after changing the bundle path

What to ask for a more tailored recommendation

Your perspective belongs here.

0 question comments