Security

1. Hosting & data residency

Customer data lives in the European Union, end-to-end:

• Database, authentication, and file storage on Supabase, region eu-central-1 (Frankfurt, Germany).
• Web hosting and edge functions on Vercel, pinned to fra1 (Frankfurt). Some platform telemetry transits the United States under EU Standard Contractual Clauses.
• DNS resolution via Cloudflare's global anycast network - no application data stored.
• Email via Heinlein Hosting GmbH (Mailbox.org) - Berlin, Germany.

2. Encryption

Data in transit is encrypted with TLS 1.2+ (HSTS-enforced; HTTP requests redirect to HTTPS). Data at rest is encrypted by the provider - Supabase uses AES-256 for both the database and file storage (photos and documents), with provider-managed keys.

3. Authorisation model

Every request that originates from a browser session runs through PostgreSQL Row-Level Security (RLS). Permission checks use a tier-based helper (has_farm_permission(farm_id, tier)) for owner_only / finance_access / write_access / any_member, applied at the database layer. The application UI is not the security boundary - even a forged client request cannot read data the RLS policy denies. A small number of trusted server-side paths use a service-role key that bypasses RLS: the scheduled retention jobs, the Stripe webhook, the health check, buyer-inquiry email routing, the token-authenticated calendar feed, the short-lived signed links that serve documents a seller has published on a sale page, and an operator-only admin dashboard. That key is server-side only, restricted by environment variable, and never reachable from the browser.

4. Audit log

Every successful mutation writes exactly one row to the activity_log table. The log captures who did what, when, and the diff. Routine entries are kept 24 months; security/legal/finance/membership entries are kept indefinitely. Soft-deleted rows on tables that support it (animals, events, tasks, etc.) are hard-deleted after 24 months - except the financial-records tables, which are kept ten years per Italian tax law.

5. Backups & recovery

The Supabase project is currently on the Free plan, which does not include automated backups or point-in-time recovery. A manual database dump command is available to the operator, but there is no scheduled backup and no off-site backup procedure today. Before paid plans launch the project moves to the Supabase Pro plan, which provides 7 days of daily backups; point-in-time recovery is a separate paid add-on that we will evaluate at that time. File storage is replicated within the eu-central-1 region. If backup guarantees matter to your evaluation, ask us and we will tell you exactly what is in place on the day you ask.

6. GDPR posture

We treat GDPR as a baseline product requirement, not a feature. Every AlpacaKeep user can export their core data sets as CSV (animals, events, shows, financial entries, fibre results), request rectification, and request erasure. The erasure flow includes a 30-day cool-off, then a hard delete via cascade. See our Privacy Policy for the full GDPR Art. 13/14 disclosure and our DSR procedure.

7. Responsible-disclosure programme

If you believe you have found a security vulnerability, please report it before disclosing publicly. We commit to acknowledging your report within seven calendar days and to providing a substantive response (fix, mitigation plan, or detailed reasoning) within ninety calendar days. Researchers acting in good faith - staying within scope, not accessing other users' data, not degrading the service - will not face legal action from us; we will work with you to fix the issue and credit you publicly if you wish.

8. Scope

In scope:

• alpacakeep.com and any locale or sub-path served from it (e.g. /it/...).
• Public anon-readable RPCs (notably get_public_animal).
• The signup, login, password-reset, and invite-acceptance flows.
• Customer data handling - RLS, IDOR, finance-access bypass, etc.

Out of scope:

• Sub-processor infrastructure (Supabase, Vercel, Cloudflare, Mailbox.org) - report directly to the provider.
• Findings that require physical access to a user's device.
• Best-practice issues without a clear security impact (e.g. missing security-headers on a static page, theoretical CSRF on a no-side-effect GET).
• Denial-of-service via volume - please don't.
• Social-engineering of staff, customers, or contractors.

9. How to report

Email security@alpacakeep.com with:

• A clear description of the vulnerability and its impact.
• Reproduction steps - ideally a minimal proof-of-concept.
• Your name and a way to contact you for follow-up. Anonymous reports are accepted but slower to triage.

We do not currently offer a monetary bug bounty. We are happy to credit you publicly in a security advisory or release note if you wish.