Security

1. Hosting & data residency

Where customer data is stored and processed:

• Database, authentication, and file storage on Supabase, region eu-central-1 (Frankfurt, Germany).
• Web hosting and server functions on Vercel, pinned to fra1 (Frankfurt). Public pages that are the same for every visitor, such as the guides, are also cached on Vercel's global network. Some platform telemetry transits the United States under EU Standard Contractual Clauses.
• DNS resolution via Cloudflare's global anycast network. No application data is stored there.
• Account and notification emails via Heinlein Hosting GmbH (Mailbox.org), Berlin, Germany.
• If you use an AI feature (certificate reading, or Ask your herd in its closed test), what that feature needs is sent to Anthropic, which stores it in the United States and may process it in any region it uses. See the Privacy policy, Section 7.
• If you subscribe to the newsletter, your email address is used by Resend to send it. Resend stores account data in the United States, under the EU Standard Contractual Clauses. No farm data goes to Resend.
• If you choose Continue with Google, Google handles that sign-in as its own controller. It is not one of our sub-processors.

2. Encryption

Everything between your browser and AlpacaKeep travels encrypted (TLS 1.2 or newer). Unencrypted requests are redirected to the secure address, and the site tells browsers to use only the secure address (HSTS). Stored data is encrypted by our database provider, Supabase, with AES-256. Uploaded photos and documents are stored in the same Frankfurt region as the database.

3. Authorisation model

Every request from a signed-in browser session runs through PostgreSQL Row-Level Security (RLS): the database itself checks, row by row, whether your role on that farm allows it. There are four tiers: owner only, finance access (Owner and Co-Owner), write access (adds Farmhand) and any member (adds Viewer). Most policies use the helper my_farm_ids(tier); file storage and database functions use has_farm_permission(farm_id, tier). The app's screens are not the security boundary: even a forged request cannot read data a policy denies.

Some server-side tasks use a service-role key that bypasses RLS, because they act without a signed-in session or work across two farms. Each one makes its own check first, such as a shared secret, a payment signature, the signed-in person's role, or a rate limit. They are:

• Scheduled nightly jobs: retention clean-up, account erasure after its waiting period, plan expiry and the emails that go with it, storage housekeeping, and a daily summary for the operator.
• Billing: the Stripe payment webhook, linking a farm to its Stripe customer, and recording a cancellation or withdrawal, including the public withdrawal form.
• The health check used by our uptime monitor.
• The record of sent emails that every outgoing email passes through, so that sending limits hold.
• Buyer inquiries: taking in an inquiry from a visitor, the buyer's conversation by emailed link or buyer account, the seller's notification address, and showing a farm's phone number on request.
• Public pages for visitors who are not signed in: short-lived signed links for documents a seller has published on a sale page, and the public herd page, website widget and read-only public API.
• Animal transfers between two farms: copying the transferred files from the seller's storage and refreshing the seller's public pages.
• AI features: recording the result of certificate reading and of Ask your herd, after the signed-in request has been checked.
• Newsletter and early-access sign-ups.
• The operator's admin console, which needs an authenticator-app code (see section 7).

The key exists only on the server and is never sent to the browser.

4. Audit log

Every change saved in the app writes an entry to the activity_log table: who did what and when, with the changed fields or the context of the change. Routine entries are kept 24 months; all other entries (security, legal, finance, membership and the animal register) are kept while the farm exists and deleted with it. Most records you delete (animals, events, tasks and similar) are permanently removed 24 months later, with these exceptions: financial entries, and animals still linked to financial or breeding records, are kept until the farm is deleted; an animal with a movement from the last 3 years is kept until that movement is 3 years old; an animal with a medicine treatment from the last 5 years is kept until that treatment is 5 years old. Documents and movement records are kept until you delete them or the farm is deleted.

5. Backups & recovery

The Supabase project is on the Pro plan, which takes a daily backup of the database and keeps the last 7 days of them. These backups cover the database, not the files you upload (photos and documents). Point-in-time recovery is a separate paid add-on that is not enabled today, so a restore goes back to the most recent daily backup. There is no off-site backup outside Supabase today. 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 member of a farm can export its animals, events, shows, fibre results and herd register as CSV files; Owners and Co-Owners can also export the financial entries. Anyone can ask us for a full copy of their data, ask for corrections, or ask for their account to be erased. Erasure has a 30-day waiting period in which you can change your mind. After that, a farm you own is deleted with all its records (if other people still work on it, you first pass ownership to one of them); on a farm someone else owns, the records you entered stay, without your name. A few records are kept by law or as proof, as listed in the Privacy policy, Section 8. The Privacy policy also has the full GDPR Art. 13/14 information and how we handle your requests.

7. Accounts & website protections

How accounts, sign-in and the website itself are protected:

• Passwords need at least 10 characters, including a number.
• A new account has to confirm its email address before the first sign-in, and a change of email address has to be confirmed too. Opening a link in one of our emails never uses it up by itself, so automatic mail scanners cannot spend it: you confirm with a button on the page, and every email also carries a code.
• Sign-in sessions are kept in cookies that scripts on the page cannot read.
• The public forms (buyer inquiries, showing a farm's phone number, the withdrawal form) are rate-limited.
• The operator's admin console needs a code from an authenticator app on top of the password, asked again every 12 hours. Codes by text message are not offered.
• When the operator opens a farm in the admin console, for example to help with a support request, that access is logged, and the log is kept for at least 24 months.
• The website sends standard browser security headers: other sites cannot show our pages in a frame (except the website widget, which is made for that), browsers may not guess file types, and other sites do not receive full page addresses from us. There is no site-wide Content Security Policy for now. That is a deliberate decision: framing by other sites, the main risk such a policy would cover here, is already blocked.
• Errors are reported to the operator automatically, and those alerts contain no customer data.

8. 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.

9. Scope

In scope:

• alpacakeep.com and any locale or sub-path served from it (e.g. /it/...).
• Public pages and the anon-readable functions behind them: sale pages, the public herd page, the website widget and the read-only public API (notably get_public_animal).
• The signup, login, password-reset, and invite-acceptance flows.
• Customer data handling: RLS, IDOR, finance-access bypass and similar.

Out of scope:

• Sub-processor infrastructure (Supabase, Vercel, Cloudflare, Mailbox.org, Resend, Anthropic): please 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 by sheer volume. Please don't.
• Social-engineering of staff, customers, or contractors.

10. 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.