https://docs.all-hands.dev/ logo
Join Slack
Powered by
<github.com/OpenHands/agent-canvas/pull/1796> - su...
# proj-agent-canvas
q
github.com/OpenHands/agent-canvas/pull/1796 - support for deploying canvas under a subpath
✅ 1
🙌 1
This will allow us to deploy canvas on 
<http://app.all-hands.dev/canvas|app.all-hands.dev/canvas>
e
The primary motivation for this is a self-hosted OHE customer who will start using Canvas as their primary UX for OHE. Hosting as a sub-path avoids issuing new SSL certs on the internal instance running OHE. For SaaS (app.all-hands.dev), we have separate URL for Canvas here: canvas.openhands.dev
q
We decided that for consistency we'd deploy on a subpath as well, there are other benefits to do it for us as well such as not requiring the user to authenticate twice (cookies are shared)
cc @ancient-car-4311 for further elaboration/ticket details
e
ah gotcha
so that means we deprecated canvas.openhands.dev? If so, I trust you'll close the loop on this with Graham and Marketing (given this URL will become part of website CTAs)
nod 1
@limited-student-10747 @prehistoric-father-39041 FYI
w
Can we get 
<http://app.openhands.dev|app.openhands.dev>
moving in the meantime?
👍 1
(as an alias for app.all-hands.dev)
l
Thanks Rohit, this is great! I'd like to discuss what to do on integrstions hub too. Also, when this goes live let's update company-site too
q
Sounds good, yep I'm seeing what's required here and I'll look into the integration hub prs you have ready next
l
Also, Robert mentioned that our new-user onboarding activation for agent canvas at canvas.openhands.dev is really bad (<10%) probably because the login process is confusing. I wonder if you’ve tested the new user onboarding process for app.all-hands.dev/canvas and if it’s straightforward? If so, it might be worth trying to push this change to prod sooner rather than later.
q
Yep working that right now, it will be the same login page from our main app
I'll have staging ready so others can take a look first
🙏 1
also seems like we'll have two automations pages in cloud one on 
/automations
and the other on 
/canvas/automations
we'll need to plan to deprecate the former and forward to the latter
👍 1
pr-254.staging.all-hands.dev/canvas - i have things working although there is a bug where the app redirects to a 404 page after successful login and requires a page refresh to resolve (seems to be an existing bug that also applies to automations microservice page) otherwise you can start playing around with this (no more extra connect step) separately, we have a connect to cloud modal for the "add BE" section. it seems like we've explicitly disabled add BE except for OH cloud, but since we auto seed the BE its probably better UX to remove that modal all together (I'll open a ticket that's more details)
staging.openhands.dev/canvas Canvas is on staging I'll coordinate for release/coms next week There are a couple of extra items which would make the process smoother, opening tickets for them now Automations is not working in staging atm, so even though canvas is deployed properly its indicating that automations are disabled, looking into it
@millions-afternoon-47582 pr for supressing redundant telemetry consent in canvas for cloud mode, as we track it via the main apps TOS flag: github.com/OpenHands/agent-canvas/pull/1848/changes
✅ 1
Automations are working now, see staging.openhands.dev/canvas/automations
Also integrations hub on a subpath: pr-252.staging.openhands.dev/integrations-hub now that we auto-login some of the screen sequences seem like less ideal UX, and it would be nice to deploy under 
/integrations
but that path is already taken by the main app; made some low effort tweaks for now, lmk if there's any feedback regarding the flow If it looks good I'll promote it to staging
w
Rad!
well done
8 Views
Open in Slack
PreviousNext
Powered by