Remote access for
the machines you ship.

What you probably have today

Rarely nothing. Usually a patchwork that kind of works:

• A VPN or a jump host every engineer has to be set up on — and a second identity system nobody wants to explain to a customer's IT department.
• A remote-desktop tool the end customer has to install and approve, that knows nothing about your machine.
• A camera stream someone wired to the dashboard one sprint, that falls over on LTE.
• scp through two hops to get one log out.
• Or "proper remote access", on the backlog for a year.

Each piece works on a good day. Together they're slow to support, hard to secure, and a different login every time. Fjarr replaces the patchwork with one connection per machine that carries all of it.

We've built this stack three times before, inside robot companies — what we kept and what we didn't.

Three pieces, your stack

Fjarr embeds into what you already run. Your backend stays in charge of who may reach what; video and data go straight between the machine and the person looking at it.

// any JWT library, any language
const grant = jwt.sign({
  aud: "fjarr",
  tenant: "acme",
  robot_id: "robot-024",
  operator: { id: user.email, label: user.name },
  capabilities: [
    { name: "fjarr.camera" },
    { name: "fjarr.desktop" },
  ],
}, GRANT_KEY, { algorithm: "HS256", expiresIn: "5m" });

import {
  createFjarrClient, FjarrProvider, DesktopView,
} from "@fjarr/react";

const client = createFjarrClient({
  serverUrl: "wss://fjarr.acme.example",
  grant: (id) => myApi.fjarrGrant(id), // your grant endpoint
});

<FjarrProvider client={client}>
  <DesktopView
    session={client.sessions.open("robot-024")} />
</FjarrProvider>

The contract between the pieces: interfaces · architecture

Capabilities — everything is a plugin, including yours

available: in a release · in development: running on main · planned: on the roadmap. We don't market what doesn't run.

Measured, not promised

Every number below was measured on named hardware at a milestone gate, against a written budget. Click one for where and when.

The machine's desktop — and control that's safe for one that moves

The desktop your machine already has, in your dashboard — no tool for the end customer to install. in development

• Unattended: back after a reboot with nobody at the machine
• Every monitor, plugged in or out while you watch
• Virtual screens for machines with no monitor attached
• The clipboard both ways
• Typing through the machine's own keyboard layout
• Its own cursor, drawn where it really is

Who's in control is explicit

Each of these ships with a regression test (safety behaviors). How control works: security · remote desktop.

A link to one machine — not a VPN

Every team keeps a list of things it occasionally needs to do on a machine that nobody will ever write a protocol for. The network link is the escape hatch: an authorized operator gets a routable address for one machine, inside the session that already carries its video — and the tools they already use just work.

$ fjarr-connect login                 # your company's sign-in, in the browser
$ fjarr-connect robot-024
robot-024  100.70.118.224  mtu 1184  up in 0.8 s

cannelloni -I vcan0 -R <machine> -r 20000 -l 20000
candump vcan0

(gdb) target remote <machine>:2345

ros2 topic list
rviz2

DOCKER_HOST=ssh://user@<machine> \
  docker logs -f my-node

And ssh, scp, RDP, your file manager, Wireshark, a serial port, Modbus — more ideas.

It deliberately isn't a mesh: no shared network, no machine-to-machine routing, no always-on reachability. It's developer and support access — the design says exactly where that line sits.

Safe to put on a customer's network

Light on the machine

The whole threat model is public: security. Encoders and hardware: supported platforms.

Built for the people who debug machines

Open core, honest split

The whole business plan is a public document: product strategy.