Soon Strux 0.4 and Strux Fleet are coming soon

Your web app, shipped as an operating system.

Use web technologies to build a signed, bootable Linux image. Then, use our software to manage your fleet of kiosks remotely.

curl -fsSL https://strux.sh/install.sh | sh
See how Strux Fleet works
The RT101 rugged tablet illuminated against black, running Strux OS.

~/projects

strux init my-kiosk --template vue --arch arm64
Created strux.d.ts type definitions
Agent guidance written (.agents/skills/strux, .claude/skills/strux, AGENTS.md, CLAUDE.md)
 
cd my-kiosk && strux dev --local
struxDev server listening on port 8000
struxmDNS published: _strux-dev._tcp on port 8000
struxFile watcher started
struxStarting Vite dev server...
struxVite dev server started on http://localhost:5173
struxStrux Local MCP: http://localhost:8000/mcp
struxStarting QEMU...
struxDevice connected: my-kiosk

Getting started with Strux is easy

Use the Strux CLI to scaffold a project, develop against a QEMU virtual machine or physical hardware, and then build a production image when you're ready.

$ strux init my-kiosk --template vue --arch arm64

Scaffold

strux init my-kiosk --template vue --arch arm64
Created strux.d.ts type definitions
Agent guidance written (.agents/skills/strux, .claude/skills/strux, AGENTS.md, CLAUDE.md)
my-kiosk/
├── strux.yaml         project configuration
├── main.go            Go backend entry point
├── frontend/          your Vite project
├── bsp/qemu/          board profile for dev mode
├── assets/logo.png    boot splash
├── overlay/           files copied into the OS
├── strux-update.key   signs updates, never committed
└── strux-update.pub   built into every image

$ strux dev --remote --bsp rt101-rk3568

Develop

strux dev --remote --bsp rt101-rk3568
struxDev server listening on port 8000
struxmDNS published: _strux-dev._tcp on port 8000
struxFile watcher started
struxStarting Vite dev server...
struxVite dev server started on http://localhost:5173
struxStrux Local MCP: http://localhost:8000/mcp
struxDevice connected: front-desk-01

strux build hd215-rk3576

After editing main.go

  1. 01Frontendcached
  2. 02Applicationrebuilt
  3. 03Cage compositorcached
  4. 04WPE extensioncached
  5. 05Strux clientcached
  6. 06Base rootfscached
  7. 07Kernelcached
  8. 08Bootloadercached
  9. 09Post-RootFSrebuilt
  10. 10BSP scriptsrebuilt
  11. 11Bundlerebuilt
  12. 12Image assemblyrebuilt

Get started with one command.

Strux projects use Vite web apps and a Go backend. We compile your backend types into frontend-callable code through RPC.

What every file is for
  1. Your frontend

    Use Vue, React or plain JavaScript. We configure Vite and set up hot-reload on physical devices when you run Strux in dev mode.

  2. Your Go backend

    Create a main.go file, and exported fields and methods automatically become callable in the frontend.

  3. WPE WebKit

    We ship Strux with a custom version of WPE WebKit, a powerful web engine designed for embedded devices.

  4. Cage

    We built a custom Wayland compositor around Cage. Designed to show your frontend in full-screen and nothing else.

  5. Strux runtime and client

    Your device ships with the Strux runtime and a strux client that handles the Go to TypeScript Bridge, Hardware APIs, Signed atomic updates, and fleet enrollment.

  6. Debian 13

    Based on a reliable minimal root filesystem with the basics needed to get Strux up and running. Supported until 2030.

  7. Kernel and bootloader

    Use a custom kernel and bootloader with your own defconfigs, patches, device trees, U-Boot or GRUB.

  8. Your board

    Strux supports ARM64, x86_64, or ARMhf. Any board that boots Linux can boot Strux. Describe your board using a board support package or find a community one.

Start with two files, Strux builds the whole operating system.

Start simple with a web app, then write your Go backend. Strux handles the entire build process using board support packages.

A Unified API across all your Strux devices.

The Strux Standard Library defines common APIs and abstracts them over different pieces of hardware. Our board support packages provide an interface to the Strux API so that you can develop for multiple devices at the same time with the same code.

main.go

You write

type App struct {
Title string
Counter int
}
 
func (a *App) Greet(name string) string {
return "Hello, " + name + "!"
}
strux types

frontend/src/strux.d.ts

Generated

interface App {
Title: string
Counter: number
Greet(name: string): Promise<string>
}

frontend/src/App.vue

You write

const greeting = await window.go.main.App.Greet("World")
 
if (await strux.capabilities.Supports("battery")) {
strux.battery.on("changed", (state) => render(state.percent))
}

Access the Strux API from the frontend or backend. Green APIs work on every board, Amber APIs are board-specific.

The full runtime reference
  • strux.boot
  • strux.dev
  • strux.display
  • strux.profiles
  • strux.project
  • strux.system
  • strux.update
  • strux.capabilities
  • strux.ipc
  • strux.audio
  • strux.battery
  • strux.cellular
  • strux.deviceSigning
  • strux.network
  • strux.wifi

The whole OS, replaced atomically.

