[Bug]: OpenDesign AMR 无法登录

[MakeItAlright]

Before you submit

• I searched existing issues and confirmed this is not a duplicate.
• I replaced the example text with the real behavior, reproduction steps, expected result, and version from the app's About menu or od --version.

What happened?

我将opendesign放到服务器用docker部署运行，我的服务器没有外网，当我尝试登录AMR账号的时候无法进行登录，一直处于登录中

Steps to reproduce

1. 打开opendesign网页
2. 登录AMR账号
3. 浏览器控制台，login地址出现报错提示 409（Conflict）
   补充：我的opendesign放到服务器上启动，但是服务器没有访问外网功能，如果AMR CLI工具内的登录地址可以支持中国用户访问，我想问题应该能够得到解决。

Expected behavior

期望AMR CLI工具的登录地址可以被中国地区的用户正常访问

Open Design version

0.11.1

Platform

Linux

Logs (optional)

Screenshots (optional)

No response

Additional context

No response

[open-design-bot]

🎉 ✨ Welcome to Open Design, @MakeItAlright!

✨ 🔥 Lit the spark.

🌱 Your first contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hey @MakeItAlright — thanks for the clear repro, especially the detail that this is a Docker deployment on a server with no outbound internet.

Reading the current AMR login path, the 409 Conflict here looks like a follow-on symptom, not the primary failure: Open Design starts vela login on the server/daemon side, and repeated clicks while that login process is still in flight return 409 already running. So if the container/daemon itself cannot reach the AMR endpoints, browser-side access in China will not unblock this flow by itself.

That makes this report look different from the earlier TLS edge case in #3726. The current working hypothesis is: AMR sign-in is not usable from a fully offline self-hosted server today, and the product should fail more clearly instead of sitting in a long “logging in” state and then surfacing a confusing 409 on retries.

If you can share one more data point, the most useful one would be whether the Open Design container/daemon can reach amr-api.open-design.ai at all from inside the server environment. If it cannot, we should treat this as a product gap in self-hosted/offline AMR support rather than a China-browser-only login URL problem.

In the meantime, for a fully offline deployment, the practical workaround is to use a local/BYOK runtime instead of AMR, since the current AMR auth flow depends on daemon-side outbound connectivity.

[lefarcen]

Hey @i-win-again — thanks for picking this up. Your plan to make the proxy path explicit in the Docker env/docs makes sense for this report, especially since the current failure mode is so confusing on restricted-network deployments.

Assigned to you now — looking forward to the PR.

[lefarcen]

已有对应 PR 在推进：#5046 现在聚焦两件事——把受限网络 / 无外网部署下的代理与离线认证用法（ / ）写进部署文档和示例环境变量，同时避免 fork 上的 工作流因为缺少 R2 secrets 直接失败。先把 issue 保持打开，等这个修复合并后再确认受限网络部署的实际体验。

[lefarcen]

已有对应 PR 在推进：#5046 现在聚焦两件事——把受限网络 / 无外网部署下的代理与离线认证用法（HTTPS_PROXY / VELA_RUNTIME_KEY）写进部署文档和示例环境变量，同时避免 fork 上的 bake-plugin-previews 工作流因为缺少 R2 secrets 直接失败。

先把 issue 保持打开，等这个修复合并后再确认受限网络部署的实际体验。

[lefarcen]

Hey @i-win-again — thanks, I saw #5046.

The proxy + offline VELA_RUNTIME_KEY documentation update is exactly the right place to push this issue forward. Let’s keep the code-level / merge-specific discussion on the PR thread so it stays in one place; we’ll keep this issue open until the PR feedback is resolved and the fix lands.

If anything issue-specific changes on the self-hosted/offline behavior after review, we can loop back here.

[lefarcen]

Re-opening this issue for community contribution because linked PR #5046 has had no author activity.

The PR has been left open as draft so @i-win-again can resume later, and others may /claim this issue if they want to take it on.

[lefarcen]

Hey @i-win-again — Synclo bot here. I’ve flagged this to a human maintainer for the close-out / merge decision so they can review the current PR + issue state directly.

We’ll keep the issue state aligned with whatever lands on #5046.