It’s 2026. Your humanoid robot just failed a navigation test in the warehouse.
The Perception Engineer runs the simulation locally on their $4,000 laptop. They spin up Gazebo. They launch RViz. They see the LiDAR point cloud glitch.
“Aha!” they say. “The obstacle avoidance kicked in early.”
They record a 15-second screen capture (MP4). They post it in Slack.
“Hey @product-manager, look at this glitch.”
The Product Manager squints at the pixelated video on their phone. “Can you zoom in on the left leg?”
“No,” says the engineer. “That’s just a video. I’d have to re-run the sim.”
This is the “MP4 Loop.” And it is killing your velocity.
The Localhost Trap
We treat robotics software differently than web software. We accept that “Simulation” is a heavy, local process. We accept that to see the robot, you need the robot’s entire brain installed on your machine.
This is madness.
Imagine if a Frontend Engineer sent a video of a button click to a designer. “Can I click it myself?” asks the designer. “No,” says the engineer. “You don’t have Node.js v22 installed.”
We solved this in web development 10 years ago with Preview Deployments (Vercel, Netlify). You push code. You get a URL. Everyone sees the same thing.
The Pivot: Simulation as a URL
In 2026, a simulation is not a process running on your laptop. A simulation is a URL.
If you cannot link to it, it doesn’t exist.
Your robotics pipeline should look like this:
- Push Code: You modify the path planner.
- Build Container: The CI builds a Docker container with your ROS workspace.
- Spin Up: The cloud (PrevHQ) spins up the ROS nodes and a Foxglove Bridge.
- Visualize: You get a link:
prevhq.com/sim/pr-402.
You paste that link in Slack. The Product Manager clicks it. They don’t install ROS. They don’t install Ubuntu. They see the robot in 3D in their browser. They rotate the camera. They inspect the topic data.
Why Foxglove + PrevHQ?
The open-source project Foxglove (formerly Webviz) changed the game. It moved the visualization layer from a local binary (RViz) to the browser (WebSocket + WebGL).
But Foxglove is just the viewer. You still need to run the heavy ROS backend.
This is where PrevHQ comes in. We provide the ephemeral compute. We spin up the “Backend for Frontend” (BFF) pattern for your robot.
- The Backend: Your ROS nodes + Foxglove Bridge (websocket).
- The Frontend: A pre-configured Foxglove layout served via HTTPS.
Kill the MP4
Stop shipping videos. Start shipping interactive experiences.
When a simulation fails in CI, don’t just fail the build. Generate a link to the failure. Let the engineer click the link and see the exact state of the world at the moment of the crash.
This is how you scale a fleet of 10,000 robots. Not by buying more laptops, but by moving the “World” to the cloud.
FAQ: Robotics Simulation in the Browser
Q: Can I really replace RViz with a browser link?
A: Yes. Modern WebGL is powerful enough to render millions of LiDAR points at 60fps. Foxglove is the industry standard for this. You lose almost nothing in fidelity, but you gain 10x in collaboration.
Q: Does this work for Gazebo / Physics?
A: It depends. PrevHQ runs the ROS nodes (control, planning, perception). The physics engine (Gazebo/Ignition) can also run in the container (headless), bridging the visual data to the browser. For heavy physics, you might need GPU instances, but for “Playback” and “Debugging Logic,” CPU is often enough.
Q: How do I secure my proprietary robot data?
A: Ephemerality is security. The preview environment exists only for the duration of the PR review. Once merged (or closed), the environment evaporates. The data doesn’t sit on a shared staging server waiting to be leaked. It lives for 30 minutes and then vanishes.
Q: What if I have massive bag files (100GB+)?
A: Stream, don’t download. Instead of downloading the bag file to your laptop to play it, you upload it to the cloud once. The PrevHQ instance mounts the bag and streams the relevant topics to the browser on-demand. You save hours of download time.