DEV Community: Russel Dsouza

Ship a Live Demo of Your Supabase App That Runs Entirely in the Browser

Russel Dsouza — Fri, 16 Oct 2026 12:40:54 +0000

Every SaaS landing page wants a "Try the demo" button. And every developer who's built one knows the problems that come with it:

A shared demo account that strangers fill with junk (or worse) within a day
A cron job to reset the demo database every night
Real backend costs for people who will never sign up
Rate limits, abuse, and the occasional visitor who deletes everything

There's another way. Run the backend inside the visitor's browser. Each visitor gets their own private copy of your app's database, built from your migrations and seed data. Nothing is shared, nothing needs resetting, and the demo is just static files.

This guide does that for a Supabase app using tinbase, an open-source Supabase-compatible backend that can run in the browser on PGlite (Postgres compiled to WebAssembly).

tinbase is alpha. It covers a large part of the supabase-js surface, but not everything; check the known gaps in the README before relying on a specific feature for your demo.

How does it work?

Your app already talks to Supabase through supabase-js. That client accepts a custom fetch. In demo mode, instead of sending requests over the network, you hand them to a backend running in the same page:

your UI → supabase-js → backend.fetch → Postgres (PGlite, in the browser)

Your components don't change. Only the client setup does.

Step 1: Make the client switchable

Here's a Vite example. In normal mode, the app uses your real Supabase project. In demo mode, it starts an in-browser backend.

// src/lib/supabase.ts
import { createClient, type SupabaseClient } from '@supabase/supabase-js';

const DEMO = import.meta.env.VITE_DEMO === 'true';

export async function getSupabase(): Promise<SupabaseClient> {
  if (!DEMO) {
    return createClient(
      import.meta.env.VITE_SUPABASE_URL,
      import.meta.env.VITE_SUPABASE_KEY
    );
  }

  const { createDemoBackend } = await import('./demo-backend');
  const backend = await createDemoBackend();

  return createClient('http://localhost', backend.anonKey, {
    global: { fetch: (input, init) => backend.fetch(new Request(input, init)) },
  });
}

The dynamic import() matters: visitors to your real app never download the demo backend.

Step 2: Build the demo backend from your migrations

Vite can import SQL files as strings with ?raw, so the demo uses the exact same migrations as production:

// src/lib/demo-backend.ts
import { createBackend } from 'tinbase';
import init from '../../supabase/migrations/20261001000000_init.sql?raw';
import projects from '../../supabase/migrations/20261005000000_projects.sql?raw';
import demoSeed from '../../supabase/demo-seed.sql?raw';

export function createDemoBackend() {
  return createBackend({
    dataDir: 'idb://my-app-demo-v1', // persist in IndexedDB between visits
    migrations: [
      { name: '20261001000000_init', sql: init },
      { name: '20261005000000_projects', sql: projects },
      { name: '99990000000000_demo_seed', sql: demoSeed },
    ],
  });
}

A few choices here:

The demo seed runs as the last migration, so every new visitor starts with the same realistic sample data.
dataDir: 'idb://...' keeps the visitor's changes in IndexedDB, so the demo survives a page refresh. Bump the name (-v2) when you change the seed, and returning visitors get a fresh copy.
If you'd rather every visit start clean, leave persistence out. Check the README for the current in-memory option.

Step 3: Sign the visitor in automatically

A demo shouldn't ask for an email. Anonymous sign-in gives each visitor a real authenticated user, so your RLS policies work exactly as they do in production:

const supabase = await getSupabase();

if (import.meta.env.VITE_DEMO === 'true') {
  const { data } = await supabase.auth.getSession();
  if (!data.session) await supabase.auth.signInAnonymously();
}

If your seed data needs to belong to the visitor, assign it after sign-in, or write your seed to use rows that any authenticated user can read.

Step 4: Build and host it as static files

VITE_DEMO=true npm run build

Deploy the output folder to any static host (GitHub Pages, Netlify, Vercel, Cloudflare Pages) at something like demo.yourapp.com. There's no server, no database, and no bill that grows with demo traffic.

Step 5: Make it obvious it's a demo

Visitors should know their data stays on their device and isn't saved to a real account. Add a small banner:

{import.meta.env.VITE_DEMO === 'true' && (
  <div className="demo-banner">
    Demo mode: everything runs in your browser and stays on this device.
    <a href="https://yourapp.com/signup">Create a real account</a>
  </div>
)}

That banner is also your conversion point: someone who just spent five minutes in a working app is a much warmer lead than someone who watched a video.

What are the trade-offs?

Be honest with yourself about these before shipping:

Download size. WASM Postgres adds several megabytes to the demo build. Lazy-load it, and show a short loading state ("Setting up your demo…").
Memory. WASM Postgres is memory-hungry. Test on an older phone and a low-end laptop.
Feature coverage. Features your app uses that tinbase doesn't support yet (see the README's known gaps, such as MFA, phone auth, or image transforms) need to be hidden or stubbed in demo mode.
No server-side logic. Anything that depends on third-party APIs, emails, or payments should be faked or disabled in the demo.
Not for production. This is a demo and prototyping technique. Your real app keeps using your real Supabase project.

When is this a good fit?

Dashboards, CRUD tools, internal-tool templates, and productivity apps where the value is obvious once someone clicks around
Template or boilerplate products where buyers want to try before they buy
Conference demos and workshops where Wi-Fi can't be trusted

It's a weaker fit for apps whose value depends on other users (social, messaging) or heavy server-side processing.

Wrapping up

A browser-only demo removes the worst parts of "Try the demo": no shared account to vandalize, no nightly reset job, and no backend cost per visitor. Your migrations build the database, anonymous auth signs the visitor in, and your real RLS policies keep working.

Source, benchmarks, and known gaps: tinbase on GitHub. Have you built a "try it now" demo for your app? How did you handle the shared-data problem? Tell me in the comments.

Your EXPO_PUBLIC_ Keys Are Public: A Practical Guide to EAS Environment Variables

Russel Dsouza — Thu, 15 Oct 2026 11:23:04 +0000

Open almost any Expo repo and you'll find a .env file with a mix of things: an API URL, a Supabase key, a Sentry DSN, maybe a Stripe secret key someone added "just for testing."

Some of those are safe to ship inside your app. Some are not. And the EXPO_PUBLIC_ prefix doesn't make anything private. It does the opposite.

This guide sorts it out: which values can go where, how EAS environments and visibility levels work, and one easy-to-miss mistake with OTA updates.

The one rule: anything in the app is public

Every EXPO_PUBLIC_ variable is inlined into your JavaScript bundle at build time. Anyone who downloads your app can extract it. The Expo docs say it plainly: treat client-side code as public, and secret visibility in EAS "does not provide any additional security for values that you end up embedding in your application itself."

So the first question for every variable isn't "how do I hide it?" It's "does the app actually need this?"

Sort every value into one of three buckets

Bucket	Examples	Where it lives
Public, used at runtime	API base URL, Supabase URL and publishable key, Sentry DSN, PostHog project key	`EXPO_PUBLIC_*`
Build-time only	`APP_VARIANT`, bundle ID suffix, `GOOGLE_SERVICES_JSON` file, Sentry auth token for source maps	Non-prefixed EAS variable, read in `app.config.js` or by build tools
Server only	Stripe secret key, Supabase secret/service key, OpenAI key, webhook secrets	Your backend or edge functions. Never the app.

If a key can spend money, read every user's data, or call a paid API, it belongs in the third bucket. The app calls your server, and your server holds the key.

A quick test: if this value leaked on Twitter tomorrow, would you need to rotate it? If yes, it can't be EXPO_PUBLIC_.

How EAS environments work

EAS gives each project three environments by default: development, preview, and production. Each is an independent set of variables, and a variable can belong to one environment or several.

Create variables with eas env:set (it creates or updates):

eas env:set --name EXPO_PUBLIC_API_URL \
  --value https://api.staging.example.com \
  --environment preview --visibility plaintext

eas env:set --name EXPO_PUBLIC_API_URL \
  --value https://api.example.com \
  --environment production --visibility plaintext

Check what's set:

eas env:list --environment production

Pick the right visibility

