Hiratra Danarson

One additional thing I'd check before assuming this is a DNS provisioning issue is whether the NXDOMAIN is consistent across authoritative and recursive resolvers. Since NXDOMAIN is different from a timeout or SERVFAIL, it would be useful to verify the exact hostname and query path: ```bash dig +short lowajnbdzsxvqxnjtoq.supabase.co dig +trace lowajnbdzsxvqxnjtoq.supabase.co dig @1.1.1.1 lowajnbdzsxvqxnjtoq.supabase.co dig @8.8.8.8 lowajnbdzsxvqxnjtoq.supabase.co ``` If the hostname is confirmed to be the exact Project URL from the dashboard and multiple public resolvers consistently return NXDOMAIN, `dig +trace` can help distinguish a resolver/cache issue from the record genuinely not existing in the authoritative DNS chain. I'd also check whether the project itself is in a transitional state (recently created, restored, renamed, paused/unpaused, or otherwise undergoing provisioning), because the API hostname is infrastructure-level and a healthy dashboard state doesn't necessarily prove that the DNS record has already propagated. So I'd frame the diagnosis as: 1. Verify the canonical Project URL from the Dashboard. 2. Query multiple recursive resolvers. 3. Use `dig +trace` to check the authoritative path. 4. If the canonical hostname still returns NXDOMAIN consistently, attach those DNS results to SU-495921 so Supabase can check the project's DNS provisioning rather than spending time debugging the application. The key signal here is that a reproducible NXDOMAIN at the canonical hostname points to a different layer than a frontend/API connectivity issue.

I think the project name in the browser tab would be especially useful when working with multiple Supabase projects. For the instance distinction, I’d probably avoid relying only on different colors, since that can become difficult to scan quickly (and isn't ideal for accessibility). A small environment indicator could work better, for example: `● Supabase · my-project` `◆ Supabase Local · my-project` `◇ Supabase Self-hosted · my-project` The same distinction could be reflected in the favicon with a subtle badge or shape rather than changing the whole icon. For the tab title, I think the most useful hierarchy would be: `[Project name] · [Current resource] · Supabase` with the resource part being optional depending on the page. That would make a set of tabs like: `Production · Users · Supabase` `Staging · Users · Supabase` `Local · Users · Supabase` much easier to distinguish than having the same table name repeated across several tabs. It could also be exposed as a small preference: "Show project name in tab title" / "Show current resource". The combination of a persistent environment indicator + project name seems more useful to me than changing the favicon color alone, especially when several projects are open side by side.

I think the key distinction here is between "can technically obtain temporary AWS credentials" and "Supabase provides a supported workload identity that AWS can trust." If the hosted Edge Function does not expose a stable platform-issued OIDC identity with a documented issuer/audience/subject contract, I would avoid building an IAM trust policy around any internal or undocumented token format. That would make the authentication boundary dependent on an implementation detail that could change. For a production setup, I'd expect the trust relationship to look roughly like: Supabase Edge Function → platform-issued OIDC identity → AWS STS AssumeRoleWithWebIdentity → temporary IAM credentials → Lambda The important part is that AWS should validate the issuer and claims directly, rather than relying on an end-user Supabase JWT. If Supabase doesn't currently provide that workload identity for hosted Edge Functions, then I would consider an intermediary that owns the AWS trust boundary, or a narrowly scoped long-lived credential stored as a Supabase secret as a fallback. The latter obviously has a larger rotation/compromise surface, so I wouldn't treat it as equivalent to workload identity. I'd also be interested in whether Supabase has an internal mechanism for this that isn't exposed as a public contract. If one exists, documenting the issuer/audience/subject semantics would be particularly important for IAM trust policies. Given that you're making a production architecture decision involving financial data, I agree that "it works" isn't enough here — the supported identity contract and credential lifecycle matter just as much.