Trust center · Current state

Your workspace is the boundary, and the money never passes through us.

A control-by-control account of how one workspace is held apart from every other, how a published site charges cards on the merchant’s own Stripe keys, and where our claims stop.

StatusCurrent state · checked against the running serviceEffectiveApplies toNaratake browser SaaS

01 · Readiness at a glance

Three states, kept separate.

Implemented

Application boundaries

Workspace-derived authorization, tenant-scoped persistence contracts, bounded archive and image validation, immutable revisions, same-origin mutation checks, publish eligibility gating, rollback state, and a credential vault the web application itself cannot decrypt are in code and covered by automated verification.

Conditional

Provider-backed controls

Clerk identity, Postgres roles and row-level policies, private object storage, Stripe billing, and the build and deployment lane are configured in production, and the service re-reads that configuration rather than trusting the deploy that set it. Anything missing or malformed fails closed: a plan cannot be sold unless the payment can also grant what was bought, and a site cannot go live unless a worker has recently passed its own self-test.

Not claimed

Outside the application

Independent security assessment, a rehearsed restore with a measured recovery time, and incident-response commitments are not claimed on this page. What is claimed is the list to the left, and every line of it is in the shipped code.

02 · Identity and authorization

Provider identity does not choose the application role.

  • Clerk authenticates the user and the active organization, and the production runtime carries the identity keys that check requires.
  • An application session requires an active workspace and an exact database membership for that user.
  • Database roles are authoritative: owner, admin, designer, operator, and viewer have distinct permissions.
  • Provider organization roles are ignored for ordinary authorization; the first-owner provisioning path is a narrow exception.
  • Studio routes and APIs are identity-protected by default. There are two named exceptions: the signed Stripe webhook POST, and the readiness endpoint at /api/health/ready, which is deliberately public — it reports whether the platform can serve a customer right now, it carries no customer data and no credential, and a watchdog checks it every fifteen minutes. Open it yourself.
  • The local development bypass requires development mode, explicit flags, and a host that is loopback or ends in .localhost.

A workspace has a single owner, so team invitations, membership synchronization, role-change automation and audit events are outside the scope of this page.

03 · Tenant data boundaries

The browser cannot nominate a workspace target.

Project and asset routes obtain the workspace identifier from the authenticated server session. The URL carries a project or asset identifier, but not an authoritative tenant target. The durable database design uses a non-bypass application role and installs workspace scope inside transactions before tenant queries.

Project documentsImmutable revisions use tenant- and project-scoped references plus server-computed SHA-256 and byte size.
AssetsPrivate objects are served through authenticated routes; storage credentials and direct private provider URLs stay server-side.
QuotasProject, storage, immutable revision, upload-rate, and concurrent-write ceilings are enforced as abuse controls.
Deletion fencingLogical removal enters delayed, reference-aware cleanup; physical deletion is an idempotent worker responsibility, not request-time work.

The reviewed migrations enable and force row-level security on every tenant table the application role can reach, and workspace scope is installed transaction-locally before any tenant query runs. Confirming that the deployed database role carries no bypass privilege is an operational check against the production Postgres service, not a property the application can prove about itself.

04 · Request and file safety

Untrusted input meets a bounded boundary.

  • State-changing browser routes require an authenticated role and an exact same-origin request.
  • Save requests use strong version preconditions and idempotency keys; stale writes are rejected instead of silently overwriting a newer revision.
  • Project archives are inspected for canonical paths, one project document, entry count, decompressed size, compression ratio, JSON complexity, schema support, and matching project identity.
  • Cloud images are capped, stream-bounded, and accepted only when declared type and magic bytes agree for supported raster formats.
  • Server-computed hashes are checked before stored project bundles or assets are returned.
  • Missing durable database or private object storage configuration returns an unavailable response; production does not fall back to browser or in-memory persistence.

05 · Publishing safety

Unsupported work stops before promotion.

Go live binds a request to one immutable reviewed revision. Eligibility is computed from the authored components, their required modules, and relevant delivery swaps. A Naratake project is a full application with a database behind it: the full delivery provisions that database and its back office and is sold on the Pro plan; the storefront delivery is the same site with the write-side removed, and the removal is named in the publish report. Which one a workspace may request is decided by its entitlements inside the submit transaction, not by the client.

  1. 01
    Freeze

    Bind the request to the exact revision and its server-verified project bundle.

  2. 02
    Build away from production

    Create a bounded release artifact through the worker contract.

  3. 03
    Verify

    Check the immutable result and release state before changing the stable pointer.

  4. 04
    Promote or roll back

    Retain release history so a prior verified release can be selected.

