SUPABASE_URL is incorrect in edge function when developing locally

[mark-monteiro]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

When developing a supabase edge function locally, I am reading the built-in secret SUPABASE_URL as documented here: https://supabase.com/docs/guides/functions/secrets#default-secrets.

The value being returned is http://kong:8000, which I assume is the address and port for internal docker networking. However, I would expect this value to be the value http://127.0.0.1:54321, as returned from supabase status. This is the address the API can actually be accessed at.

To Reproduce

1. Create edge function
2. Read value of SUPABASE_URL (console.log(Deno.env.get(SUPABASE_URL)))
3. See incorrect value http://kong:8000

Expected behavior

The value should be http://127.0.0.1:54321

Screenshots

If applicable, add screenshots to help explain your problem.

System information

• OS: Windows (podman)
• Version of supabase CLI: 2.26.9
• supabase edge runtime: 1.67.4
• Browser: N/A
• Version of supabase-js: N/A
• Version of Node.js: N/A

Additional context

None

[a0m0rajab]

the value is hardcoded in the docker compose file:

supabase/docker/docker-compose.yml

Lines 38 to 39 in f4222eb

	SUPABASE_URL: http://kong:8000
	SUPABASE_PUBLIC_URL: ${SUPABASE_PUBLIC_URL}

[mark-monteiro]

Since opening this I've realized that the value returned for SUPABASE_URL is fine for most use cases (i.e. creating a supabase-js client to call the API).

In my specific use case I needed the publicly facing URL for something else. I think a good resolution here would be to expose the SUPABASE_PUBLIC_URL variable in addition to SUPABASE_URL.

[a0m0rajab]

@mark-monteiro looking at functions variables seems like the does not have the public url exposed, if that's the case then your solution is simple, you need to just add one line here: SUPABASE_PUBLIC_URL: ${SUPABASE_PUBLIC_URL}

supabase/docker/docker-compose.yml

Lines 315 to 338 in f4222eb

	functions:
	container_name: supabase-edge-functions
	image: supabase/edge-runtime:v1.67.4
	restart: unless-stopped
	volumes:
	- ./volumes/functions:/home/deno/functions:Z
	depends_on:
	analytics:
	condition: service_healthy
	environment:
	JWT_SECRET: ${JWT_SECRET}
	SUPABASE_URL: http://kong:8000
	SUPABASE_ANON_KEY: ${ANON_KEY}
	SUPABASE_SERVICE_ROLE_KEY: ${SERVICE_ROLE_KEY}
	SUPABASE_DB_URL: postgresql://postgres:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
	# TODO: Allow configuring VERIFY_JWT per function. This PR might help: https://github.com/supabase/cli/pull/786
	VERIFY_JWT: "${FUNCTIONS_VERIFY_JWT}"
	command:
	[
	"start",
	"--main-service",
	"/home/deno/functions/main"
	]

I could not test this yet, but in theory it can work, I need to setup self hosted and functions (Which I can not at the moment)
@mark-monteiro can you try it? yeah this is the solution to your issue.

[mark-monteiro]

Okay, that makes sense. I'm not using a self-hosted setup with docker compose though, I'm using the supbase CLI with supabase functions serve

[Hallidayo]

Hi guys, I'm going to move this over as a discussion, thanks for your help on this one.

[mark-monteiro]

@Hallidayo Not sure if converting this to a discussion was appropriate. There is still no way to access SUPABASE_PUBLIC_URL in edge functions. That was not resolved in the issue

[Hallidayo]

Hi @mark-monteiro - ah sorry I misread. I'll create a new issue with a link to this discussion.

[aliakseikislou]

Hi all, any update on this? I'm facing the same issue — I'm using SUPABASE_URL in my Edge functions on a local config and need to access http://127.0.0.1:54321, but not http://kong:8000 (e.g., for webhooks to work).

I'm using Supabase CLI for managing the local instance. There is no docker-compose.yml though, the containers are handled by CLI I believe.

