Choose the execution location based on who starts the work and what it needs: call a Supabase Edge Function for a signed-in user action, schedule recurring backend work with Postgres, and use Capacitor background execution only when the task genuinely needs the device. Edge Functions are bounded request handlers, not always-on workers; move heavy, long-running processing to worker infrastructure.
Which automation pattern fits your workflow?
Start with the initiator, execution environment, duration, reliability requirement, and credentials. The app should not be responsible for recurring business automation that must run while it is closed, and a mobile background task is not a dependable server scheduler.
As an Amazon Associate I earn from qualifying purchases.
| Workflow | Where it runs | How it is initiated and trusted |
|---|---|---|
| A signed-in user action | Supabase Edge Function | The Supabase client invokes the function with the user’s session JWT. |
| Recurring backend work | Supabase Postgres schedule calling an Edge Function | pg_cron schedules an HTTP request through pg_net; keep the call credential in Vault. |
| External provider event | Supabase Edge Function | Validate the provider’s signature in the handler when the endpoint does not require a Supabase user JWT. |
| Brief device-dependent work | Capacitor native background environment | The operating system decides when the task runs; use it only when the device itself must do the work. |
| Heavy or durable long-running processing | Background worker infrastructure | Use a worker design with suitable failure handling and retries rather than relying on a request handler to stay alive. |
How should a React app call an Edge Function?
For work a signed-in user explicitly starts, invoke the function through the Supabase client library. Supabase’s guide shows supabase.functions.invoke; the user’s session JWT is sent in the Authorization header. The function can use the authenticated identity, while database access should be protected with Row Level Security policies. See Supabase’s guide to securing Edge Functions.
Recommended Free Tools
A publishable key is intended to be visible in shipped browser or mobile code. It identifies the project; it is not a substitute for user authentication or database authorization. Supabase distinguishes the user JWT in Authorization from the project key in apikey. Do not ship a secret or service-role key: Supabase says secret keys bypass Row Level Security and must remain under server-side control. See Supabase API keys.
#1 Best Overall
How do you schedule a Supabase Edge Function?
For recurring work that must run independently of whether the app is open, Supabase documents scheduling an HTTP call to an Edge Function with Postgres pg_cron and pg_net. Store the function-call credential in Supabase Vault, as the scheduling guide recommends, and configure the function to accept the authentication method used by its caller. Keep that credential out of the app bundle. See Supabase’s function scheduling guide.
This is a backend-controlled schedule, not a timer running in React or Capacitor. Choose a schedule that matches the project’s configuration and the task’s needs; the documented examples do not establish that every workload belongs in an Edge Function. Keep the function’s work short and bounded. Supabase’s general guidance says, “Heavy long-running jobs should be moved to background workers.” See Supabase Edge Functions.
How should an Edge Function handle a third-party webhook?
External providers generally do not send a Supabase user JWT. Supabase advises disabling verify_jwt for the specific webhook function and verifying the provider’s signature inside the handler. Disabling the platform JWT check lets requests reach the handler without a Supabase JWT, so signature validation or another explicit authentication mechanism is essential. Do not disable JWT verification indiscriminately across functions. See Supabase’s function security guidance.
Can an Edge Function keep running after it responds?
For short follow-up work, Supabase documents EdgeRuntime.waitUntil(promise), which lets a task continue after the handler has returned a response. Its examples include asynchronous storage uploads, database updates, and logging. Handle failures with try/catch, and account for the function’s wall-clock, CPU, and memory limits. See Supabase background tasks.
waitUntil does not make completion durable. For important work, plan for failures and use retries or a durable worker mechanism appropriate to the application. The right queue or worker cannot be selected without knowing the workload’s duration, throughput, latency target, and retry requirements.
Can a Capacitor app run tasks in the background?
Capacitor Background Runner provides a headless JavaScript environment for native background events, but it is not an always-on service or precise timer. The operating system controls when work runs, execution is constrained, and runner state is destroyed between invocations. Use it only when work needs device-local capabilities; route recurring business automation through a backend schedule instead. See Capacitor Background Runner documentation.
The cited Capacitor next documentation describes iOS execution as approximately up to 30 seconds per invocation, with timing determined by iOS. It says Android can allow longer execution in some cases, but recommends keeping work to 30 seconds for cross-platform behavior and describes a minimum 15-minute interval for repeating work. These are plugin documentation limits, not guarantees that a task will run at a particular time. Because this is next documentation, check the stable plugin documentation and version installed in your project before relying on implementation details.
Quick Recap
Best Value
What security and project setup should you check?
- Separate credentials: send a user’s JWT in
Authorization; use the project key inapikey. Keep secret and service-role keys server-side because they bypass RLS. - Store secrets appropriately: use Supabase’s secret configuration for local and production function secrets, and keep local secret files out of version control. See Supabase function secrets.
- Protect webhook routes: configure authentication per function and verify provider signatures in the handler.
- Protect scheduled calls: store cron-call credentials in Vault rather than in shipped client code.
- Keep execution bounded: use a worker for heavy, long-running work instead of assuming an Edge Function will persist.
- Maintain native project configuration: Capacitor’s React guide explains that compiled web assets are copied into native projects and says to commit the native platform folders to source control. See Capacitor’s React guide.
A practical decision checklist
- A user taps a control while signed in: invoke an Edge Function with the Supabase client and authorize the request using the user’s identity and applicable RLS policies.
- The task must recur while the app is closed: schedule a backend invocation with
pg_cronandpg_net, keeping its credential in Vault. - A provider calls your endpoint: configure only that function for the provider’s authentication pattern and validate its signature in the handler.
- The response can return before brief follow-up work finishes: consider
EdgeRuntime.waitUntil, with explicit error handling and no assumption of durable completion. - The device must perform the work while backgrounded: consider Capacitor Background Runner, accepting OS-controlled timing and short execution limits.
- The work is long-running or completion must be dependable: design a suitable background worker and retry strategy instead of stretching an Edge Function or mobile task beyond its limits.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
