RobCo becomes a unicorn: where Bun fits in robotics

RobCo, a German startup from Munich, just became a unicorn. According to Tech Funding News, the company is now worth $1 billion. It sells modular industrial robots to small and mid-sized factories. That's the kind of customer that never had the money or the team for a traditional automation project. You might be wondering what this has to do with Bun. More than it seems. The robotic arm is the part that shows up in the photo, but what pays the bills is the software around it. And a lot of that software is exactly the kind of thing I'd write in TypeScript tomorrow morning.

What RobCo does, without the hype

The idea is easy to explain. RobCo doesn't sell a closed, expensive robot custom built by an integrator. It ships modules: joints, links, grippers. You assemble the setup your line needs. Programming happens through a visual interface, so you don't need a robotics engineer on the payroll.

The business model helps too. The company bets on robots as a service, with recurring payments instead of one huge upfront investment. For a factory with 40 employees, that changes everything. It stops buying a machine and starts subscribing to a capability.

And here's the detail that matters to developers. A subscription needs telemetry. If you charge monthly, you need to know if the robot is on, how many cycles it ran, when it's going to fail. That doesn't run on the arm. It runs on a backend.

Why a robotics unicorn matters to web devs

Investor money in hardware tends to turn into software hiring. Every modular robot company eventually becomes a platform company. It needs:

• a web dashboard so customers can track their fleet;
• an API to integrate with ERP and production systems;
• real-time ingestion of sensor data;
• remote configuration and firmware updates.

None of these is motor control. They're problems you've already solved in a regular SaaS. The difference is a customer sitting in a factory with bad Wi-Fi and dust on the router.

The robot moves in C++. The business moves in JSON.

Here's my strong opinion of the day. The real-time control layer is still C++, Rust and ROS territory, and it should stay that way. Nobody serious is going to close a servo motor control loop with a garbage collector. But the layer on top, the one that talks to people and other systems, is wide open for JavaScript runtimes. That's where Bun gets interesting.

Where Bun fits in real robotics

The meeting point between factory and cloud is usually a gateway. It's a small computer, often ARM, sitting near the machines. It collects data, stores it when the internet drops and sends it when the connection comes back. It's boring and important work.

Bun solves three pains of this setup at once.

A single binary. Installing Node, npm and node_modules on an industrial gateway is asking for trouble. With Bun you compile everything into one executable:

bun build ./gateway.ts --compile --target=bun-linux-arm64 --outfile gateway

You copy one file to the machine and run it. No package manager in the factory, no "works on my machine".

Embedded SQLite. bun:sqlite ships with the runtime. For a local buffer of readings, it's exactly what you need, with no native dependency to compile on ARM.

Native WebSocket. Bun.serve accepts WebSocket directly, no extra library. To receive data from several production cells at once, that's enough.

A telemetry gateway in a few lines

Here's a minimal example. The cells send readings over WebSocket, the gateway writes everything to local SQLite and a separate loop sends it to the cloud.

import { Database } from "bun:sqlite";

const db = new Database("buffer.db");
db.run("PRAGMA journal_mode = WAL;");
db.run(`CREATE TABLE IF NOT EXISTS readings (
  id INTEGER PRIMARY KEY,
  robot TEXT NOT NULL,
  payload TEXT NOT NULL,
  ts INTEGER NOT NULL
)`);

const insert = db.prepare(
  "INSERT INTO readings (robot, payload, ts) VALUES (?, ?, ?)"
);

Bun.serve({
  port: 8080,
  fetch(req, server) {
    if (server.upgrade(req)) return;
    return new Response("gateway ok");
  },
  websocket: {
    message(ws, msg) {
      const { robot, data } = JSON.parse(String(msg));
      insert.run(robot, JSON.stringify(data), Date.now());
    },
  },
});

And the sender, which only deletes what the cloud confirmed:

const pending = db.prepare(
  "SELECT id, robot, payload, ts FROM readings ORDER BY id LIMIT 500"
);
const deleteUpTo = db.prepare("DELETE FROM readings WHERE id <= ?");

setInterval(async () => {
  const batch = pending.all() as { id: number }[];
  if (batch.length === 0) return;

  const res = await fetch("https://api.example.com/telemetry", {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify(batch),
  }).catch(() => null);

  if (res?.ok) deleteUpTo.run(batch.at(-1)!.id);
}, 5_000);

Notice the golden rule: data only leaves the disk after the 200. If the factory internet drops for three hours, the readings wait in SQLite. When the connection comes back, the loop drains the queue in batches of 500. No Kafka, no broker, no cluster. For a gateway with a dozen robots, this holds up just fine.

Of course this isn't production-ready code. It's missing WebSocket authentication, payload validation and a size limit so the database doesn't fill the SD card. But that's the structure, and it fits on one screen.

The limits you need to respect

It would be dishonest to sell Bun as the answer to everything in robotics. It isn't.

First, real time. A runtime with a GC can pause for a few milliseconds at a bad moment. For telemetry, that doesn't matter. For stopping an arm before it hits a person, it matters a lot. Functional safety belongs in the controller, with certified hardware. Your TypeScript should never be in that path.

Second, industrial protocols. The factory floor speaks OPC UA, Modbus, and sometimes proprietary stuff from the 90s. The JavaScript ecosystem has libraries for this, but maturity varies. Before you pick the runtime, check if your customer's protocol has a decent client. Sometimes the right answer is a small process in another language acting as a bridge, with Bun handling the rest.

Third, Node compatibility. It has improved a lot, but packages that rely on old native addons can still cause headaches on ARM. Test on the real hardware, not just your laptop. The factory gateway doesn't share your MacBook's mood.

What changes in your day to day

If you work with TypeScript backends, the RobCo news is a market reminder. Robotics is no longer a niche for mechatronics engineers. Companies like this one need people who can build APIs, queues, dashboards, authentication and reliable deploys. It's your usual job, just with a customer who measures success in parts per hour.

In practice, three things are worth your time:

1. Learn to think offline first. Factories lose internet all the time, and your code needs to treat that as a normal case, not an exception.
2. Master bun build --compile and cross-compilation. Shipping a single binary is a superpower in an environment you don't control.
3. Learn the basics of OPC UA or MQTT. You don't need to become an expert, but you need to be able to read the equipment docs.

My final take: the $1 billion isn't in the arm's aluminum. It's in the promise that a small factory can automate without hiring an expensive integrator. That promise only holds with software that's simple, robust and easy to install. Bun doesn't make robots move, but it gets everything else into the factory with less friction. If you want to see how I apply this same single-binary, lean-backend approach in real projects, take a look at my projects.

RobCo just became a unicorn. And the robotic arm isn't what caught my eye.

What pays the bills is the software around it: telemetry, dashboard, API, remote updates.

The robot moves in C++. The business moves in JSON.

Real-time control stays with C++ and Rust, and it should stay that way. But the gateway sitting in the factory fits in a single Bun binary, with embedded SQLite and native WebSocket.

The rule is simple: data only leaves the disk after the cloud confirms it. The factory internet can drop for three hours and not a single reading is lost.

Robotics is no longer a mechatronics niche. It needs people who know how to build APIs, queues and reliable deploys.

I wrote a step by step guide with code on the blog. If you work with TypeScript backends, it's worth a read.

#Bun #TypeScript #Robotics #IoT #Backend