How we protect your site, your data and your customers.

Your account, your business, your site's content and everything your site stores — members, orders, bookings, uploads — live in a single PostgreSQL 17 database, run by Supabase on AWS in us-east-2 (Ohio). Authentication and file storage are the same project, same region.

The Helm app, the studio and every site we build for you are served by Vercel. Your published site is a static build plus a small set of API routes; it holds no database credentials of its own.

In transit: helm.biz and every site we publish are served over TLS with HTTP Strict Transport Security (two-year max-age); plain HTTP is answered with a permanent redirect to HTTPS, never with content. The application talks to the database only through its HTTPS APIs — there are no direct Postgres connections from the app tier — and the database itself enforces TLS, refusing any client that tries to connect without it.

At rest: database volumes and backups are encrypted by the provider (AES-256). Secrets you hand us to connect your own vendors — API keys, OAuth tokens — are additionally encrypted by Helm with AES-256-GCM before they are written, and are decrypted only on our server at the moment they are used. They never cross the wire to a browser.

Sessions: sign-in state lives in HttpOnly, Secure cookies — not in URLs, where it would land in logs, browser history and forwarded links.

Your site's data routes take two things: which build is asking (resolved server-side to your business) and who is signed in (resolved server-side from the session cookie). There is no owner parameter, no tenant id in the request — by construction, a client cannot name a scope it does not hold.

In the database, every table the API roles can reach has row-level security enabled. Tables without it are reachable only by the server's own role, never by a public key — and no database key is shipped to any browser or any built site.

Membership is Helm's to run. Whether a person is a paid member of your site right now is a status your site reads. The entitlement endpoint has exactly one operation and it is a read; there is no verb a site could call to grant itself a member. A membership is written only from a verified payment reference on your own Stripe account.

Each build gets its own E2B sandbox: a fresh microVM with its own filesystem, its own process space and its own network, created for that build and named by its job. The generated code is installed, compiled and exercised there. The sandbox runs on a 30-minute lease and is killed when the build finishes or the lease lapses, whichever is first.

What survives the sandbox is the built output and the source, written to your project's storage. The sandbox itself does not.

Selling on your site uses Stripe Connect: you connect your Stripe account, and each visitor who buys is sent to a checkout session minted on that account. The money settles with you. Helm reads the completed payment back from your account to record the membership or the order, and that is the whole of our involvement — there is no platform fee, no application fee, no cut.

Card numbers are entered on Stripe's hosted checkout and never pass through a Helm server. Your Helm subscription is billed the same way, by Stripe.

Account → Your site → Download your code streams a zip of your site's source and its built output, assembled in memory from the stored artifacts. It is available on every plan, including free, and the stored objects are kept when a site is taken down — so the download works on the day it matters.

The export runs a secrets guard before it leaves: if a file that must not leave Helm — a key, a credential — is found in the bundle, the export is refused and we are told. The fix is ours, never yours.

Nothing that identifies you or authenticates you is placed in a query string, where it would be logged by every proxy, cached by every browser and copied into every forwarded link. Sessions are cookies; a sign-in link from us is single-use.

When our team checks a customer's site the way a customer would, it does so on a single-use ticket that is bound to one build, one seat and one role, expires within sixty seconds, and can neither be replayed as a different person nor promoted to a staff seat. Every door we have — the internal console, its API, and the sign-in doors our own QA uses — refuses a credential presented in a URL outright: it is stripped without ever being compared — even from a visitor who is already signed in — and there is no function left in the codebase that can read one out of a query string.

Helm builds the platform; it does not fund your customers' usage. Where a capability serves your site's own users — generation on demand, for instance — the vendor key is yours, connected once in your account and reused across every site you build. It is stored encrypted, decrypted only on our server at the moment of the call, and shown to you only as a mask.

The database is snapshotted daily by the provider and the seven most recent snapshots are retained, encrypted, in the same region. A restore returns to the most recent daily snapshot.

What we do not have yet: point-in-time recovery, which would allow a restore to any second in the last week rather than to the last nightly snapshot. It is on our roadmap; until it is on, this page will keep saying “daily”.