I'm trying to implement some apps using the new sidecar architecture, and having some issues Background: • I host my canvas at

<http://canvas.rbren.io|canvas.rbren.io>

• Apps currently serve their SPAs in an iframe, served on a different port • Apps currently serve their backends also on a different port The problem is that agent-server credentials are stored in localStorage, so the iframe window can't access them. I also disallow traffic to arbitrary ports on

<http://canvas.rbren.io|canvas.rbren.io>

, so everything has to be proxied through OpenHands, or a special nginx route has to be set up for each app. Here's my suggestion: • When an app is installed, the backend sets up a proxy for

/apps/$app-name

, pointing to

localhost:$app-port

• This serves both frontend and backend • OpenHands decides the port (so we can avoid conflicts, e.g. two different apps trying to claim 3000). App must respect some env var like $OPENHANDS_PORT during setup • If the app wants to set up both a frontend and a backend, it can start a proxy server

Seems interesting, but is this an edge/corner case?

I think the shift is also in framing how the apps run. They are authenticated already with the agent server, or should be, so you can run whatever you need in your SPA. It also should not be in an iframe unless designed to be

Yes, I don't know why iframe

Apps are loaded by

loadCanvasExtensionModule()

. It turns the fetched ESM bundle into a Blob URL and dynamically imports it:

await import(/* @vite-ignore */ moduleUrl);

Then the app calls the bundle’s required

activate(host)

export. Pages are injected into their route container through the extension’s registered

mount({ container, ... })

callback.

forget the iframe bit 🙂

Got it, I see the issue. This should probably be handled by the agent-canvas ingress instead of the agent server though? Since we already have an ingress server

maybe...I think you want to dynamically provision the proxy though. i.e. if I install an app, start proxying from

/app/$app-name

to a specific port

Yeah, tbh I don’t think we have a great separation of concerns right now. Like why is automations a separate service in the first place?

agreed, in some analysis I made, I had to acknowledge that automations were initially designed for the cloud, and it’s a bit awkward or overkill on other backends