RingUps keeps each store's records in a Postgres database hosted by Supabase in the ca-central-1 region, so Canadian store data stays in Canada, with daily backups. One boutique cannot read another boutique's brides, because that rule is enforced by the database rather than by application code. RingUps never holds card details, and every store can export all of its own data at any time.
Most shared software keeps stores apart in application code. Every query the software writes carries a clause meaning "only rows belonging to my store", and the separation holds for exactly as long as every query remembers to carry it. There are hundreds of queries. One of them forgets, on one screen, in one release, and a store sees data that is not its own. This is the ordinary way tenant leaks happen, and it is almost never malicious.
RingUps puts the rule underneath the application instead. Row-level security is a feature of Postgres, the database itself, and it is enabled on 53 tables. Every policy on those tables is written against one shared helper, current_org(), with 145 policy references pointing at it. That means there is one rule to get right rather than dozens scattered through the code.
A bug in a query cannot leak another store's brides, because the database itself refuses to return them.
Isolation is checked by a script rather than described in a slide. verify-rls.sql simulates a signed-in user the way Supabase does at runtime, by setting the authenticated role and a JWT subject claim, then reads the org-scoped tables and asserts that each owner sees only their own store. A second fixture store cannot read, update, delete or insert into the first. The whole thing runs inside a transaction that is rolled back.
There is one deliberate path across the boundary, the marketplace, and it is a narrow function with an explicit column list rather than a relaxed policy. The isolation rule is never widened for a feature's convenience. How the marketplace handles identity.
That sentence is the point of the whole page, so it is written without hedging. The same row-level policies that stop one boutique reading another apply to the people who build RingUps.
RingUps runs an internal platform console to provision stores and keep the service running. Membership of it is a separate admin table, it is not a screen a boutique owner ever sees, and it is not part of any plan. It appears on this page because it is a trust proof rather than a product feature, and because a security page that describes only the customer-facing half of a system is not describing the system.
Setting up a new store is a concierge script run with a service-role key, and a service-role key bypasses row-level security by design. That is stated here rather than left out. It exists to create a store, not to browse one, and no code path inside the application can create an owner account. Anyone who tells you their system has no privileged key has not looked.
Your client data is never handed to an outside company to learn from. The drafting features read your own records to produce a first draft and stop there, and they run only where a store has provisioned its own key for them. See where drafting is used.
The short version is one country, one database, one payment processor that RingUps does not stand in front of. The long version is the table.
| What | Where | Detail |
|---|---|---|
| Your store's database | Supabase, ca-central-1 | Postgres, hosted by Supabase in the Canadian region. Canadian store data stays in Canada. |
| Backups | Daily | Taken daily against that database. Backups age out on their own schedule, and we will give you the current windows in writing. |
| Separation between stores | 53 tables | Row-level security in Postgres, with 145 policy references to one shared current_org() helper. |
| Card details | Never held | RingUps does not store card numbers. Card processing runs through Stripe, and the result comes back to RingUps on a webhook whose signature is verified before anything is recorded. |
| Encryption | In transit and at rest | Both, on the database and on stored files. |
| Everything else | On request | Email delivery and a small number of other services sit alongside the database and not all of them are Canadian. RingUps keeps a current sub-processor list and will send it in writing. Ask before you sign rather than after. |
Brides, orders, payments, appointments, inventory and the gown catalogue come out in full, at any time, self-serve, without a ticket and without an exit fee. The exports are generated by the same functions the screens render from, so a download cannot quietly disagree with what you were looking at.
The second half of that sentence is the part worth publishing. If the company winds down, you still get your data. It is written on a public page rather than left to a clause nobody reads, because a store that cannot leave has not chosen anything.
You can correct or delete records yourself inside the app while you are a customer. If you close your account, RingUps keeps the data for a short wind-down window so you can export or change your mind, then deletes it. Backups age out on their own schedule. Some records are kept longer where tax or accounting law requires it. Ask for the current windows in writing and you will get exact numbers rather than a paragraph. The full statement is on the privacy page.
Not everything should be deletable by whoever is standing at the counter, and the guards are in the database rather than in the app: payments cannot be deleted, ledger entries cannot be rewritten, a signed contract is frozen with a SHA-256 hash over its own snapshot, and a customer carrying financial history cannot be deleted at all. When a bride disputes what she was told, the record shows who did what and when, including the exact version of the terms she signed.
Plenty of boutique owners forward a security page to a family member who works in software, or to the accountant's IT contractor. This section is written for that reader, without the marketing layer, and it is the same set of facts we would give on a call.
The formal version of this page: what is collected, who processes it, the sub-processor list and the retention windows.
Which roles exist, what each one can reach, and what happens the day someone leaves mid-season.
How data comes in from your current system, what gets reconciled against it, and how an import is reversed.
In a Postgres database hosted by Supabase in the ca-central-1 region, which is in Canada, with daily backups. RingUps itself is built in Kelowna, British Columbia. Not every service RingUps uses sits in Canada, and email delivery is a separate provider, so the current sub-processor list is available in writing on request. Ask for it before you sign rather than after.
No. We cannot read your brides. The RingUps-internal platform console is used to provision and support stores, it is not a screen a boutique owner ever receives, and the same row-level policies that stop one boutique reading another apply to the RingUps team. The one deliberate exception is the service-role key used by the store provisioning script, which bypasses row-level security by design and exists to create a store rather than to browse one.
By row-level security in Postgres, not by application code remembering to add a filter. Row-level security is enabled on 53 tables, with 145 policy references to a single current_org() helper, so there is one rule to get right rather than dozens. A bug in a query cannot leak another store's brides, because the database itself refuses to return the rows.
You export it, in full, at any time, without asking first: brides, orders, payments, appointments, inventory and the gown catalogue. That promise holds if the company winds down. Every customer gets a full export of their own data, and it is published here rather than kept in a drawer so that you can hold the two founders to it.
By email, from the two founders, to the stores affected, followed by a written explanation of what happened. RingUps does not publish a status page today and this page will not link to one that does not exist. You should never learn about downtime from a bride standing at your counter.
Ask what happens if we are acquired, if you leave, or if the software is down on a Saturday. Book a fifteen-minute demo on your own data and you will get a straight answer from the people who built it.