Node.js Example - Remote Debugging with Your Local IDE
Remote development lets you code against a cloud environment. Remote debugging takes it a step further — you can set breakpoints, step through execution, and inspect variables in code that is running inside a Bunnyshell container, all from the comfort of your local VS Code. Watch the video above for the full setup and a live debugging demonstration.
Configuring VS Code for Remote Debugging
The Node.js runtime has a built-in inspector protocol that allows external debuggers to attach to a running process. When you start Node.js with the --inspect flag (for example, node --inspect=0.0.0.0:9229 server.js), it opens a WebSocket server on port 9229 that debugger clients can connect to. The key to remote debugging is making that port accessible from your local machine.
In Bunnyshell, this means two things: first, your Node.js application must start with the --inspect flag, and second, port 9229 must be forwarded from the remote container to your local machine. During a remote development session, you can configure the startup command to include the inspect flag. Bunnyshell's port forwarding handles the rest, creating a secure tunnel between your machine and the container.
On the VS Code side, you need a launch configuration that tells the debugger where to connect. Create or update your .vscode/launch.json file with an "attach" configuration pointing to localhost on the forwarded port. A minimal configuration looks like this: set the type to node, the request to attach, the port to 9229, and enable localRoot and remoteRoot mappings so VS Code can match your local files to the files inside the container. The localRoot is your project directory, and the remoteRoot is the working directory inside the container (typically /app or wherever your code is mounted).
Setting Breakpoints and Inspecting State
Once the debugger is attached, you interact with it exactly as you would when debugging a local application. Click in the gutter next to any line of code in VS Code to set a breakpoint. When the cloud-running application hits that line — say, when a request comes in to your API endpoint — execution pauses, and VS Code highlights the current line.
From here, you have the full debugging toolkit at your disposal. The Variables panel shows the current values of local and global variables. The Call Stack panel shows the chain of function calls that led to the current point. The Watch panel lets you track specific expressions. You can hover over any variable in the code to see its value, and the Debug Console lets you evaluate arbitrary JavaScript expressions in the context of the paused execution.
Stepping controls let you move through the code line by line. Step Over executes the current line and moves to the next. Step Into follows function calls into their implementations. Step Out finishes the current function and returns to the caller. Continue resumes execution until the next breakpoint is hit.
This is particularly valuable for debugging issues that only appear in the cloud environment — problems caused by specific database state, interactions between services, or environment-specific configuration. Instead of adding console.log statements, redeploying, and reading logs, you can pause execution at the exact point where something goes wrong and inspect the full application state.
The End-to-End Debugging Workflow
Putting it all together, the remote debugging workflow looks like this: start a remote development session with the Bunnyshell CLI, which syncs your local code and configures the container for development mode. Ensure your startup command includes the --inspect flag. Use Bunnyshell port forwarding to expose port 9229 locally. Open VS Code, launch the attach configuration, and confirm the debugger connects successfully.
Now, trigger the behavior you want to debug — visit a page in the browser, call an API endpoint, or run a script. When execution hits your breakpoint, VS Code pauses and gives you full visibility into the running state. Inspect variables, step through the logic, identify the issue, fix it in your local editor, and the file sync pushes the change to the container. The application reloads with your fix, and you can verify immediately.
This tight loop — edit locally, run in the cloud, debug interactively — combines the best of local development speed with the accuracy of a production-like environment. You never need to wonder whether a bug will reproduce in staging, because you are already debugging in a real cloud environment with real services and real data.
For teams working on complex Node.js applications with multiple services and dependencies, remote debugging eliminates an entire category of slow, frustrating troubleshooting. No more log-based debugging. No more guessing. Set a breakpoint and see exactly what is happening.
Ship faster starting today.
14-day full-feature trial. No credit card required. Pay-as-you-go from $0.007/min per environment.
Frequently Asked Questions
Can I set breakpoints in code that is running in the cloud?
Yes. With remote debugging, your local IDE connects to the Node.js debug protocol running inside the Bunnyshell container. Breakpoints you set in your local VS Code are hit when the cloud-running application reaches that line of code. You can inspect variables, step through execution, and evaluate expressions exactly as you would with a locally running process.
What port does the Node.js debugger use and how do I forward it?
Node.js uses port 9229 by default for the inspector protocol. Bunnyshell port forwarding maps this remote port to a local port on your machine. Once forwarded, VS Code connects to localhost:9229 (or your configured port) to attach the debugger. The Bunnyshell CLI handles the secure tunnel automatically.
Does remote debugging work with IDEs other than VS Code?
Yes. Any IDE that supports the Node.js V8 Inspector Protocol can connect to the forwarded debug port. WebStorm, IntelliJ IDEA, and Chrome DevTools all support this protocol. The setup differs slightly per tool, but the underlying mechanism — connecting to a debug port via port forwarding — is the same.