Effective date: May 12, 2026 · Version: v1.2
Vibehaus is a developer tool that runs on your Mac. The encrypted vault and notes you sync to our servers are unreadable by us — we hold the ciphertext, your devices hold the key. We try to collect as little as possible, and we tell you exactly what we have.
The short version: we know your email address (so you can sign in), the paths and names of the projects you sync (because the sync request has to identify “which project”), and your subscription state from Stripe (so we know whether you’re on a paid plan). We don’t know your secrets, your notes, or what’s inside your projects.
Your data lives in Supabase (Postgres, eu-central-1 / Frankfurt) and Stripe (US-based payment processor). The master encryption key for your vault and notes lives in your iCloud Keychain — never on our servers.
You can sign out at any time, which clears local state on that device. You can delete your account by emailing us; we describe what gets removed below.
Vibehaus is operated by Alp Yaprak as a sole proprietor based in Turkey. We’re the data controller for the personal data described in this policy.
Contact: info@alpyaprak.com. A postal address is available on request via the contact email.
auth.users). Regular accounts sign in with Apple ID (Sign in with Apple). Admin accounts sign in with email + password; password-recovery emails are delivered through Resend (see section 8).public.vault_items. Each row is an AES-256-GCM ciphertext blob with a per-item nonce. We cannot read these.public.notes. Same encryption model as vault items. We cannot read these.public.project_metadata (port, tags, flow steps, custom notes). Encrypted with your master key under the same AES-256-GCM model as vault items and notes; we cannot read it either.vault_items and notes rows carry a plaintext project_path so the sync protocol knows which project a row belongs to. This is unavoidable for indexing. If a project path leaks information you’d rather not share (e.g. a client name in the directory path), treat it as visible to us.public.profiles from Stripe via webhook (plan, status, customer ID). We do not store your card details; Stripe does. Lifetime tier exception: if an admin grants Lifetime status directly (without a Stripe transaction), profiles.plan='lifetime' is set via admin_update_plan() and no Stripe row is created for that grant.profiles.beta_access (boolean). During the closed beta we gate the /download page behind this flag. It defaults to false and is flipped to true only when an admin grants you beta access via the admin panel. Admins are implicit beta users. The flag is decoupled from your plan: a free user can have beta access, a paid user can too. When an admin grants or revokes beta access, a row is written to public.admin_audit_log describing the before/after state (see “Only if you become an admin” below).profiles.last_seen_at, refreshed by the macOS app on launch and by web sessions, so we can tell active accounts from dormant ones.public.waitlist together with a coarse source label (e.g. landing). No IP address, no user-agent. Each signup gets a short referral slug (8 hex characters, e.g. a1b2c3d4) stored in the same row as referral_slug. The slug is the suffix of your personal vibehaus.dev/?ref=<slug> share link — it carries no identifying information on its own and is only meaningful inside our waitlist table. If you signed up after clicking another waitlist member’s share link, we also store their slug as referred_by_slug so we can attribute the referral. We don’t link these slugs back to your email anywhere outside the same row.vibehaus.dev/r/<slug> short link, we record an anonymous click row (public.share_link_clicks). We never store your raw IP or user-agent. Instead we compute sha256(ip + daily_salt) and sha256(user_agent + daily_salt). The salt rotates every day, which lets us deduplicate same-day clicks but prevents anyone — including us — from correlating your visits across days. We also record a coarse country code from the CDN edge (e.g. DE, TR) and the HTTP referrer if your browser sends one.public.feedback. The email field is optional; if you fill it in, we’ll use it to reply. We also compute sha256(ip + daily_salt) on the submission for rate-limiting + duplicate detection — the raw IP is never stored. The daily salt rotates, so same-day spam attempts can be deduplicated but we cannot correlate submissions across days.public.admin_audit_log records every admin action (e.g. plan change, lifetime grant, beta-access grant or revoke) with the admin’s user ID, the target user’s ID, a JSON before/after payload, an optional free-text reason, the request IP, and the user-agent. This only applies if your account is granted admin status; regular users never write to this table.eu-central-1 (Frankfurt, Germany). Hosts everything in section 2 except payment data and the master key.vibehaus.dev web app, including all /api/* endpoints (waitlist signup, feedback submit, admin actions). Receives HTTP requests in transit; does not persist user data beyond the standard web access logs needed for service operation.We cannot read your vault items or your notes. Here’s the technical detail:
What this means in practice: if someone breached our database tomorrow, your vault and notes would be opaque to them. The trade-off is that if you lose access to your iCloud Keychain entirely, your vault and notes become unrecoverable — neither we nor Apple can restore them, by design.
Project paths and names are not encrypted. The sync protocol needs them in plaintext to route requests. If a project path leaks information you’d rather not share, treat it as visible.
You can request account deletion by emailing info@alpyaprak.com from the address on file. We process deletions manually right now (a self-serve flow is on the roadmap).
For a regular user, deletion of your auth.users row cascades:
public.profiles — deleted (on delete cascade).public.vault_items — deleted (on delete cascade).public.notes — deleted (on delete cascade).A few rows are intentionally preserved or transformed:
public.share_link_clicks.signup_match_user_id — set to null (on delete set null). The anonymous click row stays, but it can no longer be linked back to you.public.admin_audit_log.target_user_id — set to null if you were ever the target of an admin action (on delete set null). The audit entry is preserved for accountability, but no longer references your user ID.public.waitlist — if you originally signed up for the waitlist with an email and never linked that email to an account, the waitlist row is independent of auth.users and is not removed automatically. Tell us in your deletion request and we’ll remove it manually.public.feedback — feedback messages are anonymous-by-default (the email field is optional and free-form). If you submitted feedback under your account email and want it removed, ask us and we’ll remove the matching rows.If you’re an admin, your auth.users row is referenced by admin_audit_log.admin_user_id and share_links.created_by with on delete restrict, which would block a direct cascade delete. In practice, before deleting an admin account we reassign or archive those references. Regular users are not affected.
After cascade, your encrypted rows are gone. Because we never held the key, there is no copy we can recover.
Stripe retains payment records as required by their own terms and applicable tax law; you can request deletion directly with Stripe in parallel.
To exercise any of these rights, email info@alpyaprak.com. We’ll respond within 30 days.
KVKK Article 11 grants the same rights in a Turkish-law framing: knowing whether your personal data is processed, requesting information about the processing, learning the purpose and whether the data is used in line with that purpose, knowing third parties to whom data is transferred, requesting correction of incomplete or inaccurate data, requesting deletion or destruction, requesting that corrections and deletions be communicated to third parties to whom the data was transferred, objecting to results produced by automated systems that disadvantage you, and claiming damages from unlawful processing. Send requests to info@alpyaprak.com.
If you’re a California resident:
Email info@alpyaprak.com to make a request. We may verify your identity by asking you to send the request from the email on file.
We don’t run any third-party analytics scripts on the website. There’s no Google Analytics, no Plausible, no Mixpanel, nothing.
We set a small number of functional-only cookies:
vh-admin-token and vh-admin-refresh — session cookies set after you sign in on the website. They hold a short-lived Supabase access token (vh-admin-token) and a refresh token (vh-admin-refresh) so you stay signed in across page loads. Both cookies are HttpOnly and Secure. The names are historical from the admin-only auth surface; during the closed beta the same cookies are now also set for regular signed-in users so the /download route can check your beta-access flag. Both names refer to the same pair of session cookies regardless of whether you’re an admin or a regular user.vh_ref — set for 30 days when you visit a vibehaus.dev/r/<slug> short link (admin-created share-link tracker). Stores the link identifier so that if you later sign up for the waitlist or create an account, we can attribute the signup back to the campaign that referred you. The cookie holds an opaque link ID, not your identity.vh_waitlist_ref — set for 30 days when you land on the homepage via vibehaus.dev/?ref=<slug> (a waitlist member’s personal share link). Holds only the 8-character referral slug from the URL. If you then submit the waitlist form, the slug is stored in your own waitlist row as referred_by_slug so the referrer gets credit. Distinct from vh_ref above (different path, different mechanism).Because none of these are tracking or advertising cookies under GDPR / ePrivacy, we don’t display a cookie banner. If we ever add non-essential cookies, that changes.
We share data with the third-party processors described in section 3:
vibehaus.dev. Data processor under GDPR Art. 28. Operates in Germany (EU).We don’t sell, rent, or trade personal data with anyone, ever. We don’t share data with advertisers because we don’t run ads.
Vibehaus is a developer tool, not directed at children. We don’t knowingly collect personal data from anyone under 16. If you believe a child has signed up, email us and we’ll remove the account.
In addition to the encryption posture in section 4:
No system is perfect. If you spot a security issue, please email info@alpyaprak.com with security in the subject.
We keep data for as long as your account exists. After deletion we retain only what’s needed for legal or accounting reasons (e.g. Stripe invoice records). Anonymous click logs (share_link_clicks) are kept for product analytics with no fixed expiry; we can purge them on request once they’re disassociated from your account.
If you’re in the EU, your data is stored in Frankfurt. Stripe processes payment data in the US under Standard Contractual Clauses. Apple’s iCloud Keychain operates under Apple’s own privacy framework.
When we change this policy, we bump the version number and update the effective date at the top. Material changes will be summarized in the changelog and, where the change is significant, emailed to active users.
Vibehaus — operated by Alp Yaprak (sole proprietor, Türkiye).
Email: info@alpyaprak.com. Postal address available on request.