Deploying Deno Fresh + TypeScript + Supabase to Production

I've deployed this Deno Fresh + TypeScript + Supabase stack to production three times. Here's what really happens when you ship it, not the marketing bullshit.

Fresh Is Fast Until It Isn't

Fresh's islands thing ships zero JavaScript by default so your Lighthouse scores look incredible. But the moment you need real interactivity, you're writing islands and suddenly dealing with hydration mismatches that make you want to throw your laptop.

I learned this the hard way when our dashboard went from 98 Lighthouse to 72 after adding client-side charts. The island hydration kicked in and suddenly we had layout shifts everywhere. Fresh is great for content-heavy sites but struggles with app-like interfaces.

Supabase Edge Functions on Deno Deploy do hit sub-100ms cold starts most of the time. But "most of the time" means you'll get random 2-second spikes that will make your monitoring alert. The edge works great until it doesn't.

TypeScript Everywhere (Including the Bugs)

The type safety actually works, which is rare. Supabase's type generation from PostgreSQL schemas means when you add a column, TypeScript immediately yells at you everywhere it's missing.

Here's the shit they don't tell you: the generated types break constantly. Change a table name? The types don't update until you restart the dev server twice and sacrifice a goat. Add a foreign key? The types are wrong for complex joins half the time and you get lovely errors like Property 'user_profiles' does not exist on type 'Database' even though it clearly fucking does.

I've wasted entire afternoons debugging TypeScript errors that were just stale generated types. The type generation breaks in weird ways too - had it generate a User type with 'undefined' for every property after I renamed a table. Spent an hour thinking my query was broken when it was just the types lying to me.

The Deno TypeScript support is solid but I've hit weird import resolution bugs that force you to restart the LSP. Always pin Deno versions in production - auto-updates will bite you when you least expect it.

Security Is Good When You Remember to Use It

Deno's permission model is actually useful. Running with --allow-net=api.stripe.com,supabase.io means your code can't accidentally phone home to random APIs. This caught a compromised dependency that was trying to send data to a Chinese server.

Supabase RLS is where most people fuck up. The policies look simple but get complex fast. I spent two days debugging why users could see each other's data only to find a missing auth.uid() = user_id check in a join table policy.

The Development Experience Reality Check

The file-based routing in Fresh is nice until you have 50 routes and can't find anything. The automatic route generation breaks when you have dynamic segments with the same name in different directories.

Hot reload works great... except when it doesn't. Database schema changes should trigger type regeneration but sometimes the watcher gets stuck. You end up restarting deno task start more than you'd like.

The Supabase CLI local development is solid but the database migrations can be finicky. I've had supabase db diff miss foreign key changes and then deployment fails because the migration is incomplete.

When It All Works Together

Despite all this crap, we still shipped in 6 weeks. No webpack config, no babel setup, no Docker compose nightmare for local dev. Edge Functions deploy in seconds, database migrations usually work, and TypeScript catches most of the stupid mistakes.

Fresh forces you to think about what actually needs JavaScript, which makes your app faster. Supabase handles auth and database without the usual PostgreSQL setup hell. When everything works, it's actually pleasant to use.

Just don't expect perfection. Pin your versions, write tests for your RLS policies, and keep supabase db reset handy for when the local environment gets wedged.

Environment Setup That Actually Works

Supabase environments work fine until you try to use different database schemas between staging and prod. The CLI assumes you want the same schema everywhere, which breaks when you're testing migrations.

Here's a deno.json that works in production:

{
  "compilerOptions": {
    "lib": ["deno.window", "deno.unstable"],
    "strict": true
  },
  "imports": {
    "@supabase/supabase-js": "https://esm.sh/@supabase/supabase-js@2",
    "@supabase/functions-js": "https://esm.sh/@supabase/functions-js@2"
  },
  "tasks": {
    "start": "deno run -A --watch=static/,routes/ dev.ts",
    "build": "deno run -A dev.ts build",
    "deploy": "deployctl deploy --project=your-project --entrypoint=main.ts"
  }
}

Pin major versions but let minor updates through - breaking changes in "patch" releases have fucked me three different times. Now I always test imports after updates because I'm not an idiot anymore. Our file upload broke after what should have been a tiny 2.1.3 → 2.1.4 version bump and I spent 2 hours debugging why FormData.append() was suddenly throwing TypeError: Cannot read properties of undefined errors.

