What Eryxon Flow's Supabase architecture means on the shop floor

A cutting operator finishes a batch and records the result on a tablet. The bending cell needs to know that its next job is ready, while planning wants to see the same change in the office. Showing a new status on two screens is straightforward. Knowing whether both screens reflect the same accepted operation, and whether a different workshop can read that record, is a harder question.

Eryxon Flow is built on Supabase. Its architecture documentation describes PostgreSQL, row-level security, authentication, file storage, realtime updates and Edge Functions behind the application. Each piece answers a different question about a manufacturing record. Where does the job live? Who may change it? How do other screens hear about the change? Digital work instructions and job progress tracking describe what people do with the system. Here the focus is what its backend design requires from the team operating it.

One production record, several views

Eryxon models work as jobs, parts and operations. One job can contain multiple parts; a part may pass through cutting, bending and welding. An operation might appear as the next task on an operator’s tablet and as a delayed stage in a planner’s queue. If both views derive from persistent records rather than separate spreadsheets, a team has a better chance of tracing why their screens differ.

PostgreSQL provides the underlying store, but choosing a database does not decide when cutting is actually finished. Does the part require an inspection before the next cell can start? Who can release it when a defect is reported? Those are production rules. Eryxon’s architecture documentation says lifecycle changes run through specific transition functions, including functions for operation state and time entries. A new interface should use the established transition path rather than write a plausible-looking status directly to a table. Otherwise two screens can agree on an invalid state.

Imagine an illustrative case: two operators leave the same operation open on separate tablets. One marks it complete while the other has an active time entry. Hiding the completion button on one device would not reliably resolve the conflict. The accepted transition must account for the timer, the current operation state and the order of updates on the server. The record’s meaning matters more than the color of the last screen somebody touched.

A sensible pilot starts with a single job that has two parts and a few operations. Make a state change from one account and check the outcome from another. Then deliberately try a conflicting change. Record what the server accepted, not merely what appeared in the browser. This makes the boundary between a convenient interface and a trustworthy production record visible.

Permissions extend beyond the sign-in page

Signing into a shop-floor application must not grant access to every job in every workshop. Eryxon’s documentation describes Supabase Auth sessions, admin and operator roles, tenant separation and PostgreSQL row-level security. Menu visibility is only one layer. The database and API paths also need to respect the account’s scope. In a shared infrastructure deployment, a wrongly mapped tenant is not simply a confusing screen: it could expose another workshop’s orders.

Test the boundaries with distinct accounts. A planner should see the relevant job, an operator should see the permitted task, and an unrelated account should be denied access. Do the same test through a permitted API path rather than only through the app interface. That the architecture includes row-level rules does not prove that every policy in a particular installation has been configured correctly. Authorization is behavior to verify, not a diagram to admire.

Attachments make the test more interesting. A job may carry a drawing, a STEP model or a PDF instruction. Eryxon’s architecture lists Supabase Storage and expiring signed URLs for files. The database row and the downloaded file are separate access paths. If a user’s permission changes, how long can a previously issued link still be used? If an attachment is linked to the wrong job, a correct database policy on the job row cannot by itself correct the mistake. Try both record and file access when reviewing a role change.

Realtime is not the source of truth

Supabase Realtime can relay changes to open screens. Planning may see an operation advance without refreshing the page. That does not make every tablet permanently synchronized. When a connection drops, an event may be missed. On reconnect, a client should obtain the current accepted state from durable storage rather than assume that its last displayed notification is complete history.

Consider a tablet at shift change. An operator taps Complete just as wireless access fails. The tap is not proof that the server accepted the operation. A good workflow distinguishes pending submission from confirmed completion, and makes rejection or retry legible to the person on the floor. Sending the same action twice after reconnection deserves its own test. Without checking the actual deployment, it would be misleading to promise offline operation or exactly-once behavior simply because the backend supports realtime updates.

Eryxon also exposes integration routes through Edge Functions. That is useful when an ERP sends work to the MES, but it introduces another source of truth to reconcile. The ERP’s order reference might not be the MES job identifier. Agree on who assigns each identifier, whether a repeated event creates a new job or updates an existing one, and where failed imports are visible. An API allows systems to exchange messages; it does not supply the business agreement that makes those messages safe to repeat.

A narrow architecture test

Instead of testing every feature at once, use a small production example. Create a job with two parts. Give a planner and an operator different access. Change an operation, disconnect one tablet, reconnect it and compare the screen with the stored record. Try to access the job and its attachment as an unrelated account. Replay an integration event and inspect the result. None of these exercises presume the product is broken. They expose the places where a production team needs a documented answer before relying on the tool during a shift.

Hosting needs a separate checklist. A Supabase-based application is not automatically portable without operational work. Decide who owns database backups, file storage, authentication settings, realtime connections and Edge Functions. Document versions and test restoration of the parts together. Moving the database while leaving attachments or identity configuration behind is not a completed migration. The general Supabase backend components are useful context, but Eryxon’s manufacturing rules still sit above that platform.

The architectural choice gives Eryxon Flow a coherent foundation for sharing production records across roles and screens. Its value should be judged by what happens at the boundaries: a rejected unauthorized read, a clear answer after a disconnected tablet returns and a recoverable record after an outage. More dashboards will not fix those boundaries if a small pilot cannot demonstrate them.

Sources: Luke van Enkhuizen’s overview of open-source software for metal fabrication and the Eryxon Flow application architecture. The workshop situations are illustrative, not reports from a particular installation.