Turn a Jetson, Raspberry Pi, or local server into a browser-based control station. Add live video, controls, and telemetry without building a frontend.
Start with a camera, joystick, buttons, and battery state. Add only what your operator needs from 42 reusable widgets across six categories.
Drive, switch and adjust hardware with controls designed for repeated operator use. Fourteen of them, each able to read state as well as write it.
A joystick and a video player are easy to prototype. A control station that reconnects, keeps state in sync, survives long sessions, secures access, and works across devices is a separate software project.
Flintbay packages that reusable layer. You build the machine and its logic; Flintbay handles the browser control surface.
Keep the control path close to the machine.
Telemetry stays on infrastructure you control.
Your local control station does not need the internet.
Run Flintbay on a Jetson, Raspberry Pi, laptop, or server. Connect ROS2, MQTT, REST, or WebSocket, then arrange live video, controls, and telemetry without writing frontend code.
Describe where the data lives, drop the widgets an operator needs, and wire the ports. The dashboard stays live the whole time — there is nothing to compile and nothing to deploy.
A host, a port, and what it speaks. REST, MQTT, ROS 2, WebSocket or a media stream — the form knows what each one needs and says so inline.
Forty-two widgets across six categories, each previewed in the palette. The page underneath keeps running while you build on top of it.
Every widget exposes typed ports. Point one at a path in the payload and it is bound — Connection Studio shows which are fed and which are still waiting.
Each step is also an MCP tool, so an assistant can do the same work from a description of the machine.
Start with a robot cockpit. Reuse the same control surface for a test bench, lab, or any local device with an API.
Put live video, a joystick, drive controls, battery, and connection state in one browser view.
Build a reusable panel for actuators, sensors, cameras, and setpoints instead of another throwaway UI.
Give a TurtleBot, rover, or Jetson project a control station that opens on a laptop, tablet, or phone.
The same widgets can control lighting, irrigation, home-built automation, or anything exposed through an API.
Compose the operator view around the machine: interactive controls, live media, current state, history, and structured data on the same page.
Connect MQTT, REST, WebSocket, and ROS2 through declarative bindings. Keep the layout while the transport or payload evolves.
Authentication, workspace roles, account management, audit and system logs, reconnect behavior, command modes, and state synchronization are part of the platform—not a new backlog for every robot.
Connect a supported AI client and create sources, endpoints, widgets, and bindings through structured tools instead of editing generated frontend code.
Every screen below was built in Flintbay and photographed running. Nothing is a mockup, and nothing is relabelled — each one reads its own simulated site, so a chiller says degrees and a spindle says percent of load.
Eight robots on one floor: live position on the plan, who is charging, and which aisle is taking the throughput. The map background is an image the endpoint supplies, so a new site is a new file.
A control station is more than widgets. Accounts, roles, keys for automation, an audit trail and the logs that answer “why is this source quiet” are in the box. Each panel below is a photograph of the running product, not a feature list.
The same account can run the warehouse floor and only watch the test bench. Four roles ship with the platform — admin, editor, operator, viewer — and the owner of a workspace changes them from this panel without an administrator in the loop.
Get an account on the live instance with a workspace of your own. Demo setup attempts to add live Sources and Endpoints from one simulated rover—including telemetry, video, and audio. Provisioning is best-effort, so the activation screen reports what was actually added. Then add widgets and connect them in Connection Studio before installing anything. Email, a password, one activation link.
A public instance that may be reset without notice. Treat anything you build there as temporary, and don't reuse a real password.
Flintbay ships as one Docker image with the web app, API, PostgreSQL, and Redis. Run it on the robot's Jetson, a Raspberry Pi, a laptop, or a nearby server so the interface is ready whenever the hardware is.
AMD64 and ARM64 images cover servers, laptops, Jetson, and Raspberry Pi.
Saved layouts and configuration survive container restarts and image updates.
Control traffic and telemetry can stay on the same network as the hardware.
Authentication, sessions, workspace roles, rate limits, and audit logs are already part of the stack.
0.1.9 is the current release. :latest tracks the newest stable one; pin a version like this in production so an upgrade is something you choose.
Every release is one image covering AMD64 and ARM64. Its index digest is what cosign signs, so the digest — not a tag — is what identifies a build. A running deployment reads this same list and compares it against its own version locally; nothing about the deployment is sent anywhere.
sha256:a20e9c9ad74dd5048ffd9ef6c51a711688aa3fb42018f926ee3dc9460e680aefOlder releases and the reasoning behind each change are in the changelog.
Flintbay is built independently by Andrii, a developer in Ukraine. It started as a way to replace a pile of physical controls with a camera, joystick, buttons and telemetry in a browser. It now runs beside real hardware on Jetson, and exists so the next machine does not need another control app written from scratch.
It is free to self-host and it stays that way: no seat count, no paid tier, no telemetry. Support is what buys the time to keep it moving — and it is the only thing that does.
Boards, cameras and sensors, so widgets are built against machines that actually misbehave rather than against a mock that never does.
Integrations, widgets and the unglamorous parts — reconnects, roles, audit trails. Support is what turns the next release from a maybe into a weekend.
A tip jar is the alternative to a pricing page. It is why the deployment on your machine answers to you and reports nothing about itself: the only thing it fetches is the public list of releases, and that can be switched off.
Camera, controls, and telemetry in one local operator view.
Deploy Flintbay, connect your endpoints, and build the panel around your machine.