Built to be trusted with real business data

Every table that holds business data carries Postgres Row-Level Security policies. A query from one workspace physically cannot return another workspace's rows — the database refuses, regardless of what the application code asks for. This is not an application-level filter that a bug could bypass; it is enforced by the database engine itself.

These policies are covered by an automated regression suite that runs against a real database and asserts, for every table, that workspace A cannot read or write workspace B's data. New tables ship with their isolation tests.

Owner, admin, and member roles are enforced by the same database policies — a member cannot promote themselves, change billing settings, or touch admin-only tables, because the database rejects the write, not just the UI.

Every significant operation is recorded in an append-only audit log: who did what, and when. Entries are written server-side and cannot be edited or deleted from the application.

All traffic between your browser, BaseBlock, and the database travels over HTTPS/TLS. At rest, data lives in Postgres hosted by Supabase, which encrypts stored data at the infrastructure level. Passwords are handled by Supabase Auth and stored only as salted hashes — BaseBlock never sees or stores a plaintext password.

Your database runs in AWS ap-southeast-1 · Singapore, and the application that queries it runs in Vercel sin1 · Singapore — deliberately in the same region, so a page load does not pay a round trip across an ocean to fetch its own rows. Requests enter at the nearest edge — for Nepal that is normally Mumbai — and execute in Singapore, beside the database.

Nothing about your workspace is replicated to a region outside that, and no data is sold, shared, or sent anywhere for training. Where a feature does leave our infrastructure — an AI draft, an SMS, a courier booking — it is because you connected that service yourself, and it is named on the page where you connected it.

Files attached to your rows are stored in a private bucket — there are no public URLs. Access goes through short-lived signed links generated per request, only for signed-in members of the owning workspace.

Online payments on your published site run through your own eSewa, Khalti, or Fonepay merchant account. BaseBlock never holds your money and never processes card data. Your gateway credentials are stored per-workspace, used only server-side to initiate and verify your own transactions, and are never exposed to browsers or other workspaces.

The same model applies to email and SMS automations — they send through provider credentials your business supplies, so your customer communication never routes through a shared BaseBlock account.

Frequency

Daily, automated, at the database level.

Retention

Seven days of daily backups on the current infrastructure plan.

Point-in-time

Point-in-time recovery — rolling back to a specific minute rather than a specific night — is a paid tier we have not bought yet. When we do, this line changes.

Your own copy

Any table exports to CSV at any time, from the table's own toolbar. No ticket, no waiting on us.

Backups are run by the infrastructure, not by BaseBlock, and we would rather say so than imply we operate a system we do not. The line that matters more is the last one: your data is never locked in. Any table exports to CSV on demand, and deleting a workspace removes all of its rows across every table through database cascades.

BaseBlock holds no formal certification yet, and none is claimed anywhere on this site. What exists today is the engineering groundwork those audits examine. What is planned carries a date, because "on the roadmap" with no date attached is a way of saying nothing.

• In placeDatabase-enforced tenant isolation

  Row-Level Security on every table holding business data, with an automated regression suite that fails if one workspace can reach another's rows.

• In placeEncryption in transit and at rest

  TLS on every connection; storage encrypted at the infrastructure level by AWS and Supabase.

• In placeAppend-only audit log

  Every significant operation records who did it and when. Written server-side, and not editable from the application by anyone.

• In progressDocumented incident response and breach notification

  A written runbook: who is paged, how an incident is classified, and a commitment to notify affected workspaces within 72 hours of confirming a breach.

  Target: December 2026

• PlannedSOC 2 Type I

  A readiness assessment first, then an observation window with an independent firm. We will publish the engagement date when it is signed, and the report itself under NDA on request once it exists.

  Target: Engagement signed by June 2027

• PlannedISO 27001

  Follows SOC 2. Not started, and claimed nowhere on this site until it is.

If a date here passes without the item moving, that is a fact about us worth knowing, and the page will say so rather than quietly gaining a new date.