feat(frontend): add cloud region selector on sign-in

[mmabrouk]

Summary

• add cloud region selector UI with info modal on the auth page
• store preferred region in cookie and redirect from cloud alias when needed
• wire cloud region env + update Next config to transpile workspace package

Config

• Runtime env (secrets/vars): AGENTA_CLOUD_REGION=eu|us (injected into NEXT_PUBLIC_AGENTA_CLOUD_REGION via web/entrypoint.sh)
• Existing required vars (already in use): AGENTA_WEB_URL (sets NEXT_PUBLIC_AGENTA_WEB_URL), AGENTA_API_URL

---

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agenta-documentation	Ready	Preview, Comment	Feb 5, 2026 1:07pm

[mmabrouk]

@jp-agenta we need to set these Runtime env (secrets/vars): AGENTA_CLOUD_REGION=eu|us (and probably in staging or so for testing)

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 5 additional flags.

[devin-ai-integration]

(Refers to lines 12-31)

🚩 transpilePackages now applies in development mode too

The transpilePackages array was previously only applied in production (!isDevelopment). Now it's moved to the common config at next.config.ts:31 and includes @agenta/oss. This means these packages are transpiled in both development (with Turbopack) and production builds. This is likely intentional to support the workspace package, but it's a behavior change worth noting for the reviewer.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[mmabrouk]

@ardaerzin I think this was changed due to some local issue compiling. It should be reverted right>

[junaway]

@mmabrouk

• I added copy fixes (mostly Virginia > Ohio)
• We already have ACCOUNT=[..., cloud], REGION=[..., eu, us], STAGE=[..., live] at the platform level. We might want to expose them to the application level, indeed.

However, in this PR, plenty of things seem to be hardcoded:

• The available regions
• The region details
• The url structure
• The region urls

I'd say that adding an env var for the region only is not clean. Either we put everything in env vars or nothing.

In this case, I'd

• either extract the current region from the current hostname (given that we are hardcoding the url structure, why not?)
• or put all the bullet points in env var(s).

I guess the former is simpler.

Now, in self-hosted, all this would still be visible ? Even the decision to show this whole thing or not follows the same rule:

• either we display based on the hostname
• or we have it as part of the env var(s) info.