Visibility	Who can read it	Use for
Plain text	Dashboard, CLI, build logs	`EXPO_PUBLIC_*` values (they're public anyway)
Sensitive	CLI and dashboard (toggle); hidden in logs	Build-time values you need to resolve locally
Secret	Only EAS servers; hidden everywhere else	Tokens only the build needs, like a source-map upload token

Two details catch people out:

Secret variables can't be pulled. eas env:pull skips them, and resolving app.config.js locally needs at least sensitive visibility. If your config reads a variable on your laptop, don't make it secret.
Secret doesn't make an EXPO_PUBLIC_ value private. It hides it in the dashboard, but the value still ships in the bundle.

Connect build profiles to environments

In eas.json, each build profile picks its environment:

{
  "build": {
    "development": {
      "developmentClient": true,
      "environment": "development"
    },
    "preview": {
      "distribution": "internal",
      "environment": "preview"
    },
    "production": {
      "environment": "production"
    }
  }
}

Now eas build --profile preview gets the staging API URL, and --profile production gets the real one, with no .env juggling.

Use build-time variables in app.config.js

Non-prefixed variables are available in app.config.js, which is perfect for running preview and production builds side by side on one phone:

// app.config.js
const variant = process.env.APP_VARIANT ?? 'development';
const suffix = variant === 'production' ? '' : `.${variant}`;

export default {
  name: variant === 'production' ? 'Acme' : `Acme (${variant})`,
  ios: { bundleIdentifier: `com.acme.app${suffix}` },
  android: {
    package: `com.acme.app${suffix}`,
    googleServicesFile:
      process.env.GOOGLE_SERVICES_JSON ?? './google-services.json',
  },
};

Set APP_VARIANT per environment in EAS. Upload google-services.json as a file variable, and the fallback keeps local builds working.

Pull variables for local development

eas env:pull --environment development

This writes the readable variables to a .env file (like .env.local). Add it to .gitignore. The dashboard and EAS become the source of truth, and nobody pastes keys into Slack again.

The OTA mistake: updates read the environment too

Here's the one that bites teams in production.

EXPO_PUBLIC_ values are baked into the JavaScript bundle. An OTA update ships a new bundle, so it gets whatever environment you publish it with:

eas update --channel production --environment production

Publish a production update with the wrong environment, and every production user's app now points at your staging API. The native build was fine; the update replaced the config.

Guard against it:

Always pass --environment explicitly, and match it to the channel.
Put the command in a package script or an EAS Workflow so nobody types it by hand:

{
  "scripts": {
    "update:preview": "eas update --channel preview --environment preview",
    "update:prod": "eas update --channel production --environment production"
  }
}

Log the API base URL on startup in preview builds, so a mismatch shows up in QA, not in support tickets.

A 10-minute audit for your project

[ ] Search the codebase for EXPO_PUBLIC_ and check each one against the three buckets
[ ] Move any secret key out of the app and behind your backend, then rotate it (it has already shipped)
[ ] Use plaintext for EXPO_PUBLIC_*, sensitive for build values you resolve locally, and secret for build-only tokens
[ ] Set environment on every build profile in eas.json
[ ] Make sure .env* files are git-ignored
[ ] Wrap eas update in scripts that always pass --environment

Wrapping up

Environment variables feel like plumbing until one leaks or an update points production at staging. The fix is mostly sorting: public runtime config in EXPO_PUBLIC_, build config in EAS variables, and real secrets on your server where users can't reach them.

If you'd rather start from a project where this is already laid out, RapidNative generates real Expo apps you can export, with config you can drop straight into this setup.

How does your team split config between the app and the server? Share your setup in the comments.

6 Best Ways to Get Your Lovable App into the App Store and Google Play (2026)

Russel Dsouza — Mon, 12 Oct 2026 12:13:29 +0000

Compared on approval risk, how native the result feels, cost, and how much work you'll do yourself

Disclosure: This article is published by LetsDeployIt, which is ranked first below. We've described every other option as fairly as we can, including when it's the better choice.

If you're a developer helping a founder (or yourself) ship a Lovable app to mobile, this is the landscape in 2026, with the trade-offs that actually matter for review.

You built something real with Lovable. It works, people like it, and now they're asking the inevitable question: "Is it in the App Store?"

Here's the catch most people hit first: Lovable builds web apps, not mobile apps. Its own FAQ says it doesn't generate React Native projects, and it suggests two routes to phones: turn your app into a Progressive Web App, or wrap your published URL with a tool like Capacitor and submit that to the stores.

Those aren't your only options, though. Below are six ways to get a Lovable app onto iPhones and Android phones, ranked for the most common goal: a real app in both stores, that passes review, without rebuilding everything yourself.

The quick comparison

#	Option	What you get	App Store approval risk	Your effort	Best for
1	LetsDeployIt	Native React Native rebuild + full submission	Low	Very low	Founders who want a real app, done for them
2	Median.co	Web app in a native shell, plus native plugins	Medium	Low to medium	Apps that can stay web-based inside
3	Capacitor (DIY)	Web app in a native shell you configure	Medium to high	High	Developers who want full control
4	Rebuild yourself with an AI coding tool	Native React Native app you build	Low (if done well)	High	Developers with time and mobile experience
5	Hire a freelancer	Depends on the freelancer	Varies	Medium	Teams with budget and a trusted hire
6	Progressive Web App	Installable website, not in the stores	N/A	Very low	Testing demand before going native

Why "just wrap it" isn't always enough

Before the list, one rule shapes everything: Apple's App Store Guideline 4.2 (Minimum Functionality). Apple rejects apps that are essentially a website repackaged in an app shell, without native, mobile-specific features.

That doesn't make every wrapped app a rejection. Wrappers that add real native features (push notifications, biometrics, offline support, device access) can and do get approved. But a wrapper with nothing added is the most common first-submission rejection for web-based apps, and that risk is why the rankings below look the way they do.

1. LetsDeployIt: native rebuild and submission, done for you

What it is: a done-for-you service that rebuilds your Lovable app as a real native app (React Native and Expo, not a WebView) and submits it to both stores.

How it works:

Bring your Lovable project. Upload the project file or connect GitHub. With GitHub, the mobile app can stay in sync as you keep changing things in Lovable.
It's rebuilt as a native app. Screens, navigation, and gestures are native. Your Supabase backend (database, sign-in, and data) stays exactly as it is, so web and mobile users share the same accounts.
Preview it on your phone for free before you pay anything.
Store submission is handled: certificates and signing, screenshots, privacy labels, Google's Data Safety form, and the review back-and-forth.
You own it. The app is published under your own Apple and Google developer accounts.

Why it's #1: it's the only option on this list that combines a genuinely native app (the lowest Guideline 4.2 risk) with someone else doing the store work. For most founders, the hard part isn't the code; it's the certificates, forms, testers, and rejections. This handles both halves.

Watch out for: you'll still need your own developer accounts ($99 per year for Apple, $25 once for Google), and a rebuild takes longer than wrapping a URL. If you just need something in the store this week and approval risk doesn't worry you, a wrapper is faster.

Best for: non-technical founders, and anyone who wants real users finding them in the App Store without spending weeks on mobile tooling.

→ Preview your Lovable app as a native app, free

2. Median.co: a native shell with plugins

What it is: Median wraps your published Lovable URL inside native iOS and Android shells, then adds device features through a plugin library.

Strengths:

No code changes. You paste your URL and configure the app.
Native features through plugins: push notifications, haptics, biometric login, deep links, and in-app purchases through a RevenueCat plugin.
Automated store setup after you connect your Apple developer account.
Pricing: self-serve plans start at $179 per year, with managed tiers above that.

Watch out for: your app's screens are still your website, so scrolling, buttons, and transitions feel web-like. Median's own guidance is that you need to add enough native functionality to make the case under Guideline 4.2, so plan to use the plugins rather than shipping the URL as-is.

Best for: apps where the web experience is good enough and you mainly need store presence plus a few native features.

3. Capacitor: wrap it yourself

What it is: an open-source tool that packages a web app into native iOS and Android projects. It's the option Lovable's own FAQ names.

Strengths:

Free and open source.
Full control over the native projects, with plugins for device features.
Keeps your existing code.

Watch out for: you do everything yourself: Xcode and Android Studio setup, signing, store listings, privacy forms, and rejections. And the same Guideline 4.2 risk as any wrapper applies, so budget time for adding genuinely native features.

Best for: developers who are comfortable with native tooling and want to own every detail.

4. Rebuild it yourself with an AI coding tool

What it is: recreate your app's screens in React Native and Expo using a coding agent like Claude Code or Cursor, keeping your Supabase backend.

Strengths:

Truly native, with the lowest approval risk when done well.
Your Lovable app is the spec. Every screen and flow is already defined, which speeds up the rebuild.
No service fees.

Watch out for: it's real engineering work. Agents are fast at screens but often miss what reviewers check: permission messages, empty and error states, account deletion, privacy manifests, and in-app purchases. And you still own the whole store submission.

Best for: developers with mobile experience and time to spare.

5. Hire a freelancer

What it is: pay a developer (on Upwork, Fiverr, or similar) to convert and publish your app.

Strengths: a human handles it, and a good freelancer brings experience with review.

Watch out for: quality varies enormously. Many "Lovable to App Store" gigs are wrappers, which brings back the 4.2 risk. Before hiring, ask:

Will it be a native rebuild or a WebView wrapper?
Will the app be published under my developer accounts?
Do I get the full source code?
What happens if Apple rejects it?

Best for: teams with budget and a freelancer they already trust.

6. Turn it into a Progressive Web App

What it is: make your Lovable app installable from the browser. Users tap "Add to Home Screen," and it opens full screen with an icon. Lovable's FAQ lists this as an option.

Strengths: free, immediate, no review, no developer accounts.

Watch out for: it isn't in the App Store or Google Play, so nobody finds you there. Many users never discover "Add to Home Screen," and you can't sell in-app purchases.

Best for: validating demand before you invest in a store app.

How to choose

"I want a real app in both stores, and I don't want to do the mobile work." → LetsDeployIt
"My web app is good enough on phones; I just need store presence." → Median
"I'm a developer and want full control." → Capacitor, or a rebuild with an AI coding tool
"I'm not sure anyone will use it yet." → Start with a PWA, then move to a native app

What will it cost?

Option	Upfront cost	Ongoing cost	Your time
LetsDeployIt	Free preview, then a one-time service fee	Store fees only	A few hours of review and approvals
Median.co	From $179/year (self-serve)	Yearly plan + store fees	A few days
Capacitor (DIY)	Free	Store fees	Days to weeks
Rebuild with an AI tool	Free (tool subscriptions aside)	Store fees	Weeks
Freelancer	Varies widely	Varies	A few hours of managing
PWA	Free	None	Hours

Store fees for every store option: $99 per year for Apple, $25 once for Google.

Before you start: a 5-minute checklist

Whatever you choose, do these today. They take longer than you'd expect, and none of them depend on which option you pick.

[ ] Create your Apple Developer and Google Play accounts (identity checks can take days)
[ ] Write down every service your app uses (Supabase, analytics, payments) and what data each collects; you'll need this for the privacy forms
[ ] Make sure users can delete their account inside the app
[ ] Create a demo account with sample data for reviewers
[ ] If you have a new personal Google Play account, line up 15 to 20 people willing to test for two weeks (Google requires at least 12)

What every option still requires

Whichever route you pick, the stores ask for the same things:

An Apple Developer account ($99 per year) and a Google Play developer account ($25 one time)
A privacy policy at a public URL that matches what your app collects
Apple's privacy details and Google's Data Safety form
Account deletion inside the app, if users can sign up
Screenshots that show the real app
A demo account so reviewers can get past your sign-in screen
For new personal Google Play accounts: a closed test with at least 12 testers for 14 days before the app can go public

Frequently asked questions

Can Lovable publish to the App Store directly?
No. Lovable builds web apps and doesn't generate native mobile projects. You need one of the routes above.

Will Apple reject a wrapped Lovable app?
Not always, but it's a real risk. Apple's Guideline 4.2 targets apps that are just a website in a shell. Wrappers that add meaningful native features have a better chance.

Do I lose my Supabase backend if I rebuild natively?
No. A native rebuild replaces the screens, not the backend. Your database, sign-in, and data can stay exactly as they are.

How long does it take to get into the stores?
For brand-new accounts, plan on two to four weeks from start to live. Google's 14-day closed test for new personal accounts is often the longest single step.

Who owns the app?
Make sure it's published under your developer accounts, whichever option you choose. If someone else's account owns the listing, you don't fully own your app.

Ready to turn your Lovable app into a real iOS and Android app? Preview yours free with LetsDeployIt.

What route did you take with your Lovable app? Drop it in the comments, especially if you've been through Guideline 4.2.

The Supabase Edge Functions Testing Playbook: Unit, Auth, Webhooks, and Local Integration Tests

Russel Dsouza — Thu, 08 Oct 2026 15:19:11 +0000

Most Supabase Edge Functions get tested exactly once: by deploying them and hitting them from the app. That works until a function sends a duplicate charge, emails the wrong user, or quietly returns 500 for anyone who isn't signed in.

Edge Functions are where your app's most sensitive logic tends to live: payments, AI calls with secret keys, webhooks, anything that needs the service role. They deserve better tests than "it worked when I clicked it."

This is a practical playbook: how to structure functions so they're testable, and the five kinds of tests that catch the bugs that matter. Everything here works with the standard Supabase CLI. At the end there's a lighter local option if Docker is slowing your loop down.

Step 0: Split the handler from the server

Almost every Edge Function example puts everything inside Deno.serve:

Deno.serve(async (req) => {
  // 80 lines of logic
});

That's hard to test, because the only way to run the logic is to start a server. Split it into two files instead:

// supabase/functions/summarize/handler.ts
import { createClient, type SupabaseClient } from 'jsr:@supabase/supabase-js@2';

export type Deps = {
  // Everything that talks to the outside world is injectable
  makeUserClient: (authHeader: string) => SupabaseClient;
  summarize: (text: string) => Promise<string>;
};

export function makeHandler(deps: Deps) {
  return async (req: Request): Promise<Response> => {
    if (req.method !== 'POST') {
      return new Response('Method not allowed', { status: 405 });
    }

    const auth = req.headers.get('Authorization');
    if (!auth) return new Response('Unauthorized', { status: 401 });

    let body: { noteId?: string };
    try {
      body = await req.json();
    } catch {
      return Response.json({ error: 'Invalid JSON' }, { status: 400 });
    }
    if (!body.noteId) {
      return Response.json({ error: 'noteId is required' }, { status: 400 });
    }

    // A client acting as the caller, so RLS decides what they can read
    const supabase = deps.makeUserClient(auth);
    const { data: note, error } = await supabase
      .from('notes')
      .select('body')
      .eq('id', body.noteId)
      .single();

    if (error || !note) {
      return Response.json({ error: 'Not found' }, { status: 404 });
    }

    const summary = await deps.summarize(note.body);
    return Response.json({ summary });
  };
}

// supabase/functions/summarize/index.ts
import { createClient } from 'jsr:@supabase/supabase-js@2';
import { makeHandler } from './handler.ts';

const url = Deno.env.get('SUPABASE_URL')!;
const key = Deno.env.get('SUPABASE_PUBLISHABLE_KEY') ?? Deno.env.get('SUPABASE_ANON_KEY')!;

Deno.serve(
  makeHandler({
    makeUserClient: (authHeader) =>
      createClient(url, key, { global: { headers: { Authorization: authHeader } } }),
    summarize: async (text) => {
      const res = await fetch('https://api.example-ai.com/v1/summarize', {
        method: 'POST',
        headers: {
          Authorization: `Bearer ${Deno.env.get('AI_API_KEY')}`,
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({ text }),
      });
      if (!res.ok) throw new Error(`AI provider returned ${res.status}`);
      return (await res.json()).summary;
    },
  })
);

Now the logic is a plain function from Request to Response, with its dependencies passed in. You can call it directly in a test, with fakes, in milliseconds.

Two details in the handler are worth copying into every function:

The user client forwards the caller's Authorization header. Queries then run as that user, and your RLS policies apply. Reach for the service role only when the function genuinely needs to bypass RLS.
Every bad input returns a specific status code. 400 for a bad body, 401 for no auth, 404 when RLS hides the row. Tests can assert on these, and your app can handle them.

Test 1: Unit tests (no server, no database)

Supabase recommends putting function tests in supabase/functions/tests/, named after the function with a -test.ts suffix. Unit tests call the handler directly:

// supabase/functions/tests/summarize-test.ts
import { assertEquals } from 'jsr:@std/assert';
import { makeHandler } from '../summarize/handler.ts';

// A fake Supabase client that returns whatever row you give it
function fakeClient(row: { body: string } | null) {
  return {
    from: () => ({
      select: () => ({
        eq: () => ({
          single: async () => (row ? { data: row, error: null } : { data: null, error: { message: 'not found' } }),
        }),
      }),
    }),
  } as any;
}

const post = (body: unknown, auth = 'Bearer test-token') =>
  new Request('http://localhost/summarize', {
    method: 'POST',
    headers: { Authorization: auth, 'Content-Type': 'application/json' },
    body: JSON.stringify(body),
  });

Deno.test('returns a summary for a readable note', async () => {
  const handler = makeHandler({
    makeUserClient: () => fakeClient({ body: 'long text' }),
    summarize: async () => 'short text',
  });

  const res = await handler(post({ noteId: 'n1' }));
  assertEquals(res.status, 200);
  assertEquals(await res.json(), { summary: 'short text' });
});

Deno.test('rejects requests without auth', async () => {
  const handler = makeHandler({
    makeUserClient: () => fakeClient(null),
    summarize: async () => '',
  });

  const req = new Request('http://localhost/summarize', { method: 'POST', body: '{}' });
  assertEquals((await handler(req)).status, 401);
});

Deno.test('returns 404 when RLS hides the note', async () => {
  const handler = makeHandler({
    makeUserClient: () => fakeClient(null),
    summarize: async () => 'should not be called',
  });

  assertEquals((await handler(post({ noteId: 'someone-elses' }))).status, 404);
});

Deno.test('validates the body', async () => {
  const handler = makeHandler({
    makeUserClient: () => fakeClient(null),
    summarize: async () => '',
  });

  assertEquals((await handler(post({}))).status, 400);
});

Run them:

deno test --allow-all supabase/functions/tests/

These run in well under a second and cover the logic you're most likely to break: validation, auth, not-found handling, and the happy path.

What to unit test in every function:

[ ] Wrong HTTP method → 405
[ ] Missing auth → 401
[ ] Invalid or missing body fields → 400
[ ] Row hidden by RLS → 404, and the expensive call (AI, payment) is not made
[ ] External API failure → a clear error, not an unhandled exception
[ ] Happy path → correct response shape

That fifth one deserves its own test:

Deno.test('surfaces AI provider failures cleanly', async () => {
  const handler = makeHandler({
    makeUserClient: () => fakeClient({ body: 'text' }),
    summarize: async () => { throw new Error('AI provider returned 503'); },
  });

  const res = await handler(post({ noteId: 'n1' }));
  // Decide what you want here and pin it down: 502 is a reasonable choice
  assertEquals(res.status >= 500, true);
});

Writing this test will probably make you add a try/catch around the external call, which is the point.

Test 2: Auth and JWT behavior

By default, Supabase verifies the JWT on every function request before your code runs. You can turn that off per function in supabase/config.toml:

[functions.stripe-webhook]
verify_jwt = false

Turn it off only for functions called by third parties (webhooks) or genuinely public endpoints, and then verify the caller yourself: a webhook signature, a shared secret header, or similar.

For functions that keep JWT verification on, test both sides against a running local backend:

An anonymous request returns 401.
A signed-in user can reach their own data.
User A can't reach user B's data through the function. This is where forwarding the Authorization header pays off: RLS does the work, and your test proves it.

Test 3: Webhook-triggered functions

Database webhooks call your function with a fixed payload shape: type, table, schema, record, and old_record. Save real payloads as fixtures and unit-test against them:

// supabase/functions/tests/fixtures/order-insert.json
{
  "type": "INSERT",
  "table": "orders",
  "schema": "public",
  "record": { "id": "o1", "user_id": "u1", "total_cents": 4200, "status": "paid" },
  "old_record": null
}

Deno.test('sends a receipt for paid orders only', async () => {
  const sent: string[] = [];
  const handler = makeOrderHandler({ sendReceipt: async (id) => { sent.push(id); } });

  const payload = JSON.parse(await Deno.readTextFile(
    new URL('./fixtures/order-insert.json', import.meta.url)
  ));

  await handler(new Request('http://localhost', { method: 'POST', body: JSON.stringify(payload) }));
  assertEquals(sent, ['o1']);
});

Add fixtures for the cases that cause real incidents: an UPDATE where the status didn't change (no duplicate receipt), a DELETE (where record is null), and the same payload delivered twice. Webhooks can retry, so make handlers idempotent and test it.

Test 4: Secrets and environment

Locally, put function secrets in supabase/functions/.env (and add it to .gitignore), or pass a file with --env-file when serving. In production, set them with:

supabase secrets set --env-file ./supabase/functions/.env.production
supabase secrets list

Two tests worth having:

The function fails loudly if a required secret is missing. Read secrets at startup and throw a clear error, rather than discovering undefined in a request to your AI provider.
Secrets never reach the response. A test that serializes every error response and asserts it doesn't contain your key catches the classic return Response.json({ error }) leak.

Test 5: Integration tests against a local backend

Unit tests prove the logic. Integration tests prove the wiring: the real supabase-js client, real JWTs, real RLS, the real function runtime.

The standard way is the Supabase CLI:

supabase start
supabase functions serve --env-file ./supabase/functions/.env

Then invoke through the client, exactly as your app does:

import { createClient } from 'jsr:@supabase/supabase-js@2';
import { assertEquals } from 'jsr:@std/assert';

const supabase = createClient(
  Deno.env.get('SUPABASE_URL') ?? 'http://127.0.0.1:54321',
  Deno.env.get('SUPABASE_PUBLISHABLE_KEY') ?? Deno.env.get('SUPABASE_ANON_KEY')!,
  { auth: { persistSession: false } }
);

Deno.test('anonymous callers are rejected', async () => {
  const { error } = await supabase.functions.invoke('summarize', { body: { noteId: 'x' } });
  assertEquals(error !== null, true);
});

Sign a test user in first to test the authenticated paths.

A lighter local option

supabase start runs a dozen Docker containers, roughly 1.4 GB of RAM on a Mac, and takes about a minute to boot. If that's what keeps you from running integration tests on every change, tinbase is an open-source alternative that runs a Supabase-compatible backend in one process, with no Docker, in about two seconds.

npx tinbase start

It loads functions from supabase/functions/<name>/index.ts, and functions written with Deno.serve(handler) and Deno.env run unchanged, so supabase.functions.invoke() works against it. It also runs database webhooks with the same payload shape and emulates pg_cron and pg_net, so a "cron job calls a function" flow can be exercised end to end.

Be aware of the trade-offs before you switch:

Imports: functions that use npm:, jsr:, or URL imports need to be bundled first. Functions using only web APIs run as-is.
Maturity: tinbase is alpha, built for local development and CI, not production.
Parity: run your integration suite against the real Supabase CLI before deploying.

A common setup is tinbase for the fast inner loop and every pull request, and the Supabase CLI in a nightly or pre-deploy job.

Putting it in CI

# .github/workflows/functions.yml
name: Edge Functions
on:
  pull_request:
    paths: ['supabase/functions/**']

jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: denoland/setup-deno@v2
        with: { deno-version: v2.x }
      - run: deno test --allow-all supabase/functions/tests/

Unit tests need nothing but Deno, so they run in seconds on every pull request. Add the integration job (with the Supabase CLI or tinbase) once the unit layer is solid.

The checklist

Structure

[ ] Logic lives in handler.ts; index.ts only wires dependencies and calls Deno.serve
[ ] External calls (AI, payments, email) are injected, so tests can fake them

Unit tests

[ ] Method, auth, and body validation return the right status codes
[ ] RLS-hidden rows return 404 and skip expensive calls
[ ] External failures are handled, not thrown
[ ] Webhook handlers are idempotent, tested with saved fixtures

Security

[ ] User clients forward the Authorization header; service role only when needed
[ ] verify_jwt = false only where you verify the caller another way
[ ] Missing secrets fail at startup; secrets never appear in responses

Integration

[ ] Anonymous, own-data, and other-user's-data cases tested through functions.invoke
[ ] Runs on every pull request that touches supabase/functions/

Edge Functions hold the code you least want to break. An hour spent splitting handlers and writing these tests pays for itself the first time it stops a duplicate charge from reaching production.

What's the bug your Edge Function tests would have caught? I'd like to collect them.

How to Run a Supabase Workshop for 30 People Without a Single Docker Install

Russel Dsouza — Wed, 30 Sep 2026 07:02:02 +0000

If you've ever taught a backend workshop, you know the first 40 minutes. Someone's Docker Desktop won't start. Someone's on an 8 GB laptop and the Supabase stack won't fit. Someone's corporate machine blocks virtualization. Someone's on Windows Home. By the time everyone has supabase start running, you've lost a third of the session and most of the room's energy.

I've run enough of these to want a setup where the whole room has real Postgres with Row Level Security in under two minutes, no Docker anywhere. This is that setup, using tinbase, an open-source, Supabase-compatible backend that runs as one process.

What every student needs installed

Node.js. That's the list.

npx tinbase start

That boots embedded native Postgres 17 (macOS and Linux) with REST, Auth, Storage, Realtime, Edge Functions, and a Studio-style dashboard at http://localhost:54321/_/. About two seconds to boot, about 59 MB of RAM. The official @supabase/supabase-js works unchanged, and it reads the same supabase/migrations/*.sql files the Supabase CLI uses.

On Windows, or if native Postgres can't run for any reason, the same command works with the WASM engine (PGlite):

npx tinbase start --engine wasm

Slower, heavier on memory, but still real Postgres and still no Docker.

The workshop repo structure

Give students one repo with the schema and seed data already written, so the session is about using Supabase, not typing create table:

workshop/
  supabase/
    migrations/
      20260101000000_init.sql
    seed.sql
  app/                 # the frontend (Expo, Next.js, plain HTML, whatever you teach)
  README.md            # "npm install && npx tinbase start"

-- supabase/migrations/20260101000000_init.sql
create table public.posts (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references auth.users(id) on delete cascade,
  title text not null,
  body text,
  created_at timestamptz not null default now()
);

alter table public.posts enable row level security;

create policy "read all posts" on public.posts
  for select to authenticated using (true);

create policy "write own posts" on public.posts
  for insert to authenticated with check ((select auth.uid()) = user_id);

create policy "edit own posts" on public.posts
  for update to authenticated using ((select auth.uid()) = user_id);

Every student gets the same database, the same policies, the same seed rows. When someone's exercise breaks, you know it's their code, not their environment.

Exercise 1: the RLS "aha" moment

This is the exercise that makes RLS click, and it only works if every student has their own database with two users in it.

Have each student sign up twice in the app (two emails), create a post as each, then run:

const { data } = await supabase.from('posts').select('*');

as user A. They see both posts, because the read policy is using (true). Then have them try to update user B's post as user A. Zero rows change. No error. Just nothing.

Then have them change the read policy to using ((select auth.uid()) = user_id), re-run the migration, and watch user B's post disappear from A's query.

That five-minute loop teaches more about RLS than an hour of slides. It needs a database each student can break and reset without asking you.

Reset is one command

When someone's database is in a weird state (and someone's always is):

npx tinbase start --memory

In-memory mode boots a fresh database from the migrations and seed every time. Nothing persists, nothing to clean up, and it's the right default for a workshop anyway: students should be able to blow it away and start over in two seconds.

Exercise 2: realtime, in a room full of laptops

Realtime demos usually need a shared server so students see each other's changes. Here's a trick that avoids that: pair students up, and have one of them run tinbase on a port the other can reach on the venue Wi-Fi:

npx tinbase start --port 54321

The partner points their app at http://<partner-ip>:54321. Now two laptops share one database, and a postgres_changes subscription on one shows inserts from the other. Real realtime, no cloud project, no shared credentials to leak.

Exercise 3: an Edge Function that holds a secret

Give students an API key they aren't allowed to put in the client. Have them write supabase/functions/summarize/index.ts, call it with supabase.functions.invoke('summarize'), and confirm the key never appears in the browser's network tab. Plain functions run in-process with no extra setup; functions that use npm: or jsr: imports need bundling first, so keep the exercise dependency-free.

What to tell students about the limits

Be straight with the room, because they'll ask:

tinbase is alpha, built for local dev, CI, prototypes, and teaching. Not production.
It covers roughly 80% of the supabase-js surface. MFA, SSO, phone auth, and pgvector aren't there yet.
Writes go through a single connection, so it's for one person (or one pair), not a class-wide shared server.
The migration files are the same ones they'll deploy to hosted Supabase. That's the point: nothing they learn today changes when they get a real project.

The wrap-up slide

Before the session ends, have everyone create a free hosted Supabase project and run:

supabase db push

against the same supabase/migrations/ folder. The schema and RLS policies they wrote locally are now live in the cloud, unchanged. Students leave with a working backend they built, not a tutorial they followed.

Try it before your next session

npx tinbase start

Source and the coverage table are on GitHub. If you teach with it, I'd like to hear what broke and what landed; workshop feedback is some of the most useful we get.

Every Way to Run Postgres for Local Dev in 2026, Ranked by Weight

Russel Dsouza — Wed, 23 Sep 2026 05:54:51 +0000

"Just run Postgres locally" hides a real decision. In 2026 there are four genuinely different ways to do it, and they differ by two orders of magnitude in weight. Picking wrong doesn't break anything; it just quietly taxes every git clone, every CI run, and every laptop on the team for the life of the project.

Here they are, lightest to heaviest, with the honest trade-offs.

1. Embedded: PGlite (~3 MB)

The newest option and the lightest by far. PGlite is Postgres compiled to WebAssembly, packaged as a library. You don't start a database, you import one:

import { PGlite } from '@electric-sql/pglite'

const db = new PGlite()            // in-memory
// const db = new PGlite('./data') // or persisted to disk
await db.query("select 'hello' as message")

Under 3 MB gzipped, starts in milliseconds, persists to the filesystem or IndexedDB, and supports real extensions including pgvector. This stopped being a curiosity a while ago: it crossed 10 million weekly npm downloads this year, and Prisma, Firebase, and Netlify all ship it as the local engine behind their database products.

Where it wins: test suites (a fresh, real Postgres per test, no containers in CI), instant onboarding, browser playgrounds, coding-agent sandboxes, any environment where Docker isn't available.

Where it doesn't: it's single-connection and single-user. No replication, not a production database, and tools that expect a TCP connection string need an adapter. It's a library, and everything that implies cuts both ways.

2. Native install (~50 to 300 MB)

Homebrew, apt, or Postgres.app. The old way, and still the fastest raw Postgres you can run, since there's no VM and no container layer.

Where it wins: one long-lived database you use daily, maximum performance, lowest conceptual overhead.

Where it doesn't: one global version for the whole machine. Two projects on different Postgres majors means version-manager gymnastics. It pollutes the host, upgrades are a small ritual, and "install Postgres 16 locally" is the onboarding step that fails differently on every teammate's laptop.

3. Docker (~400 MB image, plus the runtime)

The default answer of the last decade. docker compose up, one isolated Postgres per project, any version you like, throw it away when you're done.

Where it wins: version isolation per project, parity with a containerized production setup, and the whole team runs the identical environment from one committed file.

Where it doesn't: the real cost isn't the image, it's the runtime. Docker Desktop idles at gigabytes of RAM on Mac and Windows, licensing applies at larger companies, CI needs service containers with health checks and port juggling, and there are environments (locked-down laptops, cloud IDEs, agent sandboxes) where it simply can't run. You're running a VM to get a process.

4. Cloud dev branches (0 MB local, network required)

Neon-style branching, or your platform's preview databases: every PR gets its own copy-on-write database in the cloud, nothing on your machine.

Where it wins: production-identical infrastructure, instant branches with real data shapes, zero local footprint, great for review apps.

Where it doesn't: no network, no database. Every query pays a round trip, tests share remote state unless you're disciplined about branching, and it's the only option on this list with a monthly bill. It complements a local option more than it replaces one.

The cheat sheet

Use case	Pick
Unit and integration tests	PGlite (fresh DB per test)
CI pipelines	PGlite, or Docker service containers if you need TCP
One daily-driver database	Native install
Multiple projects, multiple versions	Docker
Matching containerized prod	Docker
PR preview environments	Cloud branches
Demos, workshops, browser sandboxes	PGlite

Most teams end up with two: something heavy for prod parity, something feather-weight for the inner loop. That split is the point. The 200 iterations a day don't need the faithful production copy; the last check before deploy does.

The Supabase-shaped footnote

One case the table above doesn't cover: your app doesn't talk to bare Postgres. If you build on Supabase, your client calls the platform's REST, Auth, Storage, and Realtime APIs, so a lightweight Postgres alone doesn't give you a lightweight backend. The official local stack solves it with Docker, about a dozen containers of it.

That's the gap tinbase fills: an open-source (MIT) Supabase-compatible backend that runs the whole API surface on PGlite, in one process, npx tinbase start, up in about two seconds, with the official supabase-js SDK working unchanged. Same idea as row 1 of the table, extended to the entire platform. It's alpha and aimed at local dev and tests, not production, which is exactly the inner-loop slot in the two-tier split above.

Whatever your stack, weigh the setup against how you actually spend your day. The database you iterate against should cost you nothing to start, nothing to reset, and nothing to explain in the onboarding doc.

AI App Builders in 2026: RapidNative vs Bolt vs v0 vs Lovable, an Honest Comparison

Russel Dsouza — Fri, 18 Sep 2026 10:05:38 +0000

These four tools are not four answers to one question; they're answers to different questions
v0: best-in-class React UI, no backend story
Lovable: fastest full-stack web MVP, deep Supabase wiring, web only
Bolt: browser IDE, most framework-flexible (Expo included), deployment is on you
RapidNative: mobile-first; full React Native + Expo apps with the backend wired
Disclosure up front: I work on RapidNative. The competitors' wins below are real wins.

The "AI app builder" category has exploded, and most comparisons read like feature-matrix theater. Having used all four of these for real projects (and shipping one of them), here's the honest version: each tool optimizes for a different job, and picking by hype instead of by job is how you lose a weekend.

v0 (Vercel)

v0 turns prompts into React components with shadcn/ui and Tailwind, and it produces the cleanest, most conventional UI code in the category. If you live in the Next.js/Vercel world, the design fidelity and deployment integration are genuinely excellent.

The boundary is just as clean: it's a frontend tool. No backend generation; your API routes, database, and auth are your problem. That's not a flaw, it's the product's shape.

Pick v0 when: the job is beautiful React UI inside a stack you already own.

Lovable

Lovable is the most complete prompt-to-web-app tool: frontend, Supabase database, auth, even RLS policies, wired together from a description. It's also the most accessible of the four for people who don't write code, which explains its trajectory.

The boundary: it generates web code. React for browsers, not React Native for phones. A Lovable app in a mobile webview is still a website.

Pick Lovable when: the job is a full-stack web MVP, fastest, especially if you're non-technical.

Bolt (StackBlitz)

Bolt gives you an AI pair inside a browser IDE, and it's the most framework-flexible of the group: React, Next.js, Svelte, Astro, and yes, Expo. For a technical user who wants direct code control and iteration speed in a tab, it's the strongest fit.

The mobile boundary is subtler here, and it's where I should be precise since this is my lane: Bolt can generate Expo projects, but mobile is one framework among many rather than the product's center of gravity, and getting from generated code to a store build (EAS setup, certificates, submission) is manual work it doesn't do for you.

Pick Bolt when: you're technical, want an in-browser IDE, and value flexibility across stacks.

RapidNative

Full disclosure again: this is the one I work on, so weigh accordingly.

RapidNative exists for one job: native mobile apps. Prompts, screenshots, PRDs, or sketches in; complete React Native + Expo + TypeScript projects out, with navigation, theming, and the Supabase backend wired, built as apps headed for the App Store and Play Store rather than as websites that might one day get wrapped. You export and own the code.

The honest boundaries: it's not the tool for a web SaaS (use Lovable), not a general-purpose IDE (use Bolt), and if your job is pixel-perfect web UI, v0 will out-design it. Mobile-first cuts both ways.

Pick RapidNative when: the deliverable is an iOS/Android app, not a website.

The actual decision

The category's dirty secret is that the web/mobile split matters more than any feature comparison. Almost every tool in this space builds web apps; if you're shipping to a browser, you have great options and this article barely matters. If you're shipping to the app stores, the field narrows sharply, and "supports Expo" and "built for Expo" are different products.

These tools also compose. Plenty of teams run Lovable or Bolt for their web app and RapidNative for the mobile app, same Supabase underneath. Treating this as a winner-take-all bracket is the feature-matrix brain talking.

Pricing, for completeness: all four land in the same rough $20-25/month ballpark for pro tiers as of writing, with credit systems that vary. Don't pick on price; at these numbers, one saved afternoon pays the annual difference.

The one-line version

Web UI: v0. Full-stack web, fastest: Lovable. Browser IDE with maximum flexibility: Bolt. Native mobile apps, end to end: RapidNative.

What are you building, and which of these did you end up on? Genuinely curious how the split looks in the comments, especially from anyone who's shipped with two of them.

Postgres RLS in Local Dev: The Three Silent-Fail Modes That Ship to Prod

Russel Dsouza — Wed, 16 Sep 2026 05:28:31 +0000

RLS doesn't fail loudly. A table with no policies and RLS off returns every row, to everyone, and looks like a working app
Three ways local dev hides that: migrations that never run ENABLE ROW LEVEL SECURITY, a dev connection that bypasses RLS, and views that evaluate as their owner
All three pass every test you'd write in the happy path, because the happy path is "the data shows up"
A 30-line SQL check at boot catches every one of them, in about 50ms

Row Level Security has one property that makes it different from almost every other security control: when it's not working, the app works better. More rows come back. Nothing errors. Your local dev environment looks great right up until a customer in production sees another customer's invoices.

I've now seen this ship three different ways, and the fix for all three is the same boring boot-time check. Here's each failure and then the check.

Silent-fail 1: your migrations never enabled it

RLS is off by default on every table in Postgres. CREATE TABLE gives you a table with no row security, and it stays that way until something explicitly runs:

alter table invoices enable row level security;

The Supabase dashboard's table editor does this for you. Nothing else does. If you write migrations in raw SQL, dbmate, Prisma, Drizzle, Knex, or anything that turns a schema file into DDL, you get a table with RLS off, no warning, and no policies. And a table with RLS off and no policies is a table with no access control at all.

The Prisma case is the sneakiest, because Prisma's schema language has no concept of RLS. You write:

model Invoice {
  id      String @id @default(uuid())
  userId  String
  amount  Int
}

and prisma migrate dev generates a perfectly correct CREATE TABLE with no ENABLE ROW LEVEL SECURITY. You have to add it in a hand-written migration, and remember to do it for every table, forever.

There's a second half most people miss even after they've enabled it. The table owner bypasses RLS unless you also run:

alter table invoices force row level security;

Without force, the role that created the table (often the same role your migrations run as, often the same role your app connects as in dev) walks straight through every policy.

Silent-fail 2: your dev connection can't see RLS at all

Superusers bypass RLS. Roles with the BYPASSRLS attribute bypass RLS. Table owners bypass RLS unless force is set. In a lot of local setups, the app connects as one of those.

The common version: local Postgres, connection string is postgres://postgres:postgres@localhost, the postgres role is a superuser. Every query the app makes runs with RLS silently disabled. Your seed script inserted rows for five fake users, your UI shows all five users' data when logged in as one of them, and it looks like a demo, not a leak.

In production the app doesn't connect as a superuser. It connects as authenticated through PostgREST, or as a scoped application role, and now the policies apply. If they're wrong, or missing, that's the first time anyone finds out.

You can check what you're running as right now:

select rolname, rolsuper, rolbypassrls
from pg_roles
where rolname = current_user;

If either boolean is true, RLS is decorative in this session.

The fix isn't "don't use the postgres role locally," because you need it for migrations. The fix is to run the app as the same role it runs as in prod, and only the migration step as the owner. Supabase-style stacks do this for you because the API layer always connects as anon or authenticated. Anything that hands your app a raw connection string doesn't.

Silent-fail 3: views evaluate as their owner

This one bit me after I'd fixed the first two.

Before Postgres 15, a view runs its underlying queries with the view owner's privileges, not the caller's. That's security-definer semantics, and it means RLS on the base tables is evaluated as the owner. If the owner is postgres, or the table owner, or anything with BYPASSRLS, the view returns every row regardless of who's querying it.

-- invoices has RLS enabled, forced, with a correct policy.
-- this view still leaks every row, because it runs as its owner.
create view invoice_summary as
  select user_id, sum(amount) as total
  from invoices
  group by user_id;

Postgres 15 added a way out:

create view invoice_summary
  with (security_invoker = true) as
  select user_id, sum(amount) as total
  from invoices
  group by user_id;

With security_invoker, the view runs as whoever called it and the base-table policies apply normally. On Postgres 14 or earlier there is no equivalent; you have to either not expose the view through your API layer, or replicate the policy logic inside the view's WHERE clause and hope nobody edits one without the other.

The reason this ships to prod is that the view works identically in dev and prod, and in both places it returns all the rows. The difference is only that in dev, all the rows is what you expected to see.

The 30-line boot check

None of the three failures produce an error. So produce one yourself. This runs at app boot in development and in CI, against whatever Postgres you're using locally, and refuses to start if any of the three conditions are true:

do $$
declare
  bad text;
begin
  -- 1. every table in public must have RLS enabled AND forced
  select string_agg(c.relname, ', ') into bad
  from pg_class c
  join pg_namespace n on n.oid = c.relnamespace
  where n.nspname = 'public'
    and c.relkind = 'r'
    and (not c.relrowsecurity or not c.relforcerowsecurity);
  if bad is not null then
    raise exception 'RLS not enabled+forced on: %', bad;
  end if;

  -- 2. the current role must not bypass RLS
  if exists (
    select 1 from pg_roles
    where rolname = current_user
      and (rolsuper or rolbypassrls)
  ) then
    raise exception 'connected as % which bypasses RLS', current_user;
  end if;

  -- 3. every view in public must be security_invoker (PG15+)
  select string_agg(c.relname, ', ') into bad
  from pg_class c
  join pg_namespace n on n.oid = c.relnamespace
  where n.nspname = 'public'
    and c.relkind = 'v'
    and coalesce(
      (select option_value = 'true'
       from pg_options_to_table(c.reloptions)
       where option_name = 'security_invoker'),
      false
    ) = false;
  if bad is not null then
    raise exception 'views without security_invoker: %', bad;
  end if;
end $$;

Three catalog queries, roughly 50ms on a schema with a few hundred objects. Run it right after migrations apply and before the app accepts a request. If you have tables that legitimately shouldn't have RLS (lookup tables, public config), exclude them by name in check 1; the point is that the exclusion is explicit and reviewable rather than the default.

Check 2 is the one people push back on, because it means the app can't connect as postgres locally. That's the point. If your local app connects as a role that ignores RLS, you have never once tested your policies.

Where this actually runs

The check only means something if local dev is real Postgres with RLS semantics. Mocks, SQLite adapters, and in-memory Postgres emulators either don't implement RLS or implement it loosely enough that the check passes on schemas that would fail in prod. I ended up running it against tinbase, which is a single-process Supabase-compatible backend on real Postgres 17: the API layer connects as anon/authenticated the way hosted Supabase does, so check 2 passes naturally, and the catalog queries behave exactly as they will in prod. Full Docker Supabase works too; it's just heavier for a check that takes 50ms.

Whichever you use, the requirement is the same: the Postgres your app boots against locally has to be the Postgres that enforces RLS, or the boot check is testing nothing.

The pattern

Three silent failures, one shape: RLS not applying looks like RLS working, only with more data. Nothing in the normal test loop distinguishes "policy correctly returned my rows" from "no policy, returned all rows, and mine were among them."

The boot check turns the silent failure into a loud one at the earliest possible moment, which is the only place it's cheap. If you've got a fourth mode, I'd like to hear it. My current suspicion is SECURITY DEFINER functions called from policies, but I haven't seen that one ship yet.

Your App Store reviewer is a user. Your listing is a product page.

Russel Dsouza — Wed, 02 Sep 2026 11:06:01 +0000

Most submission guides are engineering documents. They explain how to make the technical parts work.

Almost none treat submission as a UX problem, which it is. The reviewer is a user with a time budget. Your listing is a product page competing in a grid. The same first-impression rules that apply to onboarding apply here, and almost nobody applies them.

The reviewer is a user

A first-pass reviewer spends a short, bounded time in your app. Roughly what they encounter:

The launch screen. Is it branded, or is it a white rectangle?
A sign-in screen, if you have one. Do they even need to sign in?
The first functional screen. Does it work with the account you provided?
One or two feature interactions. Do these match what your description claims?

If any of that breaks, you're rejected. If it merely takes too long to work out — a demo account that doesn't support the sign-in method they tried first, for instance — you can also be rejected for missing information, which is the same outcome with more steps.

The dry run: hand your app and your demo account to someone who has never seen it, give them a minute, and watch. Don't help. Wherever they hesitate, the reviewer will hesitate too, except the reviewer has other apps to get to.

Review notes: write a route, not credentials

This is the highest-value item here and it costs ten minutes.

Most teams fill the App Review Notes field with the minimum:

Email: reviewer@yourapp.com
Password: TestPass123!

That gets the reviewer into the app and no further. They then explore on their own, in whatever order occurs to them, and whatever they don't find, they conclude isn't there.

Better:

Email: reviewer@yourapp.com
Password: TestPass123!

Once signed in:
1. Tap + on the home screen to create a Budget.
2. Add two or three expenses.
3. Tap Reports in the tab bar for the visualisation.
4. Tap Share, top right, for the export flow.

All features are unlocked on this account. No paywall.

Same amount of reviewer time, far more of your app actually seen. It also pre-empts the most common completeness rejection, which is a reviewer concluding a feature doesn't exist because they didn't reach it.

The last line matters more than it looks. A reviewer hitting an unexpected paywall has to decide whether that's the intended experience, and that decision doesn't go your way.

Screenshots that survive being small

Search results render your screenshots at thumbnail size. That's where the install decision gets made, and text sized for a full-screen preview is unreadable there.

A hierarchy that works:

Screenshot 1. One enormous headline stating the single most valuable outcome. Nothing else. It must be readable at thumbnail size, which means far larger type than feels reasonable in the design file.

Screenshots 2 and 3. One feature each, device UI, short caption.

Screenshots 4 onward. Supporting features and social proof, for the minority who swipe.

The test costs nothing: scale your first screenshot down to roughly the width of a thumbnail and look at it. If you can't read the headline, neither can anyone else, and that's the only one most people ever see.

Changelogs people actually read

"Bug fixes and improvements" tells a user nothing, which means it gives them no reason to update, which means they stay on an older build and eventually conclude the app is abandoned.

One line per user-visible change:

• Faster launch on iOS 18
• Fixed: widget showing stale data after a sync
• Fixed: dark mode contrast on Settings
• Added: CSV export for Reports

Note what that does beyond informing. "Fixed: widget showing stale data" tells someone who hit that bug that you saw it. That's worth more than the fix, because a user who reported something and never heard back assumes nobody is home.

The connecting idea

Every item here is the same move: treating someone you can't talk to as a user with limited time and no context.

The reviewer can't ask you where the feature is. The person scrolling search results can't zoom in. The user on an old build can't tell whether the update is worth the download. In each case they make a decision with whatever you gave them, and in each case most teams gave them very little.

Automating the mechanical parts — generating changelog stubs from the release diff, checking listing assets before submission, keeping the workflow in one place — is what letsdeploy.it does. The judgement parts stay yours, and the review notes especially are worth writing by hand.

What's in your App Review Notes field right now? My guess is an email and a password, and that ten minutes spent there has a better return than anything else on this list.

Self-Hosted Supabase Doesn't Break Because Postgres Is Hard

Russel Dsouza — Fri, 28 Aug 2026 12:21:49 +0000

I spoke to teams who had run self-hosted Supabase in production. Some still do. Some moved back to hosted. A couple ended up assembling their own stack from primitives.

The question I wanted answered: is the pain "Postgres is hard", or something more specific?

Disclosure before anything else: I work on a Supabase-compatible runtime, so I had a stake in one of the possible answers. The findings below happen to point at a product shape close to what my team builds, and you should weigh them accordingly. I've tried to report what people said rather than what would be convenient.

Nobody complained about Postgres. Every team described it as boring and working.
The pain is the surrounding services: auth, realtime, storage, proxy, meta, and the rest
Version drift between local and production was named unprompted by every team
Realtime dropping events during deploy restarts was the second most common
Both are distribution problems, not database problems

The three failure modes

Ranked by how many teams raised each without prompting:

Auth service version drift between local and production. Every team.
Realtime falling over during deploy churn. Most of them.
Storage service behaving differently from S3 behind a reverse proxy. Several.

Postgres was described as boring and working, by everyone. Not one complaint.

The pain lives in the distribution: the wrapping services that turn a database into a platform. Auth, realtime, storage, functions, image proxy, gateway, metadata. Roughly ten moving parts, each with its own version, its own restart behaviour, and its own proxy quirks.

Version drift, in detail

This came up in every conversation.

The shape: you develop locally against current service versions. Production runs older ones, because upgrading is a maintenance window and there is always a reason to defer it. Then code that works locally fails in production, because something changed between those versions.

Error taxonomies are the usual culprit. An auth error name that exists in the version on your laptop does not exist in the version on your server, so the client falls through to a generic unknown-error path and tells you nothing useful.

One team described losing a full day to exactly this. The conclusion they reached, which several others reached independently: nothing about that day was Postgres.

The workaround everyone lands on is pinning local development to the same service versions as production. Which means every developer runs deliberately outdated services, nobody benefits from upstream fixes, and onboarding a new engineer means reproducing a bespoke pinned setup that exists in one person's head.

That is a distribution problem. Not a code problem, and not a database one.

Realtime during deploys

The second most common, and the more insidious of the two, because it produces no errors.

Rolling deploy. The realtime service restarts. WebSocket clients disconnect, then reconnect, which works correctly. But during that reconnect window, subscriptions can miss changes.

Nobody sees an error. Users just don't get updates. The team finds out days later, when a customer mentions that a change on one device never showed up on another.

The workaround: deploy realtime only in low-traffic windows and manually verify subscription counts either side. That is toil, and it scales with team size in the wrong direction.

Storage behind a proxy

Less universal, sharper when it lands. Several teams lost an afternoon to 403s on presigned uploads that worked locally and failed behind nginx or HAProxy.

The cause was some combination of header case sensitivity and a Host header mismatch. Straightforward once you know where to look, and genuinely baffling if you assumed "S3-compatible" means "behaves identically to S3 in every deployment topology."

It doesn't. Compatibility claims describe an API surface, not a network path.

What this actually implies

The useful finding isn't that self-hosting is hard. It's that the difficulty is misattributed.

Self-hosted Supabase doesn't fail because a database is hard to run. It fails because a platform assembled from around ten independently versioned services has a coordination problem, and coordination problems don't announce themselves. They present as a weird error in production, an event that didn't arrive, a 403 that only happens behind the proxy.

Two things would remove most of what these teams described:

Ship every service at one version, by construction. Not tooling that makes alignment easier. A shape where misalignment isn't expressible, because the whole platform is one artifact with one version.

Make realtime restarts transparent. Resumption plus event replay across the disconnect window, so a deploy stops being a silent data-loss event.

Proxy compatibility is a third, and it becomes essential rather than nice-to-have the moment anyone puts this behind enterprise networking.

I'll be straightforward about the conflict here: the first of those describes tinbase, which is what I work on. It is a single binary, so services can't drift apart. It does not solve the second, and I'm not aware of anything that does yet.

It's also a local development runtime rather than a production self-hosting replacement, which is worth stating plainly given that everything above is about production.

If you're running it now

If you're hitting these, you aren't doing anything wrong. The shape of the distribution is doing it, and every workaround people described was a reasonable response to an unreasonable coordination problem.

Pin your versions deliberately rather than accidentally. Write down which ones, somewhere a new engineer will find. Deploy realtime when it costs least. And treat "S3-compatible" as a claim about an API, not a promise about your network.

If you run self-hosted Supabase in production, what broke that wasn't the database? I'm collecting these, and my expectation is that almost none of the answers are Postgres.

Should You Self-Host Supabase? It's Three Decisions, Not One

Russel Dsouza — Thu, 27 Aug 2026 10:53:45 +0000

The self-hosting argument never resolves because both sides are right about different things.

Own your data, no lock-in, cheaper at scale. Also true: it's an operational tax, upgrades cascade, and local drifts from prod.

Both hold. "Should I self-host Supabase" isn't one question, it's three, and most people answer all three with a single decision.

Local dev, staging, and production are separate decisions with separate constraints
Picking one answer for all three is where the pain comes from
Local: worst default, cheapest to change
Production: usually-correct default, most expensive to change
Most people optimise the expensive one and inherit the cheap one

The three decisions

Decision	Optimises for	Cost of getting it wrong
Local dev	Iteration speed, low friction	Paid daily, compounds quietly
Staging	Fidelity to production	Bugs reach users
Production	Reliability, operational burden	Paid at the worst possible moment

They pull in opposite directions. Local wants to be fast and disposable. Staging wants to be identical to prod. Production wants to be reliable and ideally someone else's problem.

No single answer satisfies all three, which is why whichever one you pick feels wrong somewhere.

Local: the one worth changing

Worst default, and almost nobody revisits it.

The standard setup runs the full container stack. Gigabytes of RAM, tens of seconds to boot, a laptop that gets loud. The consequence isn't complaints, it's that people stop running it.

That's the actual cost and it appears in no comparison table. A local environment nobody runs is one that quietly stops working, and you find out the day prod breaks and three people spend an afternoon building a repro from scratch.

Switching cost here is also the lowest of the three. Local is disposable. If a lighter setup doesn't work, you lost an afternoon.

How to tell: is anyone on your team pointing at staging instead of running locally? Then you already have your answer.

Single-binary runtimes exist for this now. tinbase is the one my team builds, so discount accordingly. It serves the Supabase-compatible surface from one process. It's a local dev runtime, not a production self-hosting replacement, which is exactly why these decisions need separating.

Staging: the one people skip

Staging is where the parity argument belongs, and it's usually where nobody's looking.

If local runs a different implementation from prod, local passing stops guaranteeing prod passing. Real cost. But the fix isn't making local heavier, it's having something between local and prod that's genuinely faithful.

Run the full stack in staging. Once before a release, not every morning. One boot a week instead of one a day, and fidelity lands where fidelity matters.

Skip staging and try to get parity out of local, and you end up with the worst combination available: a heavy local setup that still isn't identical to prod.

Production: highest stakes, usually-correct default

Self-hosting prod means owning image updates, CVE patching, cert renewal, backup verification, and restore drills.

With a platform team, that amortises across roles that already exist. Without one, it's evenings and weekends, and it has no deadline pressure right up until it has all of it.

The honest test isn't cost. It's: when did you last restore from a backup?

If never, you're not self-hosting. You're holding an unverified assumption about data you can't afford to lose. A backup nobody has restored is a hypothesis.

Self-hosting prod is reasonable when: someone owns operations, upgrades have a runbook, restore drills are scheduled, and the hosted bill justifies the work. All four. Not one.

The mistake

People spend their thinking on the production decision, where the default is usually right and switching is expensive. Then they inherit the local decision, where the default is usually wrong and switching costs an afternoon.

Flip the allocation. Change local this week. Leave prod alone until all four conditions above are true.

Optimise the decision you pay for daily, not the one you argue about online.

Worked examples

Solo dev with a live product:

Layer	Choice	Why
Local	Lightweight, no containers	Runs constantly, friction compounds
Staging	Full stack, before releases	Parity where it counts, weekly not daily
Production	Hosted	No ops capacity, no restore drills happening

Team of fifteen with a platform engineer:

Layer	Choice	Why
Local	Developer preference	Individual cost, individual call
Staging	Full stack, always running	Fidelity is cheap when someone owns it
Production	Either, run the numbers	Ops capacity makes it a real option

Notice what moves. Production changes with team structure. Staging barely moves. Local is personal and should be.

The short version

If you have no staging environment, local is doing two jobs and doing at least one badly. Fix that first.

Then: light local, faithful staging, boring production. Revisit production only when all four conditions hold.

Which of the three did you actually decide on purpose? My bet is production, because it feels consequential, and that local came from a quickstart guide three years ago and nobody has touched it since.

Migrating a Supabase Local Dev Project to Tinbase in 10 Minutes

Russel Dsouza — Mon, 24 Aug 2026 12:26:47 +0000

If you run Docker-based Supabase for local development and want to try the same stack on a single binary, this is the walkthrough. It takes about ten minutes for a typical project and nothing about it is destructive.

Tinbase is a Supabase-compatible runtime that ships as one executable. Your app code doesn't change, the SDK is the same, only the connection string and the way you boot the backend differ.

Install the binary, dump your schema, import it, swap the connection string
Your Docker Supabase state is never touched, so rollback is a git checkout away
Auth and realtime work through the same @supabase/supabase-js client
Edge functions and non-standard extensions are where the gaps are

Prerequisites

macOS, Linux, or Windows
A working Docker-based Supabase local environment you can currently run
A Node project using @supabase/supabase-js

This assumes your app connects through the standard SDK. Direct low-level Postgres connections work too, but aren't covered here.

Step 1: install the binary

curl -fsSL https://tinbase.dev/install.sh | sh

If you'd rather not pipe a script into a shell, download and read it first. Same URL, no pipe.

Verify the install:

tinbase --version

Step 2: dump your Supabase schema

With Docker Supabase running:

supabase db dump --file schema.sql --schema public

That produces a schema.sql containing your tables, functions, RLS policies, and triggers.

The auth schema doesn't need exporting. Both platforms manage it themselves, and importing one over the other creates conflicts rather than continuity.

Step 3: import into Tinbase

Start in a fresh directory:

mkdir tinbase-dev && cd tinbase-dev
tinbase up

In a second terminal, import:

tinbase psql -f ../schema.sql

Confirm the tables landed:

tinbase psql -c '\dt public.*'

If this errors, read the message rather than re-running. Import failures are almost always a missing extension, and the error names it.

Step 4: point your app at it

Docker Supabase serves on 54321. Tinbase uses a different default port, configurable through an environment variable.

- SUPABASE_URL=http://localhost:54321
- SUPABASE_ANON_KEY=eyJhbGciOiJI...
+ SUPABASE_URL=http://localhost:8080
+ SUPABASE_ANON_KEY=<from `tinbase config show`>

Run tinbase config show to get the anon key for your local instance. It's different from your Docker Supabase key, which is the step people miss and then spend twenty minutes debugging a 401.

Step 5: verify

Three checks, in this order:

Sign up a test user through your app's normal signup flow, then confirm the row exists:

tinbase psql -c 'SELECT id, email FROM auth.users'

Sign in as that user and confirm a protected route resolves. This exercises JWT issuing and verification, which is the part most likely to differ.
Trigger a realtime change if your app subscribes to anything, and confirm the subscription fires.

If all three pass, you're done. If step two fails, it's the anon key from step four.

Rolling back

Your Docker Supabase state was never modified.

git checkout .env
supabase start

That's the entire rollback. Worth knowing before you start, because it changes how much you need to think about this.

What doesn't migrate cleanly

Known gaps, worth checking against your project before you begin:

Edge functions written for Deno. Tinbase runs a v8 isolate rather than Deno, so Deno-specific APIs need adjusting.
Uncommon Postgres extensions. The widely used ones are preloaded; anything niche may not be.
Storage. Tinbase uses the local filesystem rather than S3-compatible object storage, which is usually what you want locally but differs from production.

For a standard project using Postgres, auth, realtime, and the JS client, none of these apply.

That third one is worth a thought regardless of which tool you use. If your local storage layer behaves differently from production storage, you have a category of bug that only appears after deploy, and no local setup will surface it.

Why bother

The honest version: if Docker Supabase boots fast enough on your machine and you never avoid running it, there's no problem to solve here.

The case for a single binary is about the days you'd otherwise skip local entirely. Boot time and memory footprint determine whether a local environment gets used, and an environment nobody runs is one that quietly stops working.

Full docs and source are at tinbase.dev. MIT licensed.

If you try this, I'm interested in what broke. Particularly edge functions, since that's the gap where "small syntax adjustments" covers a wide range of actual experiences.