This page keeps apart what Mezbano’s own application does to protect your data and what depends on a live Cloudflare account, a configured provider, a deployment procedure or an operator drill. What the code can do is described as something it can do; anything that has to be checked in a live deployment is said to need checking, not assumed from the code. This is not a certification or a service-level agreement.
How to read this page
- In the application
- How it works can be checked in the code and its supported ways of working.
- Checked outside the application
- Live provider settings, certificates, stored files, logs and drills that an operator must check.
- What we do not claim
- No certification, uptime promise, recovery guarantee or switched-on provider is assumed.
A record of protected changes
Protected business and administrative changes, including sales, expenses, costing, role changes and store settings, write an audit record: who made the change, what they did, when, and the details that suit that change. The app’s normal ways of changing data add new audit records; they do not edit an earlier one.
When a Mezbano platform administrator uses the product’s impersonation feature, the session is marked as impersonated, and the audit record for each change also records the administrator. The store’s activity log shows the change as the store user’s, marked “by Mezbano support” with the administrator’s name, and its CSV export has an “Acted by Mezbano support” column.
A scheduled job can copy older audit records to an R2 archive before it removes only the copied records from the main D1 database. The code sets that order; whether archive files exist, the job is healthy, and records are kept and can be found again in a live deployment has to be shown by the operator.
Closed months stay closed
When you close a month (Reports, then Close the month), that month’s sales, expenses, labour and purchases are locked against edits, so your closed books stay closed. The lock is enforced in the database, not just on the screen.
Store owners and admins can close a month. Reopening a closed month is limited to the store owner, because it reverses a financial-control decision.
No silent overwrites
On editors where saving replaces a whole record and its parts, such as recipes, checklists and daily sales, Mezbano checks that nobody else changed the record since you opened it. If someone did, your save is refused with a clear message instead of quietly overwriting their work.
Two-factor authentication and store sign-in rules
Anyone can turn on two-factor authentication (a code from an authenticator app) for their own account. A store can go further: when asked, the Mezbano team can require it for the store’s owners and admins, so everyone with extra access to that store uses a second step wherever the store’s data is shown, including a franchise owner’s brand pages. The rule applies to the store’s members; Mezbano’s own platform administrators are not covered by a store’s rule.
A store cannot switch its sign-in rule on or off itself; the Mezbano team sets it when asked. The rule belongs to one store, so a stricter store is never held back by a more relaxed one.
Each brand’s data stays its own
Recipes, ingredients, costs, policies and checklists belong to one brand. Signed-in pages check your current store membership, role, plan features and account state on the server every time, instead of trusting store or brand IDs or permissions sent from the browser.
The one deliberate exception is the standard list of expense and revenue categories, which is shared so that reports stay consistent and comparable across the platform. That shared list is a feature; it does not expose your records.
Encryption in the app and on the platform
The application adds HTTP Strict Transport Security to HTTPS responses and marks sign-in cookies Secure in HTTPS environments. Cloudflare documents encryption at rest for R2 and transport encryption for its services. The deployment operator must separately check active certificates, HTTPS redirects, DNS proxying, Cloudflare plan settings and the live response path; the source code alone cannot show those controls.
Automatic backups and disaster recovery
The scheduled Worker contains a nightly D1-to-R2 backup job that publishes a finished backup only after its files are written and checked. Cloudflare offers plan-dependent D1 point-in-time recovery; the exact retention available to a deployment must be checked against its live database and plan.
An optional copy to another provider can replicate finished database backups, archived audit records and attachments in use, but only once that provider is fully configured. Recovery from the other provider and recovery-time targets are not guarantees: they need the copied files checked on the provider’s side and a successful restore drill. The first recorded staging drill is still an operator acceptance item.
Safe, reviewed database changes
The repository’s supported command for changing the production database first replays the changes against a copy of production and compares the resulting structure before it can apply them. Project policy requires production changes to add rather than remove, and forbids direct remote write or structure commands; an operator must use that checked path for the control to hold.
Releases are checked before they go out
The repository’s release procedure requires its checks to pass first: type checks, lint, unit tests, a build and browser tests. The person releasing runs them by hand, because the deploy commands do not run them and the automated CI workflow that runs the same checks is switched off for now. This is a written procedure in the code repository; it does not show that it was followed for a particular release.
Reporting a security concern
Found something that looks wrong, or have a question about how your data is handled? Email support@mezbano.com and we will pass it to the right person. See our subprocessors for the third parties that help us run the service, and the privacy policy for how we handle personal data.