Security
Your data stays on your hardware
Vorrex Server runs on-premises at every plant site. No cloud hosting, no shared tenants, no data leaving your network. Every access event, every garment transition, every automated decision is written to an immutable audit log that cannot be altered — enforced at the database level, not just in application code.
Deployment model
Vorrex Server runs inside your network
Vorrex Server is a TypeScript application on Node.js, installed as a supervised service — systemd on Linux, a wrapped Windows Service on Windows — on a machine you control. It connects to a PostgreSQL database on your local network. There is no Vorrex cloud component in the operational path — plant-floor scans go from Vorrex Terminal to Vorrex Server to PostgreSQL, entirely on your LAN.
Each plant site runs its own independent Vorrex Server instance. A compromise at one site does not affect other sites. For multi-site laundry groups using the HQ estate dashboard, the HQ API aggregates read-only reporting data — plant-level write operations stay local.
Audit trail
Every event is permanent. Nothing can be edited out.
Every garment status change — whether triggered by an operator scan on Vorrex Terminal, an automated compliance rule, or a wash batch completion — writes a row to the LifecycleEvent table. A database trigger prevents any UPDATE or DELETE on that table. This is not an application-level constraint that can be bypassed by a rogue API call — it is enforced in PostgreSQL itself.
Each event records: the garment UID, the previous status, the new status, the operator or system process responsible, the timestamp, and the plant context. Automated transitions — wash routing, inspection pass/fail, protection engine allocations — are logged with the same fidelity as manual operator actions. Nothing is inferred after the fact.
Authentication
Three layers — PIN, session, and capability gates
PIN authentication
Plant-floor operators authenticate with a registered device and a numeric PIN on Vorrex Terminal, with database-backed lockout. Sessions time out automatically. No keyboard required — the touch pad is purpose-built for gloved hands.
Vorrex Terminal
First-party sessions
Every request carries an opaque session id, stored hashed in Postgres, issued by Vorrex Server. The session resolves the operator's plant, role, and capability set server-side. Plant scoping is read from the session — a client cannot claim a different plant.
Vorrex Server
Capability gating
Every mutating API endpoint checks the operator's capability set before executing. Capabilities are configured per operator in Vorrex Manager. A sorter cannot trigger dispatch. A driver cannot edit contracts.
Vorrex Manager
Data isolation
Plant data cannot leak across tenants
Every operational table carries a plant_idcolumn. The application scopes every query to the current operator's plant, taken from the resolved session — never from client input. Postgres row-level security enforces the same scoping as a second, defence-in-depth layer at the database itself.
The plant is never accepted from query parameters or request bodies. It comes exclusively from the resolved session. A client application cannot request data for a plant it has not been granted access to.
Offline resilience
The plant keeps running with no internet
Vorrex Terminal, Vorrex Manager, and PostgreSQL all run on the plant LAN, so scanning continues normally even if the site loses its internet connection. Only the outbound plant-to-hosted sync — the link that feeds Vorrex Portal, Vorrex Me, and the Verify page — depends on connectivity.
Vorrex Go, the driver route, runs a service worker with an IndexedDB action queue for cellular dead spots between stops. Stops recorded offline replay in order the moment signal returns, and the garment audit trail is completed without gaps.
Data ownership
You own the database. You control the backup schedule.
Because Vorrex runs on your own PostgreSQL instance, your DBA controls backups, retention schedules, and encryption at rest, using standard PostgreSQL tooling — pg_dump or base backups. There is no Vorrex retention policy overriding yours. If you want to archive data to cold storage after three years, that is a backup job you configure.
Vorrex Manager includes an Export Centre for generating Xero-compatible accounting CSVs and PDF compliance packs. These are point-in-time exports you control — there is no ongoing data feed to any external system unless you configure one through standard PostgreSQL export tooling.
FAQ
Common questions
Does Vorrex store data in the cloud?
No. Vorrex Server runs as a supervised service on your own hardware at each plant site. Your garment data never leaves your network unless you explicitly export it. There is no Vorrex cloud tenant, no SaaS hosting, and no third-party data processor for operational records.
How does Vorrex prevent unauthorised access to the kiosk terminals?
Vorrex Terminal requires a PIN for every operator session. Capabilities are assigned per operator in Vorrex Manager — a sorter cannot access dispatch, a driver cannot access billing. Sessions time out automatically. All access attempts are written to the immutable audit log.
Can audit records be deleted or edited?
No. The LifecycleEvent table has a database trigger that blocks UPDATE and DELETE operations. Every garment status change, every login, every automated decision writes a permanent row. This is enforced at the database level, not just at the application level.
How are sessions secured?
Vorrex uses first-party session authentication — opaque, randomly generated session ids, stored hashed in a Postgres session table, delivered over HttpOnly, Secure, SameSite cookies. Sessions carry the operator's plant, role, and capability set, resolved server-side on every request. The plant is never accepted from a client request.
What happens if a kiosk goes offline?
Vorrex Go, the driver route, runs a service worker with an IndexedDB action queue for offline stops. Terminal scanning depends on the plant LAN and Vorrex Server, which stay up locally with no internet — only the plant-to-hosted sync is affected, and it resumes automatically when connectivity returns.
Related reading
See it on your data, or start with the checklist.
Either path works. Pick whichever fits where you are today.