Edge Function deploy failed

What you see

You click Deploy function (or Deploy new version) in the Functions tab, or an AI agent calls deploy_edge_function over MCP. The status shows deploying for a while and then changes to error instead of active.

Why it happens

A deploy goes through three steps:

1. The source files are saved.
2. Your instance bundles the function as a check. This resolves every import and builds the module graph. It also warms the module cache so the first request is fast.
3. If the bundle succeeds, the new version goes live.

If step 2 fails, the status becomes error. Typical reasons:

• No index.ts entry file. The entry must be index.ts at the function's root and call Deno.serve.
• An import can't be resolved: a typo in a package name, a version that doesn't exist, a bare specifier like import Stripe from 'stripe' with no npm: prefix, or a wrong relative path such as ./shared/cors.ts when the file is _shared/cors.ts.
• A syntax error that stops the module from being parsed.
• Too big or too slow to bundle. The check has 150 seconds and 768 MB. Huge dependency trees can exceed it.
• Over the source limits: 50 files, 1 MB of source in total, folders nested at most 8 levels deep.
• Bad slug: lowercase letters, digits, - and _, starting with a letter or digit, up to 63 characters. A project can have up to 100 functions.

How to fix it

1. Your users aren't affected yet. When a deploy fails, the previous active version keeps serving. Fix calmly.

2. Check the entry file. In the editor (Dashboard → your project → Functions tab → Edit), confirm there's an index.ts and that it calls Deno.serve.

3. Use explicit import specifiers with pinned versions:

   import { createClient } from 'npm:@supabase/[email protected]'
   import { z } from 'npm:[email protected]'
   import { corsHeaders } from './_shared/cors.ts'
   

   Don't rely on a deno.json or import map to resolve bare names. See Import errors with esm.sh or npm packages.

4. Reproduce locally. Put the same files in a folder and run Deno's checker, which reports the exact line:

   deno check supabase/functions/send-invoice/index.ts
   

   Running supabase functions serve from the Supabase CLI against a local stack also works for testing. Deploying still happens through SupaHost.

5. Trim dependencies if bundling is slow: replace a large SDK with a direct fetch to the provider's HTTP API, or import a smaller submodule.

6. Deploy again. The status should go from deploying to active.

On SupaHost

Status values are deploying, active and error. deploy_edge_function over MCP returns immediately with status deploying; an agent should check again with list_edge_functions or get_edge_function before testing. The Supabase CLI command supabase functions deploy isn't supported; see supabase functions deploy doesn't work with SupaHost.

Related

• Deploying functions
• Writing functions: Deno, imports and structure
• Import errors with esm.sh or npm packages
• Edge Function limits