Strux devices are automatically dual A/B rootfs capable. This means that you can push an update to a device while it's running and Strux will automatically switch over to your update when the device reboots. If your image fails to boot, Strux automatically rolls back your image.

  1. Stream

    Strux updates are streamed and decompressed on the fly and written straight onto your device's idle slot. There's no need to provision extra storage for updates.

  2. Verify

    Strux devices only accept the updates you sign. This ensures that your devices remain secure.

  3. Arm

    After an image is flashed, Strux automatically instructs the bootloader to try the new image at next boot.

  4. Boot

    Strux automatically tries to boot your new image on the next boot. If your image fails to boot three times, Strux automatically switches back to the previous image.

A signed bundle streams into the idle root filesystem slot, is verified, and the bootloader switches to it.rootfs.ext4.struxbmanifest.json + manifest.sig + rootfs.imgstrux-rootfs-astrux-rootfs-bstrux-dataBOOTENV.TXTBOOTBAK.TXTdevice credentials● running · 1.3.2previous · 1.3.2idlepending · strux_tries=3● active · 1.4.0✓ signature verified · sha256 matchesBootloader: boot the pending slot, decrement strux_tries. If it reaches zero without the new system marking itself good, boot the previous slot.

Signing

RSA-PSS, and Signed Builds

Strux updates are self-contained and signed by the keys stored in your project. A device without a valid public key cannot install updates at all.

Compatibility

One bundle per board.

The manifest names the board it was built for, and a device refuses a bundle built for another board.

Recovery

Three tries, then rollback.

We use a custom version of U-Boot that automatically attempts booting your new updates and falls back to older images when your update fails, ensuring you never have a bricked device.

Strux Fleet, coming soon

Manage a Fleet of Strux Devices, Seamlessly.

Publish versions of your Strux image directly to your managed fleets from the CLI. Manage versions, permissions, remote access, and troubleshooting directly from your web browser.

console.strux.sh/rollouts/8f2c1a

Rollout

kiosk-os 1.4.0 to Downtown stores

Desired release set on the Fleet. Devices converge on their next check-in.

Completed

Devices

8

Confirmed

8

Updating

0

Rolled back

0
DeviceStatusProgress
lobby-kiosk-01Confirmed
████████████████████
lobby-kiosk-02Confirmed
████████████████████
checkout-03Confirmed
████████████████████
checkout-04Confirmed
████████████████████
warehouse-wall-01Confirmed
████████████████████
warehouse-wall-02Confirmed
████████████████████
showroom-01Confirmed
████████████████████
showroom-02Confirmed
████████████████████

Enroll

Easily Deploy

Adding Strux Fleet to your Strux devices is as simple as creating an enrollment-enabled image. When your devices first boot, they connect directly to Strux Fleet and enroll themselves.

Desired state

Manage a fleet of devices

Pin a Fleet, a group, or a device to a version of your image, or let it follow a channel. You define your device state, Strux Fleet handles the rest.

Tooling

Remote management made easy

Strux Fleet allows you to access your device's screens and perform device-specific commands that you can define yourself, directly from our web portal.

Strux, Ready for the AI Era

Strux comes with a built-in MCP server. Let your agent take a screenshot, read logs, build an image, and even take control of your device directly. Plus, with built-in documentation, your AI agent can get started with Strux right away.

Strux Local MCP

strux dev

Claude Code, connected to strux dev over MCP
screenshot{ output: "DSI-1", maxWidth: 1280 }
1280 x 800 JPEG
click{ x: 812, y: 466 }
device_logs{ source: "app", grep: "checkout", limit: 20 }
3 lines
rebuild_app{}
job 12 finished: binary pushed, app restarted
screenshot{ output: "DSI-1" }
1280 x 800 JPEG

Connects from the dev terminal to

  • Claude Code
  • Codex CLI
  • Cursor
  • VS Code
  • Claude Desktop
  • Gemini CLI

# or register the endpoint by hand

$ claude mcp add --transport http strux http://localhost:8000/mcp \
--header "Authorization: Bearer <client_key>"

Runs on the boards we ship, and any board Linux boots.

We're launching Strux 0.4 with real hardware, each fully supported by Strux OS and with Strux Standard Library support.

rt101-rk3568

  • strux.cellular
  • strux.battery
  • strux.network

rt101-rk3568 · arm64

Where Strux fits.

Strux is not the only way to put a web app on a screen. However, here is how it compares with the usual routes, in plain terms.

01Yocto and Buildroot
Yocto and Buildroot give you full control over every layer, but with weeks of learning before you get a bootable image. They also stop at the operating system. The application workflow, hot reload, updates, and any remote management or fleet are yours to assemble from scratch and without help. Strux does all of this for you and is purposefully designed for the kiosk use-case.
02Electron on desktop Linux
A full desktop with unnecessary apps underneath a kiosk app. A window manager, a display manager, notifications, bugs, and more that nobody asked for. Strux boots with your splash logo straight into your application on a custom compositor that shows one window and nothing else to break out of.
03Android kiosk mode
Heavy, with Google's update schedule, Google's services, and certified hardware. Don't forget you'll need to lock it down with another paid MDM solution. Strux runs on any board that boots Linux, updates when you say so, and never phones anyone but your own fleet.

Open source, GPLv2, built by Medeiros IT for its own kiosks.

The CLI, the device runtime, and the fleet client are on GitHub. The hosted Fleet is optional, and nothing in the operating system depends on it.

curl -fsSL https://strux.sh/install.sh | sh