# Edge Function deploy failed

> A SupaHost Edge Function deploy ends in the error status. What the build check does, why it fails (entry file, imports, size limits), and how the previous version keeps serving.

Source: https://supahost.app/kb/function-deploy-failed · Updated 2026-11-11

## 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:

   ```ts
   import { createClient } from 'npm:@supabase/supabase-js@2.49.4'
   import { z } from 'npm:zod@3.24.1'
   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](/kb/esm-sh-imports).
4. **Reproduce locally.** Put the same files in a folder and run Deno's checker, which reports the exact line:

   ```bash
   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](/kb/cli-functions-deploy).

## Related

- [Deploying functions](/docs/functions/deploying)
- [Writing functions: Deno, imports and structure](/docs/functions/writing-functions)
- [Import errors with esm.sh or npm packages](/kb/esm-sh-imports)
- [Edge Function limits](/docs/functions/limits)