Skip to content

Player · Raspberry Pi appliance tooling

A reproducible signage appliance, ready for image and hardware QA.

The Canvas Relay Pi project uses the existing browser player in Cage/Chromium and adds current Raspberry Pi image tooling, A/B partitions, hardware watchdog, local telemetry, actual capture and controlled reboot. Source is ready; production hardware support is not claimed yet.

Cloud basedAccess anywhere
Design onceUpdate in real time
Relay everywhereAny screen, any size
Reliable & secureOffline playback built in

Appliance architecture

Image, boot services, browser renderer, screen.

The image source and recovery design exist. Downloadable production images and hardware support wait for exact Pi, display, storage, and power testing.
raspberry pi
Hardware QA required
01
Build and validate image

Pinned rpi-image-gen source and static validation

SOURCE READY
02
First boot

Unique local-agent credential, Cage, Chromium

NO SHARED SECRET
03
Pair on screen

Six-digit code creates the cloud device identity

PAIRING
04
Recover locally

systemd, hardware watchdog, last-known-good release

OFFLINE SAFE
OUTPUTAssigned Canvas Relay board

Appliance tooling · physical QA required

rpi-image-gen project and static validation are available. A downloadable release image and exact Pi/display/storage compatibility require a real build and physical QA.

What the appliance project provides

01

Current 64-bit OS architecture

The project follows the official Trixie arm64 web-kiosk example with Cage and Chromium instead of mutating a floating latest image through an X11 chroot.

02

No shared device secret

First boot generates a local agent credential. Canvas Relay pairing still creates the unique cloud device identity on screen; credentials are not baked into the image.

03

Layered recovery

systemd restarts the agent and kiosk, Raspberry Pi's kernel/systemd hardware watchdog covers a wedged OS, and the browser player preserves last-known-good content.

04

Fleet Health bridge

A localhost-only agent reports model, OS, architecture, uptime and boot identity, and enables capability-gated actual screenshot capture and clean reboot.

05

A/B-ready image layout

The image uses rpi-image-gen's A/B base and persistent data layout. Canvas Relay does not invent an unsafe OTA flasher; slot update and rollback remain release-engineering work to validate.

06

Imager-compatible onboarding

Sample cloud-init customization reflects current Raspberry Pi Imager behavior. Wi-Fi values remain deployment inputs, never repository secrets.

Questions, answered

01Can I download a production image now?+

Not yet. The repository contains reproducible rpi-image-gen source and structural validation, but Canvas Relay does not claim a downloadable production image or physical-hardware pass until an image is built and exercised on the target Pi, display and storage media.

02Which Raspberry Pi OS base does it use?+

The current project follows Raspberry Pi's official 64-bit Trixie rpi-image-gen web-kiosk and A/B layout guidance. Package inputs still need a controlled snapshot or recorded manifest for byte-for-byte release reproducibility.

03How is Wi-Fi configured?+

Use current Raspberry Pi Imager cloud-init/rpi-preseed customization or Ethernet. Legacy boot-partition wpa_supplicant.conf guidance is not valid on current Bookworm/Trixie images, and no shared Wi-Fi credential is baked into the image.

04Does it keep playing offline?+

The hosted browser player retains its complete last-known-good release and starts without waiting on a public ping. Actual power-cut, cache-pressure and long-duration offline behavior still belongs in the physical QA checklist.

Build, flash and test before production.

Run the static validator, build with a pinned rpi-image-gen revision, verify manifests, then complete the physical power, network, display, cache, capture and rollback checklist.

Try the editor — no account needed

Free plan includes one live screen. No credit card. No trial clock.