The full delivery provisions the site its own database and back office, so the orders, reservations, appointments, customer records, and lead capture a visitor submits are stored. It is granted only to a workspace whose plan carries both the commerce and bookings modules. The storefront delivery publishes the same site without the parts a visitor writes to, and every removed section is named in the publish report. Card payments on a published site run on the merchant’s own Stripe keys, read from the workspace credential vault at publish time and written into that site alone; both halves must be present and in the same mode or the site publishes with no checkout rather than a broken one. Naratake never holds that money and takes no commission on it, though Stripe’s own card fee applies the way it would anywhere. A custom domain you already own is connected on either plan, one domain per plan, with HTTPS issued for it.

06 · Billing boundary

Billing is configured in production, and it fails closed.

The browser chooses only an approved price alias. The server maps it to Stripe, creates canonical return URLs, and records a durable idempotency claim before the provider call. The exact Stripe webhook route reads a bounded raw body, verifies its signature and expected API version, and processes duplicate or out-of-order events through durable claims and cursors.

Provider customer, Checkout, and subscription identifiers use a dedicated narrow billing role; ordinary workspace database credentials cannot reach the global billing claim tables. In production the plan catalog and its Stripe price mapping resolve, checkout is configured for its mode, and the webhook signing secret is present. The running service checks all three and reports itself unready if any one of them is missing, because a runtime that can charge a card but cannot grant what was bought is the failure most worth refusing. An hourly sweep re-reads money-affecting webhook decisions the pipeline declined to apply, and it fails while any of them are still outstanding.

07 · Where our claims stop

No trust badge ahead of the evidence.

No SOC 2 or ISO 27001 certification. The controls above are ours to show you, not an auditor’s to attestNo PCI certification claim by Naratake. Card numbers are entered on Stripe-hosted pages, so no Naratake form ever receives oneNo external penetration test and no public bug-bounty program. Reports reach the engineers who wrote the codeNo encryption certification. Stored provider credentials are sealed with AES-256-GCM and bound to the workspace they belong to, but that is our implementation rather than a certified programNo verified restore. Encrypted database dumps are scheduled daily and kept outside the database provider, and each one is checked for readability, but no restore has been rehearsed, so we quote no recovery timeNo uptime or incident-response SLA. We publish no availability figure we have not measuredNo one-click account or workspace deletion. A deletion request is verified by email against workspace authority before anything is removedOne custom domain on either plan, connected to a domain you already own; no promise of an exact activation time, because DNS and certificate issuance sit with the registrar and the hostNo independently audited production payment. The money path is covered by automated tests and by the configuration checks above, but no outside party has traced a live charge through itNo holding of merchant money. Card payments on a published site run on the merchant’s own Stripe keys and settle into the merchant’s own account. We take no commission on them, and Stripe’s own card fee applies the way it would anywhereNo AI usage sold and no model of our own. Both cloud plans deny AI generation outright, and the browser Studio holds no provider key. The drafting assistant belongs to LocalSite Studio on the desktop: with your own Anthropic, OpenAI or DeepSeek key — kept in that machine’s operating system keychain — the request travels from your machine to the provider, and no prompt of yours reaches us. The exception is the allowance a desktop license includes, which by definition has no key to use: those calls do pass through our license server, which forwards them under our own account and keeps a per-license monthly count rather than a copy of what was sent

Production runs over HTTPS, and transport and storage protections rest on the providers we configure and keep re-reading. Naratake presents that as engineering we can show you, not as an independently certified encryption program.

08 · Customer responsibilities

Security is also a workspace practice.

  • Protect the identity-provider account and use multi-factor authentication when the provider offers it.
  • Assign the least-privileged application role and remove access when a person no longer needs the workspace.
  • Do not paste credentials, private keys, customer secrets, or raw card data into page copy, project notes, support mail, or public assets.
  • Review every release, link, form, policy, integration, and public business fact before promotion.
  • Keep an independent copy of critical source content until a restore has been rehearsed and a recovery time published.
  • Report suspected account, workspace, or published-site compromise promptly.

See the Privacy Notice for data handling and the Service Terms for acceptable use and launch responsibility.

09 · Report an issue

Give us enough detail to reproduce safely.

Email a concise report with the affected Naratake URL or surface, impact, reproducible steps, and a safe proof of concept. Do not access another customer’s data, disrupt service, exfiltrate content, run denial-of-service tests, or include live credentials and sensitive personal information. Reports go straight to the engineers who wrote the code. There is no public bug-bounty program.

Security reportssupport@naratake.comUse the subject “Security report for Naratake” — the email link above fills it in automatically. If the report itself is sensitive, ask for a secure transfer method first.