[parigi-n]

@aantti Quite an annoying problem with local self-hosting for development

[aantti]

Been thinking of adding SUPABASE_PUBLIC_URL to docker-compose.yml, but it might introduce more confusion in some cases.

[parigi-n]

Been thinking of adding SUPABASE_PUBLIC_URL to docker-compose.yml, but it might introduce more confusion in some cases.

It might be the easiest solution ? I don't know what would be the edge cases associated with this.

[aantti]

An alternative might be to define own variable in .env and use it for development? E.g., define LOCAL_URL and have a code that checks for it and substitutes it for SUPABASE_URL? (See Environment variables.)

[aantti]

@kallebysantos jfyi

[erichjrusch]

We're experiencing this issue trying to change edge functions over to the new middleware while developing locally.

https://supabase.com/docs/guides/functions/auth

import * as jose from "jsr:@panva/jose@6";

const SUPABASE_JWT_ISSUER = Deno.env.get("SB_JWT_ISSUER") ??
  Deno.env.get("SUPABASE_URL") + "/auth/v1";

const SUPABASE_JWT_KEYS = jose.createRemoteJWKSet(
  new URL(Deno.env.get("SUPABASE_URL")! + "/auth/v1/.well-known/jwks.json"),
);

function getAuthToken(req: Request) {
  const authHeader = req.headers.get("authorization");
  if (!authHeader) {
    throw new Error("Missing authorization header");
  }
  const [bearer, token] = authHeader.split(" ");
  if (bearer !== "Bearer") {
    throw new Error(`Auth header is not 'Bearer {token}'`);
  }

  return token;
}

function verifySupabaseJWT(jwt: string) {
  return jose.jwtVerify(jwt, SUPABASE_JWT_KEYS, {
    issuer: SUPABASE_JWT_ISSUER,
  });
}

// Validates authorization header
export async function AuthMiddleware(
  req: Request,
  next: (req: Request) => Promise<Response>,
) {
  if (req.method === "OPTIONS") return await next(req);

  try {
    const token = getAuthToken(req);
    const isValidJWT = await verifySupabaseJWT(token);

    if (isValidJWT) return await next(req);

    return Response.json({ msg: "Invalid JWT" }, {
      status: 401,
    });
  } catch (e) {
    return Response.json({ msg: e?.toString() }, {
      status: 401,
    });
  }
}

Basically, I think JWT verification is getting tripped up because the internal url is not the same as the external url since it's just string comparison.

kong:8000 = internal service URL inside Docker network

127.0.0.1:54321 = external/public URL you access from your laptop

JWT iss must match the public issuer used when token is minted, so anything related to JWT validation should leverage 127.0.0.1

EIther way... adding a SB_JWT_ISSUER=http://127.0.0.1:54321/auth/v1 solves all of the issues, but I am wondering Is there something wrong with my setup or should I just use the public url when verifying JWT claims?

[aantti]

As an update - added a note on internal vs external URLs here: https://supabase.com/docs/guides/self-hosting/self-hosted-functions#internal-vs-external-urls (as well as adding SUPABASE_PUBLIC_URL to the configuration of functions in self-hosted Supabase)

[whollacsek]

Thanks for adding it to the doc, but it is not clear if SUPABASE_PUBLIC_URL should be set manually or will be automatically exposed locally and on Supabase Cloud. Also, I noticed SUPABASE_JWKS is available locally but not documented

[kallebysantos]

but it is not clear if SUPABASE_PUBLIC_URL should be set manually or will be automatically exposed

This env is automatically exposed on all platforms (Cloud Platform, Self-host and Local dev CLI)

I noticed SUPABASE_JWKS is available locally but not documented

Its on a separated docs page, please see https://supabase.com/docs/guides/self-hosting/self-hosted-auth-keys
We didn't exposed it for Cloud Platform yet, but its already available on Self-host and Local dev CLI