Deno Deploy environment variables are secure but the UI is painful. You can't bulk import them and there's no API yet. Plan to spend 20 minutes clicking through forms if you have more than 10 env vars.

Database Migrations (Where Everything Goes to Shit)

Supabase migrations work fine until they don't. supabase db diff looks at your local schema and generates SQL, but it misses things constantly.

I've had it miss:

• Foreign key constraint changes (deployment fails with relation does not exist bullshit)
• Index drops (your queries suddenly take 5 seconds instead of 50ms)
• Enum type modifications (breaks existing data with invalid input value errors)

The generated migration files have timestamps but no dependency checking. Drop a table that another migration references? Good luck figuring that out at 2am when production is down.

I learned this the hard way: always run supabase db reset && supabase migration up locally. If it breaks on clean data, production is fucked.

Here's the migration workflow that actually works:

## 1. Generate migration from schema changes
supabase db diff --file migration_name

## 2. Review the generated SQL (trust but verify)
cat supabase/migrations/[timestamp]_migration_name.sql

## 3. Test on clean database
supabase db reset
supabase migration up

## 4. Deploy with monitoring
supabase db push --linked

Always add database monitoring queries after big migrations. Check your slowest queries before and after deployment - indexing problems show up immediately under load.

Edge Functions Deployment (Actually Pretty Solid)

Supabase Edge Functions are the most reliable part of this stack. They deploy in about 10 seconds and rollbacks work instantly.

The process that works:

1. Test locally with supabase functions serve (works great)
2. Deploy with supabase functions deploy --project-ref xyz
3. Check the logs immediately - errors don't show up in deployment output

The secrets management via CLI is actually good: supabase secrets set API_KEY=xxx. Much better than clicking through dashboards.

One gotcha: Edge Functions timeout at 60 seconds hard limit. No way around it. If you need longer-running tasks, use a separate service.

Fresh Deployment to Deno Deploy

Deno Deploy is surprisingly painless. Connect your GitHub repo and deployments happen automatically on push. The platform detects Fresh projects correctly.

Where it gets weird:

• Sometimes deployments hang at "Analyzing dependencies" for 5+ minutes with no timeout (had one sit there for 23 minutes before I gave up)
• No way to see build logs during deployment - it either works or fails silently with the incredibly helpful "Build failed" message
• The automatic asset optimization occasionally breaks CSS imports with Failed to resolve import "./styles.css" errors for stylesheets that definitely exist and work locally
• Import maps randomly stop working between deploys even though you changed nothing (Cannot resolve module for imports that worked 5 minutes ago)

The deployctl CLI is better for debugging. When the web UI fails, deployctl deploy usually shows you the actual error.

GitHub Actions integration works but you need to set up the deploy token carefully. The documentation skips the part where you need --project and --entrypoint flags in CI.

Monitoring (The Stuff That Matters at 3am)

Supabase Analytics shows you database queries and API calls, but the interface is slow as hell with large datasets. You'll export to CSV and analyze in a spreadsheet for anything serious.

What actually breaks in production:

• Database connection pool exhaustion (no warning, just Error: remaining connection slots are reserved)
• Edge Function memory limits hit (silent failures, functions just stop responding)
• Fresh island hydration errors (users see blank components, console shows Hydration failed)
• RLS policies that work in dev but fail with concurrent users (new row violates row-level security policy)

Deno Deploy analytics are basic but load fast. The geographic distribution data is actually useful - you'll discover users in regions you didn't expect.

I use external monitoring for everything important:

• UptimeRobot for endpoint monitoring (free tier works fine)
• Sentry for JavaScript errors (catches Fresh hydration issues)
• Simple ping script that hits your API every minute

Security (Don't Skip This Part)

Supabase security has good defaults but you need to configure it properly.

The RLS policies are where everyone fucks up. Test them with multiple user accounts - I've seen policies that work fine with one user but fail with concurrent access. The policy editor in the dashboard is helpful but slow.

CORS configuration through the Supabase dashboard works but there's a caching issue - changes take 5-10 minutes to propagate. Plan accordingly.

API rate limiting is per-project, not per-user, so one bad actor can take down your whole app. The free tier limits are pretty low (100 requests per hour per IP), but upgrading helps.

IP allowlisting is useful for admin functions but breaks edge deployment benefits. Use it sparingly.

The SOC 2 compliance is real and actually helpful for enterprise sales, but you still need to configure everything correctly.