Using openshell-sandbox standalone on edge devices (automotive/robotics)

[engelmi]

I'm exploring how OpenShell can be applied in automotive systems - specifically, running it in the QM (Quality Management) layer. I'd like to open a discussion about whether this use case aligns with the project's direction.

Context: edge environments differ from the cloud

In automotive and robotics, workloads look quite different from the typical deployment OpenShell targets. AI agents and applications are pre-defined and static rather than dynamically spawned, communication happens over local channels rather than remote access, and sandboxes are long-lived system services, not ephemeral on-demand containers.

What I've done so far

Because of these (and other) constraints, I've been running the openshell-sandbox standalone - without a gateway. The setup:

• A custom container image with openshell-sandbox embedded as the entrypoint
• OPA, OpenShell, and inference policies either baked into the image or bind-mounted read-only from the host
• Managed as a Podman Quadlet unit under systemd, with audit logs flowing to journald

This works today because the sandbox gracefully handles an unreachable gateway and falls back to its local configuration. I'm aware that this approach sacrifices gateway-dependent features like policy hot-reload, credential rotation, and middleware services - but for statically defined, locally scoped sandboxes, that trade-off seems acceptable.

Questions

1. OpenShell's current focus is clearly on cloud deployments. Are there plans to expand into edge, embedded, or other domains?
2. Running the sandbox standalone without a gateway isn't a documented use case. Would the project consider it a valid application of OpenShell? If so, would it make sense to document it?

[sylvesterkaczmarek]

Yes, I think the low-level OpenShell runtime fits this use case reasonably well.

There is now a documented standalone openshell-sandbox mode that runs directly with policy rules and inference routes, without requiring a gateway. That seems much closer to a static, long-lived automotive/robotics deployment than dynamically creating sandboxes through the control plane.

The main difference is that standalone mode leaves lifecycle, restart/health supervision, updates, and policy/route distribution to the surrounding system. For automotive I'd probably treat OpenShell as the confinement/policy runtime inside the QM layer, with systemd or the platform service manager owning the long-lived process.