A neutral look at one design choice

Supabase, and a small always-on worker beside it

What the worker is good for, and the places where you do not need one.

Written for a team that already runs on Supabase and a native Mac app. No sales pitch. Each slide stands on its own.

Press → or swipe to start

The question

Two views, and each is right about something

View 1

"Supabase can run everything."

True for data, sign-in, live updates, and short jobs that run on a schedule or when a row changes. It is hosted, always on, and looked after for you.

View 2

"A small always-on worker is also needed."

True when work has to happen while nobody has the app open, or needs a fixed address, one home for secrets, or a job that runs for a long time.

Which view fits depends on what your app does when nobody is looking at it. The next slides walk through that, one situation at a time.

Quick glossary

Six words used in this deck

WorkerA small program on an always-on server. It picks up jobs and does them.
Cron jobA task that runs at set times, like an alarm clock for software.
WebhookA message another service sends to a web address when something happens.
QueueA list of jobs waiting to be done, each with one owner.
GatewayOne doorway that holds the keys and makes outside calls for everyone.
HarnessThe setup around an AI model: its tools, automatic checks and rules.

Credit where it is due

What Supabase already does for you

Data

A proper database for clients, walls, drafts and the "Needs you" queue.

Sign-in

Accounts and logins for the whole team and for client portal users.

Row-level security

Rules for who can see which rows, so one client never sees another's.

Realtime

Changes appear live in every open Mac app.

Scheduled jobs

pg_cron runs a task at set times inside the database.

Database webhooks

Triggers react when a row is added or changed.

Edge Functions

Small pieces of server code that run on request.

Storage

Files such as documents and images, with the same access rules.

Fair noteAll of this is hosted and always on. No one here is saying Supabase falls short at what it does. The question is only about work that does not fit these pieces.

Side by side

The Mac app alone, or the Mac app plus a worker

Mac app + Supabase

Works while people are using it

  • Chat with Archie, the AI teammate
  • Archie drafts on request
  • Humans approve in "Needs you"
  • Simple, fewer moving parts

Each agent run happens on the laptop of whoever asked.

Mac app + Supabase + worker

Also works when nobody is there

  • Overnight and weekend work continues
  • One address for Slack, email and the portal
  • One home for keys, rules and run records
  • One more small server to look after

Neither is "better". They fit different amounts of automatic, unattended work.

The shape

One small worker sits beside Supabase and does the unattended work

Team Mac apps Mac app Mac app Mac app Outside services Slack Email Portal Supabase data and sign-in live updates job table (the queue) Always-on worker one small server (VPS) or container claims jobs, runs the agents, writes results and run records Gateway holds the keys, makes the calls Model providersClaude, GPT, local Replies outSlack, email, portal Keys stay on the server side No keys on the Macs. Every outside call goes through the gateway. view, approve messages in jobs needs a call Team Mac apps Mac app Mac app Mac app view, approve Supabase data and sign-inlive updatesjob table (queue) Outside services Slack Email Client portal jobs, results messages in Always-on worker one small server (VPS) or container claims jobs, runs the agents,writes results and run records needs a call Gatewayholds the keys, makes the calls Model providersClaude, GPT, local Replies outSlack, email, portal Keys stay on the server sideNo keys on the Macs. Every outside callgoes through the gateway.

Macs talk to Supabase as before. The worker is one more client of Supabase that never sleeps.

An example day

While the laptops sleep, the work still gets done

08:30 Laptops wake. Results wait in "Needs you". Laptops asleep in use asleep Worker always on 1 2 3 4 00:00 03:00 06:00 09:00 12:00 15:00 18:00 21:00 24:00 WorkerLaptops 00:0003:0006:0009:0012:0015:0018:0021:0024:00 always on asleep in use asleep 1234 08:30 Laptops wake Results wait in"Needs you"
1Slack question arrives. A reply is drafted.
2Email arrives. It is sorted and a draft is prepared.
3The scheduled morning report is built.
4A client portal request in the evening gets picked up.

Illustrative day. Times are examples, not measurements.

Situation 1 of 13 · Scheduled tasks

Some work has to start at a set time

07:00 on weekdaysthe clock says go
Worker starts Archiebuilds the client summary
"Needs you"ready when the team arrives

Think of a morning client summary, a weekly report, or a nightly tidy-up. A cron job is an alarm clock for software. It needs something awake to hear it.

