apps/docs/content/guides/self-hosting/self-hosted-functions.mdx
Edge Functions work out of the box in a self-hosted Supabase setup. The functions service, API gateway routing, and a hello example function are all pre-configured.
On managed Supabase platform, Edge Functions are deployed across multiple regions. Self-hosted standalone instance configuration resembles a standard serverless setup.
</Admonition>The default hello function is located at volumes/functions/hello/index.ts. You can invoke it immediately after starting your stack:
curl http://<your-domain>:8000/functions/v1/hello
This returns "Hello from Edge Functions!".
mkdir -p volumes/functions/my-function &&
touch volumes/functions/my-function/index.ts
add the following code to index.ts:
Deno.serve(async (req: Request) => {
const { name } = await req.json()
const message = `Hello, ${name}!`
return new Response(JSON.stringify({ message }), {
headers: { 'Content-Type': 'application/json' },
})
})
docker compose restart functions --no-deps
curl -X POST http://<your-domain>:8000/functions/v1/my-function \
-H 'Content-Type: application/json' \
-d '{"name": "World"}'
You should be able to see the response from my-function:
{"message":"Hello, World!"}
For multiple variables or secrets, create a separate env file, e.g., .env.functions in your docker/ directory:
MY_CUSTOM_VAR=some-value
Add env_file to the functions service in docker-compose.yml (variables in env_file load first, then environment values take precedence):
functions:
env_file:
- .env.functions
environment:
JWT_SECRET: ${JWT_SECRET}
SUPABASE_URL: http://kong:8000
Don't commit .env.functions to version control if it contains secrets. Add it to your .gitignore.
Restart the functions service:
docker compose up -d --force-recreate --no-deps functions
For one or two variables, you can add them directly under environment in docker-compose.yml:
functions:
environment:
# Custom variables
MY_CUSTOM_VAR: ${MY_CUSTOM_VAR}
# Required variables
JWT_SECRET: ${JWT_SECRET}
SUPABASE_URL: http://kong:8000
Then define MY_CUSTOM_VAR in your main .env file, or specify the value directly.
All container environment variables are forwarded to function workers by main/index.ts. Access them with:
const customVar = Deno.env.get('MY_CUSTOM_VAR')
The functions service is pre-configured with the following environment variables:
| Variable | Value | Purpose |
|---|---|---|
SUPABASE_URL | http://kong:8000 | Internal API gateway URL |
SUPABASE_PUBLIC_URL | http://<your-domain>:8000 | Base URL for accessing Supabase from the Internet |
JWT_SECRET | Your secret key | Legacy symmetric encryption key used to sign and verify JWTs |
SUPABASE_ANON_KEY | Your anon key | Client-side API key with limited permissions (anon role). |
SUPABASE_SERVICE_ROLE_KEY | Your service role key | Server-side API key with full database access (service_role role) |
SUPABASE_DB_URL | Postgres connection string | Can be used for direct database access |
Here's an example function that queries a table using @supabase/supabase-js:
import { createClient } from 'https://esm.sh/@supabase/supabase-js@2'
Deno.serve(async () => {
const supabase = createClient(
Deno.env.get('SUPABASE_URL')!,
Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
)
const { data, error } = await supabase.from('todos').select('*')
return new Response(JSON.stringify({ data, error }), {
headers: { 'Content-Type': 'application/json' },
})
})
This is a key distinction that affects how you build URLs in your functions:
SUPABASE_URL contains an internal Docker network hostname. Use it for server-side calls from your functions to other Supabase services (Auth, Storage, database via PostgREST). This is what the Supabase JS client should use inside functions.
SUPABASE_PUBLIC_URL is the externally-reachable URL of your Supabase instance (e.g., <your-domain>:8000). Use it if your function needs to build URLs that HTTP clients can reach from the outside.
Self-hosted Studio mounts the same volumes/functions directory as the functions service. You can check what functions are available using Edge Functions > Functions UI.
To deploy a function to a remote server running self-hosted Supabase, copy the function directory with scp:
scp -r ./my-function user@<your-domain>:/path/to/self-hosted/volumes/functions/
Then restart the functions service on the remote host:
ssh user@<your-domain> 'cd /path/to/self-hosted && docker compose restart functions --no-deps'
If you have existing functions on Supabase platform, you can download them and run them on your self-hosted instance. There are two ways to get the function source code:
supabase functions download <function-name> --project-ref <ref> to download the source.Use scp to copy the function into volumes/functions/<function-name>/ on your self-hosted instance, then restart the functions service.
For more details, see:
The request URL must include the function name after /functions/v1/. For example, /functions/v1/hello — not just /functions/v1/.
Check the functions service logs:
docker compose logs functions
Common causes: syntax errors in your function code, invalid imports, or missing dependencies.
FUNCTIONS_VERIFY_JWT matches your intent (true or false) in .envAuthorization: Bearer <anon_key or service_role_key>Restart the functions service:
docker compose restart functions --no-deps
docker-compose.yml (under env_file or environment)Use the following command to recreate the container, not just restart:
docker compose up -d --force-recreate --no-deps functions
The default limits are 150 MB memory and 60 seconds timeout per function invocation. These are set in volumes/functions/main/index.ts. To adjust them, edit the memoryLimitMb and workerTimeoutMs values and restart the functions service.