https://docs.all-hands.dev/ logo
Join Slack
Powered by
Hey, what is the recommended way to secure an agen...
# proj-agent-canvas
t
Hey, what is the recommended way to secure an agent canvas instance running(auth/login page or something) in a self hosted cloud? And accessible from outside so webhook events can hit the automation server
s
I'm just a lurker. Somebody may give you a better answer specifically for Agent Canvas. First, I would ask if you are sure that you want it accessible from the outside. I would suggest considering options like Tailscale rather than leaving wide open. github.com/tailscale/tailscale Either way, for auth I like Authentik. I've used it for years. A beast for FOSS auth. github.com/goauthentik/authentik
nod 1
t
The thing is that my automation relays on linear webhook events, so it needs to be reachable by linear API, what other option I have otherwise?
c
One weird trick I made at some point was to set up a minimal Cloudflare worker, only to capture the webhook events; and a Cloudflare tunnel to my localhost was delivering them
Another option might be better, if Linear has some other API to connect to, rather than rely on webhooks, but I don’t know if it does. Like ws
Re: the original question, please note that agent-canvas has a session key that it requires from agent-server when it connects to a remote agent-server
That might be enough, though it’s only a token
s
I was looking at this. Seems you could expose the webhook on a different port than your Agent Canvas. Reverse-proxy if you want? inventivehq.com/blog/linear-webhooks-guide#…
t
ATM for local testing im using ngrok to expose only the port 18001 i think It wss
👍 1
Which is the endpoint only for automations
So this why you are exposing one piece of the api instead of everything (port 8000)
w
I use nginx w/ basic auth, plus some rate limiting
if you run 
LOCAL_BACKEND_API_KEY=yourpassword agent-canvas --public
that's also secure--the frontend will ask you for 
yourpassword
before you can connect
but good to have an extra layer of auth
l
@fresh-machine-37269 find the current state of our documentation/functionality regarding this and comment here. I suspect that we don't have a good how-to guide so we'll probably want to create an issue on the docs repo on creating one. We also have a linear epoch on "barrier-free ai development: securely accessing external context" so make sure the ingested GitHub issue is marked as a sub issue of that epoch
@modern-fireman-99755 this didn’t start for me, maybe I’m not on the permissions list?
c
if we replace the old one, we could just hook this to 
@openhands
, right?
no need for some ‘oss-‘ prefix
(sorry for nitpicking!)
l
Yeah, probably will do that eventually
m
I’m not on the permissions list?
yes, you were not because you are not using an openhands.dev mail for your slack user. I updated that. but I'm not sure this will solve the problem in this specific case, because we have a mentions inside a thread. I'm double-checking if we can improve the polling mechanism
l
@quick-window-91705 also encountered the issue of not being able to look inside a thread when using a bot token, so we might be having that issue here too
c
🤔 that reminds me, if it’s a Slack app, maybe we can think of making it per event at some point, we shouldn’t need polling
I don’t know if it’s a solution right now, maybe not, but on medium-long term I think it is
m
🤔 that reminds me, if it’s a Slack app, maybe we can think of making it per event at some point, we shouldn’t need polling
To do that we should expose an end-point on our side, right?
c
no, third option: openhands connects to Slack event API
this can be a starting point for your agent: https://enyst.github.io/smolpaws-slack.html
m
ah ok thanks. I will give a look
❤️ 1
c
I mean, there are three alternatives: (at least) • polling (from OH to Slack) • webhook (from Slack to OH, needs exposure) • socket mode (from OH to Slack, per event outbound connection)
l
yeah, that’s on the roadmap but not finished yet
👀 1
m
@fresh-machine-37269 find the current state of our documentation/functionality regarding this and comment here. I suspect that we don't have a good how-to guide so we'll probably want to create an issue on the docs repo on creating one. We also have a linear epoch on "barrier-free ai development: securely accessing external context" so make sure the ingested GitHub issue is marked as a sub issue of that epoch
👀 1
f
🤖 On it! View progress here: oss-agent-canvas.ngrok.dev/conversations/…
I looked into the current state of our docs and functionality on securing a self-hosted Agent Canvas instance while exposing it for incoming webhooks. Summary: What we have today (partial) ⢠
backend-setup/vm.md
covers securing the VM, 
LOCAL_BACKEND_API_KEY
+ 
--public
mode, and reaching the UI via SSH tunnel / ngrok / reverse proxy + TLS â but it's framed around UI access, not incoming webhooks. ⢠The in-repo 
docs/SELF_HOSTING.md
shows the architecture (automation backend on :18001, routed at 
/api/automation/*
behind the ingress proxy) but never explains how to expose that path for external services. ⢠
managing-automations.md
/ 
prebuilt-automations.md
mention webhook triggers exist, but don't cover how to securely expose the webhook endpoint on a self-hosted instance. ⢠Event-based automations docs are Cloud-focused (GitHub App event routing) â no self-hosted webhook-ingestion guide. The gap There's no how-to guide for the exact question in this thread: "secure a self-hosted Agent Canvas + make it reachable from outside so webhook events (Linear/Slack/GitHub) can hit the automation server." The recommended pattern from this thread â expose only 
/api/automation/*
(or just the automation port), rely on 
LOCAL_BACKEND_API_KEY
+ the backend's built-in HMAC signature verification, optionally front it with nginx basic auth / Cloudflare / Tailscale â isn't captured anywhere. Docs issue created I opened https://github.com/OpenHands/docs/issues/669 requesting a dedicated how-to guide covering: the deployment shape, authenticating webhook calls, safe exposure options (ngrok scoped to the automation endpoint, Cloudflare Tunnel/Worker, nginx path-scoped + basic auth, Tailscale), signature verification, and a worked Linear example. Linear parent (needs a hand) I couldn't set the sub-issue link on the Linear epoch "Barrier-free AI development: securely accessing external context" â I don't have Linear API credentials in this environment, so I can't mark the ingested GitHub issue as a sub-issue of the epoch. Once Linear ingests issue #669 via the GitHub integration, someone with Linear access will need to set its parent to that epoch. (Happy to do it if a Linear API key is made available.) This summary was generated by an AI agent (OpenHands) on behalf of @limited-student-10747.
✅ Done! Done. I investigated the current state of our docs/functionality on securing a self-hosted Agent Canvas instance for incoming webhooks, created a docs issue (github.com/OpenHands/docs/issues/669) requesting a dedicated how-to guide, and posted a summary with findings back to the Slack thread. Key findings: existing docs (backend-setup/vm.md, SELF_HOSTING.md, automation docs) cover VM security + UI access but there's no how-to guide for the specific use case of exposing the automation webhook endpoint (
/api/automation/*
) for external services like Linear/Slack/GitHub. The thread's recommended pattern (expose only the automation port, rely on LOCAL_BACKEND_API_KEY + HMAC signature verification) isn't documented anywhere. Note: I could not set the Linear parent relationship on the epoch "Barrier-free AI development: securely accessing external context" because no Linear API credentials are available in this environment. This is flagged in the Slack comment â once Linear ingests issue #669 via the GitHub integration, someone with Linear access needs to set its parent to that epoch (or provide me a Linear API key and I'll do it).
2 Views
Open in Slack
PreviousNext
Powered by