Skip to main content
This page collects what you need when your app goes to production. The steps after the merge are on Apps on GitHub and a host.

​
Two environments

Every app has development and production. Each has its own keys, data and cases. Production does not appear in everydeck’s addresses, development has ?env=dev at the end. A locally set up app does not switch to production by itself. Until the first event from production arrives, Setup says “Waiting for your deployment”. Merged code alone sends nothing. Flows checked only locally wait for their first real event in production. everydeck confirms them by itself.

​
Kinds of keys

everydeck creates every key itself and shows it once. Your agent never sends a key to everydeck. To replace a key, go to Settings › App › Keys and click Replace. The old key keeps working for 1 day.

​
What to set where

The setup page and Setup › To do list exactly the ones your app needs. You cannot send these to your agent: they are steps at your host.
Do not set a fixed EVERYDECK_RELEASE_KEY. The SDK finds the version by itself. See Versions.

​
On a connected Supabase project

everydeck sets the settings of its own functions and its Vault entries in your project itself. The values never go to your agent or into the chat. Your own Edge Functions read their everydeck settings from the project when you deploy them as usual. If you deploy everydeck’s own functions again yourself with the Supabase CLI, Supabase turns its JWT check back on for them, and everydeck can no longer reach them.

​
The outbox

Some apps write from the browser straight into the database, for example with the Supabase client and row level security. Then there is no server that could report “this was saved”. The browser cannot prove it either: it does not know whether the database really committed. The outbox solves this:
1

A trigger writes a note

A trigger on your table writes a short note into everydeck_outbox.event, in the same transaction as your change. If the change is rolled back, the note is gone too. So only confirmed results arrive.
2

The relay sends it

The relay reads waiting notes in order, sends them to everydeck in batches, and deletes a batch only after everydeck accepted it. everydeck counts each event once.
3

everydeck records the result

The result joins the browser’s start of the same run. In Live, these events show as Supabase.

​
What goes through it

Only references: the name of the signal, the run id, the person, the organization, the kind and id of the record and the platform. Never column values or texts. The outbox table is closed to anon, authenticated and Supabase’s Data API.

​
When it runs

  • On Supabase: a schedule calls the function everydeck-outbox-relay every 5 seconds while notes wait, and every 5 minutes with a heartbeat. A quiet app costs no extra calls. A result arrives within seconds.
  • On plain PostgreSQL: npx everydeck-outbox-relay runs as a worker of your app. It delivers every 5 seconds.
If your own server reports every result, there is no outbox, no schedule and no relay.

​
When it stops

The relay is a job of your app, named “everydeck outbox relay”. It sends its heartbeat only after a run that delivered everything. If it misses two periods, a case opens in production: “Job “everydeck outbox relay” has not reported for 2 periods”. A note everydeck refuses for good stays in everydeck_outbox.event with its error and is never sent again. everydeck does not show these anywhere else.

​
Limits

  • A deleted row cannot be a result: it leaves nothing a signal could point to.
  • At most 1,000 notes per run.

​
Updating everydeck later

When everydeck names newer package versions, ask your agent to raise them. If a new version could change more in your app than you allowed, everydeck asks you first with Allow and Not now. See Changing data.