Fair notepg_cron, Supabase's built-in scheduler, is a good fit for short jobs that only touch the database. A worker helps when a schedule starts an agent, calls outside services, or takes a while.

Situation 2 of 13 · Incoming messages

Messages from outside need an address that is always there

Slack, email, client portalsend a webhook when something happens
One fixed addresson the always-on worker
Job added to the queuenothing is missed

A webhook is a message that another service pushes to a web address. A laptop has no steady address and may be asleep when the message lands.

Fair noteA Supabase Edge Function can also be that fixed address, and it is good at "receive, check, store". The worker then picks up what needs longer thinking.

Situation 3 of 13 · Sleeping laptops

Laptops close. The work should not stop.

Lid closed nothing runs here Server keeps going small, always on

An agent that lives on one person's Mac stops when the lid shuts, the Wi-Fi drops, or the system updates.

Fair noteIf work only matters while someone is looking at the app, a sleeping laptop is not a problem and this point does not apply.

Situation 4 of 13 · Secrets

Keys live in one place, not on every laptop

Workerruns the agent Gatewayholds the keys Model providers Slack, email Mac apps carry no keys, so a lost laptop leaks none

Tip: this picture scrolls sideways on a phone.

A gateway is one doorway that holds the keys and makes the outside calls for everyone. Change a key once, not on every machine.

Fair noteSupabase can store secrets for its own Edge Functions. The wider question is where agents run, and which machines you want holding keys.

Situation 5 of 13 · One owner per job

Two laptops should never act on the same event

Email arrives Job queue Job 41 · doneclosed Job 42 · new emailclaimed by: worker Job 43 · waitingunclaimed Laptop Atries to claim Laptop Btries to claim already taken,so it skips Workersteady owner

Tip: this picture scrolls sideways on a phone.

If a job fails, it goes back in line and is tried again, up to a set number of tries. Nothing is sent twice.

Fair noteClaiming a job is a normal database action, so Supabase can hold the queue. The worker is simply the one steady owner that is always there to claim.

Situation 6 of 13 · Long jobs

Some agent jobs take longer than a short function allows

Short function time limit reached, the job stops Worker job progress is saved as it goes (circles), then the result is written back

Tip: this picture scrolls sideways on a phone.

Research, large reports, multi-step work. Archie can keep going on a worker and save progress along the way.

Fair noteEdge Functions are short-lived by design, and that suits most small jobs well. Only genuinely long jobs need a different home.

Situation 7 of 13 · Audit trail

The server writes the record, not whichever laptop ran it

TimeAsked byWhat ranWritten by
06:02ScheduleMorning client summary, 3 draftsWorker
09:41A team memberReply drafted, approved by a humanWorker
14:10EmailRequest sorted, handed to the right personWorker

A record kept on a laptop can be missing, edited, or lost with the machine. A record written by the server is complete and in one place.

Fair noteDatabase triggers can already log changes to data. The worker adds a record of what the agent did, and why.

Situation 8 of 13 · Testing on every push

Tests run on every push, with the same result for everyone

Someone saves codea "push" to the shared repo
Runner on the workersame machine setup every time
Pass or failshown to the whole team

A git runner is a machine that checks the code each time it changes. "It works on my Mac" stops being the end of the discussion.

Fair noteHosted testing services do this too, and well. A worker makes sense if you want tests next to your agents and keys, with one setup for both.

Situation 9 of 13 · Agents in branches

Agents work on their own copy, away from your files

Main version Agent A: change Agent B: change person approves Each branch is a separate copy. Nothing joins main until a human says yes.

Tip: this picture scrolls sideways on a phone.

A branch is a separate copy of the work. Agents try changes there, and a person approves before anything joins the main version.

Fair noteBranches also work on a laptop. A worker keeps agent work out of people's working folders and lets several agents run side by side without clashing.

Situation 10 of 13 · Shared service agents

Some helpers should always be on duty

Email inbox agent

Reads new mail, sorts it, drafts replies for a human to approve.

Slack reply agent

Answers team questions in the channel at any hour.

Client portal agent

Handles requests that clients make through their portal.

API and integration agents

Keep outside systems in step with your data.

Research and report jobs

Gather facts in the background and have a report ready.

Fair noteIf you do not run helpers like these yet, this point does not apply yet. It is a reason to add a worker later, not a reason to have one today.

