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?