Security

Hosting and infrastructure

• Web app: Next.js on Vercel. Vercel handles edge routing, TLS termination, and CDN.
• Database and auth: Supabase (managed database and Supabase Auth) on AWS, region us-east-2 (Ohio, United States).
• Background workers: Temporal workflows running in containers on Google Cloud Run, orchestrated by Temporal Cloud. Workflow payloads pass through Temporal Cloud in transit; the workers — not Temporal Cloud — hold customer data at rest.
• Secrets management: Production secrets are stored in Infisical and made available to Vercel at runtime. Privileged database credentials are never exposed to the browser.

Multi-tenant isolation

Ripenn is a multi-tenant application. Tenant boundaries are enforced at the database layer by row-level security (RLS) policies on every table containing customer data — not by application-layer filters that could be bypassed by a bug.

The same RLS policies apply uniformly to:

• API calls from the web application
• Background workers running Temporal workflows
• Queries from the Ripenn CLI authenticated by a Bearer JWT
• Direct queries from the Supabase dashboard by authorized engineers

A leaked or misused authentication token cannot read rows it does not own. The privileged credential that bypasses row-level security is held only on the server side and is never exposed to the browser.

Encryption

• In transit: All traffic to ripenn.ai uses TLS 1.3, terminated at Vercel. The www host 308-redirects to the apex.
• At rest: Database encryption is provided by Supabase on AWS using AES-256. See Supabase's security overview for the underlying details.

Authentication and access

User auth. Supabase Auth with email/password and OAuth (Google). Sessions are stored in HTTP-only secure cookies. Ripenn's sign-in form is gated by Cloudflare Turnstile to prevent credential stuffing and automated sign-up abuse.

API auth. Every non-public API route requires a valid Supabase session cookie or a Bearer JWT (used by the Ripenn CLI). Authorization is enforced by row-level security on every table containing customer data.

Internal access. Production database access is limited to one engineer (the founder). Access is granted through the Supabase dashboard, not through standing SSH or psql credentials. Access review cadence: quarterly.

Multi-factor authentication. MFA is offered via Supabase Auth and is enforced today for the founder's administrative accounts on Supabase, Vercel, GitHub, and Stripe. Customer-facing MFA enforcement is on the roadmap; see “What Ripenn does not yet have” below.

Application security

• Dependency scanning: GitHub Dependabot is enabled on all Ripenn repositories; security advisories are reviewed weekly.
• Secret scanning: GitHub secret scanning runs on every push. CI fails on detected secrets.
• Code review: All production deploys originate from pull requests in the main branch.
• Static analysis: TypeScript strict mode in the application code; all database queries are parameterized (no string-concatenated SQL).
• Security headers: TLS-only via HSTS, Content-Security-Policy, X-Frame-Options, and X-Content-Type-Options applied at the Vercel edge.
• Rate limiting: API routes that touch external AI providers are rate-limited per workspace to prevent runaway cost and abuse.

Logging and monitoring

• Infrastructure logs: Vercel function logs, Supabase database logs, Cloud Run container logs, and Temporal Cloud audit logs are retained by their respective providers per platform defaults.
• Product analytics: PostHog (US cloud) captures page views, feature flag evaluations, and identified user events.
• Authentication events: Sign-in attempts and Supabase Auth events are logged in Supabase and reviewed when investigating incidents.

Backup and recovery

• Supabase performs automated daily database backups, retained for 7 days on our current Pro plan.
• Source code is mirrored on GitHub. Infrastructure is redeployable from the repository plus Vercel and Cloud Run configuration.
• No formal RTO/RPO is published today. Backup restoration has not been tested under production-incident conditions; doing so is on the roadmap.

Incident response

Ripenn maintains an internal incident response process. If a security incident affects customer data, we will:

1. Contain the incident and preserve evidence.
2. Investigate scope, root cause, and affected accounts.
3. Notify affected customers without undue delay, and in any case within 72 hours where required by applicable law (GDPR Article 33/34).
4. Provide a written post-incident summary describing what happened, what data was affected, and what we changed in response.

The customer-facing contact for security incidents is support@ripenn.ai.

Vulnerability disclosure

To report a security issue, email support@ripenn.ai. Include reproduction steps and the affected URL or endpoint.

• Acknowledgment SLA: 3 business days.
• Fix SLA for confirmed high-severity issues: 14 days.

We do not currently operate a paid bug-bounty program, but credit reporters in a public hall-of-fame on request.

Employee and contractor practices

Ripenn currently operates with a single full-time employee (the founder). All production credentials are held by the founder. When contractors are granted access (typically for code review or specific implementation work), access is scoped to specific repositories or environments and revoked at engagement end. All work devices use full-disk encryption and an OS-level password manager; production credentials are never stored in plaintext.

Subprocessors

The third parties that hold customer data are listed on the Subprocessors page. The model providers used for audit runs are documented in detail on the Data Usage page.

What Ripenn does not yet have

Stating these openly is more useful than implying they exist.

• No SOC 2 audit. Ripenn has not begun a SOC 2 process. When that changes, this line will too.
• No ISO 27001 certification.
• No published penetration-test report. Available under NDA for enterprise customers on request.
• No bug-bounty program. Reports are welcome at support@ripenn.ai.
• No self-serve account deletion. Account-level deletions are processed by emailing support.
• No enforced customer MFA. MFA is available via Supabase Auth and is enforced for administrative accounts; customer-side enforcement is on the roadmap.
• No formal RTO/RPO. Backup restoration has not been tested in production-incident conditions.