Security and trust

You are being asked to run your daily production through this software and, if you connect it, to let it see your accounting. This page says what that actually involves — where the data sits, who can reach it, what happens when something breaks, and what we have not done. Every statement below describes a mechanism that exists today. Where a protection has a limit, the limit is written down rather than left out.

Where your data lives

The application runs on Google Cloud Run in us-west1. The database is PostgreSQL hosted by Supabase. Files you upload — labels, photos, exports — are stored in Google Cloud Storage. All of it is in the United States.

Traffic between your browser and the application is encrypted in transit with TLS. Database storage and object storage are encrypted at rest by the providers that operate them. We do not operate our own hardware, and we do not hold a copy of your data anywhere else.

The companies that process data on our behalf are listed, by name and purpose, on the sub-processors page. That list is part of this documentation, not marketing: if it changes, the page changes.

Keeping one bakery's data away from another's

This is a shared database, so tenant separation is the thing most worth being specific about.

• Row-level security is enabled and forced on every table in the public schema — all 233 of them — and the API roles have no grants on that schema.
• Queries that forget to name a company are refused, not widened. The data-access layer raises an error rather than returning rows across tenants. It fails closed: the bug becomes a visible error instead of a silent leak.
• This is tested against a real database, with two live tenants seeded and then deleted, rather than against mocks. A filter the database ignores looks correct to a mocked test.

Backups, and how long you would wait

The database is backed up daily, automatically, by Supabase. We also take our own nightly logical backup at 02:00 Pacific into storage we control, so a restore does not depend on a single vendor's console being available.

The recovery point is up to 24 hours. Point-in-time recovery is not enabled, which means a failure shortly before a daily snapshot would lose the work since the previous one. That is a cost decision, taken deliberately and recorded, not an oversight. If it is unacceptable for your business, say so — it is a setting, and it has a price.

A full restore has been rehearsed end to end, not assumed: the most recent drill completed in 157 seconds. We re-run it rather than trusting that last time still holds, because a restore that exits successfully can still produce a database with no users in it.

Who can reach what

• Access inside your account is controlled by roles and per-user permissions that your own administrators manage.
• Application credentials — database, payment, email and integration secrets — are held in Google Secret Manager and injected at run time. They are not in the source code, and a commit hook blocks credentials from being committed.
• Passwords are stored hashed, never in plain text. Support staff cannot read them, and neither can we.
• Administrative changes are written to an audit log recording who acted, on what, and when.

Your data is yours to take or remove

On request we will produce a complete export of your account as CSV files, one per table, with a manifest listing what was included and what was not. Credentials are withheld from the export — a password hash is not useful to you and is a risk in a downloaded file — and the manifest says so explicitly.

We will also erase your account. Erasure runs as a single transaction: it either removes everything or it removes nothing and reports the failure. A partial deletion that reported success would be the worst of the three outcomes.

Your rights, and how long we take to answer, are set out in the privacy policy.

Changes to the software

Every change runs through an automated test suite before it can deploy, and the build is blocked if the suite is not green. Database changes are applied through recorded migrations, and the deployed database can be compared against the repository to show whether the two agree — so "which version is actually running?" is a question with an answer.

No tracking

There are no analytics or advertising tags in this product. We do not sell or share personal information, and there is nothing here for an ad network to read. A test fails the build if anyone adds one, which is why the cookie notice is as short as it is.

What we have not done

This is the part most pages leave out, so it is worth being plain.

• We hold no third-party security certification. There is no SOC 2 report, no ISO 27001 certificate, and no PCI attestation to send you, because none exists. Anyone who tells you a company of this size holds one without an audit cycle behind it is describing an ambition.
• Card details never reach us. Payments are processed by Stripe, and card numbers go to Stripe directly rather than through this application. That is why PCI scope is narrow here — not because of anything we built.
• There is no 24/7 on-call rotation. We are small. Support hours and response expectations are what we agree with you, and we would rather tell you that now than during an incident.
• Point-in-time recovery is off, as described above.

Reporting something

If you believe you have found a security problem, email security@socialcarbs.com. Tell us what you found and how to reproduce it. We will confirm we received it and tell you what we are doing about it. We will not take legal action against someone who reports a genuine problem in good faith and gives us a reasonable chance to fix it before describing it publicly.

Questions this page does not answer, including security questionnaires: support@socialcarbs.com.