Situation 11 of 13 · Support triage

A request at 2am should still reach a person who can act

Watchdog: raises an alarm if the triage agent itself goes quiet Classifyurgent or not Answersimple ones Alert on-callSMS, call, Slack Waitfor a reply Escalatenext person simple no reply emergency On-call rota: person A, then B, then C Watchdogalarm if the triage agent goes quiet Classifyurgent or not Answer simple onesdone, no one is woken Alert on-callSMS, call or Slack Waitfor an acknowledgement Escalateto the next person simple no reply emergency On-call rota: person A, then B, then C

An agent sorts requests, answers the simple ones, and alerts the person on call for emergencies. If nobody acknowledges, it moves to the next person.

Fair noteThis is the case where a sleeping laptop matters most, because the watchdog and the alerts must keep running when everyone is offline.

Situation 12 of 13 · Same rules for all

The same rules apply to every person and every agent

One rule set tools it may use automatic checks (hooks) what it must not do Every Mac app Worker agents Scheduled jobs

Tip: this picture scrolls sideways on a phone.

A harness is the setup around an AI model. Kept in one place, its rules apply the same way to automatic work as to work a person starts.

Fair noteThe Mac app can ship with the same rules built in. A worker is how you make sure automated work follows them too.

Situation 13 of 13 · Health checks

Someone should notice when something stops

Worker pings"I am alive", every minute or so
Supabase notes ita "last seen" time
Pings stop?a check notices the gap
A person is toldby message

The same check can watch for jobs stuck in the queue and for runs that keep failing.

Fair noteSupabase has its own dashboards for the database. Watching the worker is one extra small thing to own, and part of the honest cost of having one.

Another option

Hosted agent services versus a small worker

Hosted agent services

Claude hosted runs, OpenAI hosted runs, Supabase Edge Functions and cron

Good at:

  • Quickest way to start
  • Nothing to maintain or patch
  • The vendor runs and scales it

Trade-offs:

  • Tied to one vendor and its sandbox
  • Time limits, no persistent file system (Edge Functions)
  • Keys and rules sit with each vendor
Small worker

One small server you control

Good at:

  • Mix Claude, GPT and local models per job
  • Rules and keys kept in one place
  • Can still call hosted agents where they are good enough

Trade-offs:

  • Someone looks after it
  • You set up the health check yourself

These are not rivals. A worker can hand a job to a hosted agent when that is the simplest fit.

Being honest

Where you do not need a worker

The app only reacts while someone has it open

Chat, a draft on request, the approve queue. Everything starts with a person.

No scheduled or event-driven work

Nothing needs to start by itself at a set time or when something arrives.

Jobs are short

They fit an Edge Function or pg_cron and finish quickly.

Nothing comes in from outside

No Slack, email or portal events that need a steady address.

If this describes how you work today, Supabase on its own is a sound choice.

The short version

When you need a worker, and when you can skip it

You need one when
  • Work must run while laptops are closed
  • Outside services must reach you at a fixed address
  • Jobs run longer than a short function allows
  • You want one home for keys, rules and run records
  • On-call alerts must not depend on a laptop
You can skip it when
  • The app is only used live, by people
  • All jobs are short and fit Supabase
  • No outside events need handling yet
  • You would rather not own another server
  • Hosted agents already cover what you need

It is also fine to start without one and add it when a real need shows up.

If you do add one

A suggested minimal starting setup

  1. Supabase stays the source of truth.Data, sign-in and the queue stay where they are.
  2. The Mac app stays a client.Nothing changes for people using it.
  3. One small worker.It picks up jobs from a Supabase table, runs the agent, and writes results and run records back.
  4. Secrets only on the worker.None on the Macs.
  5. A simple health ping and an alert.So a person hears if it stops.
  6. Add pieces only when a real need shows up.
Mac apps Supabasesource of truth One workerholds the secrets jobs, results ping missed: alert

In one line

Same data, same app. One question decides it.

Does any work need to happen when nobody has the app open?

No

Supabase plus the Mac app is complete. Keep it simple.

Yes

Add one small worker beside Supabase, and let it do only that work.

Not sure

Start without one. The setup on the previous slide can be added later without redoing anything.

For referenceSystems we run ourselves use this same shape: one always-on server, desktop apps and agents as clients, and one gateway holding the keys.
1 / 25