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, Vercel object storage uses provider-managed encryption keys.
3. Authorisation model
Every database query 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. Service-role access (used only by webhooks and cron) is 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
Supabase performs continuous point-in-time backups for the database; on the current Hobby plan the recovery window is 24 hours. Once the project upgrades to the Pro plan, the recovery window extends to 7 days. File storage is replicated within the eu-central-1 region. We have no off-site backup procedure today; this will be revisited at billing-live.
6. GDPR posture
We treat GDPR as a baseline product requirement, not a feature. Every Alpacakeep user can export their full data set as JSON, 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.