RubyMine Remote Development: Running the IDE Locally While Code Executes on a Server

The problem: local IDE, remote reality

You write Rails code on a MacBook Air, but the application runs on an Ubuntu VM in your cloud account. The gem cache, native extensions, and rails console all live there. Opening the project over SFTP is slow; editing over SSH with Vim loses code navigation, refactoring, and the debugger. RubyMine's Remote Development (since 2023.1) solves this by keeping the front-end on your laptop while a headless backend runs on the target host, connected through a TLS tunnel managed by JetBrains Gateway.

How the architecture fits together

When you register a remote interpreter (SSH, Docker, or WSL 2), RubyMine launches a backend process on that host. The backend indexes the project, runs Bundler, and hosts the debug server (ruby-debug-ide + debase). Your local IDE streams UI events and receives completion data over the tunnel. File changes sync via rsync (default 1.5 s debounce), and the Terminal toolwindow opens a shell inside the same environment so rake and custom scripts see identical PATH and gemset.

Worked example: SSH interpreter with debugging

Assume a Rails 7.1 app on a host app.example.com with Ruby 3.2 installed via rbenv. You want breakpoints in app/controllers/application_controller.rb to hit when you curl the staging endpoint.

1. In RubyMine 2024.2+, open Settings → Languages & Frameworks → Ruby SDK and Gems, click + → New Remote → SSH.
2. Enter [contact removed], select key-based auth, and test the connection. RubyMine will prompt for the remote Ruby path (e.g., ~/.rbenv/versions/3.2.2/bin/ruby).
3. After the SDK is added, create a run configuration: Run → Edit Configurations → + → Rails. Name it "Staging Server". Set the server to puma, port 3000, and Path Mappings to map your local project root to /home/user/myapp on the remote host.
4. Place a breakpoint in ApplicationController#index. Start Debug → Staging Server. The backend starts ruby-debug-ide inside the tunnel; the Variables panel shows @current_user and params when the request arrives.
5. Open Tools → Terminal → New Session. Run bundle info rails and verify the path points to /home/user/.gem/ruby/3.2.0/gems/rails-7.1.0 — confirming the remote gem cache is active.

Trade-offs and limitations

• Licensing: Remote Development requires a paid RubyMine license; the Community Edition cannot attach remote interpreters.
• rsync dependency: The remote host must have rsync installed (apt-get install rsync or apk add rsync). Windows SSH targets need cwRsync or WSL rsync in PATH.
• Path-mapping case sensitivity: Linux remotes are case-sensitive; macOS/Windows hosts are not. A mismatch (e.g., App/Controllers vs app/controllers) causes breakpoint misses and "Cannot find file" navigation errors.
• Heap pressure on large monorepos: Projects over ~200 kLOC may exceed the default 2 GB backend heap. Increase -Xmx via Help → Change Memory Settings for the remote backend process.
• Native-extension platform mismatch: An M-series Mac developing against an x86_64 Linux container will fail to compile gems like nokogiri or pg unless you run bundle lock --add-platform x86_64-linux on the remote host.
• Firewall/VPN ephemeral ports: Gateway allocates a random TCP port for the tunnel. Corporate VPNs often block these; you may need a dedicated bastion or SSH jump host with port forwarding allowed.

Verification checklist

After setup, confirm the loop works end-to-end:

• Indexing: Initial remote index on a 50 kLOC Rails app takes 90–180 s on a 4 vCPU instance; subsequent saves are sub-second.
• Live edit: Modify a view file locally; watch the rsync progress balloon (bottom-right) and verify the browser reload (via rails server -b 0.0.0.0) reflects the change within 2 s.
• Team portability: Commit .idea/runConfigurations/Development.xml. On a second machine, clone the repo, open in RubyMine, and the run configuration appears with a dropdown to select a different remote interpreter (staging VM, local Docker, WSL) without editing XML.
• Backend version match: Check Help → About — the backend version must match the local RubyMine build number. A mismatch indicates a stale Gateway cache; fix with File → Invalidate Caches → Restart.

Closing: pick the target that matches your workflow

If your team standardizes on Docker, use a Docker-based interpreter — the backend attaches via docker exec and the same Dockerfile defines the toolchain. If you're on Windows, WSL 2 gives you a Linux toolchain without a VM. For ad-hoc cloud VMs, SSH is the lowest-friction path. In each case the local IDE stays responsive while the heavy lifting happens where the code actually runs.