Security
Your evidence, your workspace, nobody else's.
Appfox handles store data, customer reviews, and sometimes your revenue. These are the boundaries it keeps, written the way they are enforced.
Isolated by default.Read-only by design.
Every workspace is walled off at the database, credentials never reach the browser, and every launch integration only reads. When data is unavailable, Appfox says so instead of guessing.
The six boundaries below are written the way they are enforced.
Workspace isolation
- Every tenant resource carries its workspace identity, enforced with Postgres row-level security and composite foreign keys.
- Role-aware membership with owner, admin, and viewer roles. A failed membership read is treated as unavailable, never as a default viewer.
- Authentication is handled by Clerk. Supabase remains the database and the enforcement layer; there is no second authorization system.
Credentials and provider access
- Integration credentials such as a RevenueCat key are stored in Supabase Vault, used server-side only, and never reach the browser.
- Connecting an integration verifies that the acting member is an owner or admin before any provider request is made. The persistence function rechecks that role independently.
- Provider inventory and metric reads are capped below each provider's documented rate limits, with bounded retries and exact handling of retry-after headers.
Read-only by default
- All launch integrations read. None write. Appfox drafts review replies and store copy for you to copy; it does not submit them.
- A public store URL is a declaration, not proof of ownership. Private resources bind only after server-side authorization through the connected account.
- External actions, when they arrive, require explicit approval and an audit trail.
Fail closed
- An unavailable read cannot appear as inactive access, zero spend, a disconnected integration, empty inventory, zero findings, or an ordinary role restriction.
- Controls that would start paid provider work stop when their history cannot be confirmed, so an outage cannot invite duplicate jobs.
- Required-read classification makes database errors take precedence over stale or partial data for every authenticated mutation.
Observability without payloads
- Provider calls emit a strict record with latency, result and unit counts, bounded cost, retry metadata, cache status, and safe error codes.
- Identifiers, payloads, credentials, URLs, and raw error text are excluded from those records.
- Web request and authentication failures are logged in a safe structured form. Background failures go to a durable alert outbox.
Retention, deletion, and recovery
- Explicit retention windows. Owner deletion removes workspace data and is Vault-aware.
- Replay sessions are masked on the device before upload, retained for a fixed window, and deleted with their storage objects.
- A logical backup and restore rehearsal runs in hosted CI as a release gate.
What we do notclaim yet.
Real pilot outcomes, authenticated end-to-end tests against production, and authorized live-provider checks are release evidence, not marketing claims. We publish them when they exist.
Report a security issue
Email us with the subject line Security. We respond to every report.
hello@appfox.appPrivate beta
Build your next release with a clearer picture.
Research your idea, understand your reviews, and follow your competitors. Request an invitation to the Appfox private beta.
Invitations are sent by email.