Note: This post describes our data-handling principles and the current state of our platform. It is not a substitute for a formal Privacy Policy or Terms of Service. Where we discuss specifics (retention windows, third-party processors, access paths), we describe what we do today — not what you are legally entitled to.
Every platform eventually has this conversation with itself: "what do we actually know about our users, where does that knowledge live, and what do we do with it?" We had ours earlier this year, and this post is the public-facing part of the answer.
What Boottify stores about you
When you sign up, we need:
- Your email address, for account identification, password reset, and verification emails.
- A salted, bcrypt-hashed password (cost factor 12). We never store your plaintext password, and we couldn't recover it for you even if you asked.
- Your name, optional — it's used in notification emails.
- A role — initially
CLIENTfor every self-signup — which gates what you can do in the control centre.
When you enable 2FA, we also need:
- A TOTP seed — the shared secret your authenticator app uses to generate 6-digit codes.
- Backup codes — 10 bcrypt-hashed single-use codes you can use if you lose your authenticator.
As of v3.6.0 (this release), both the TOTP seed and any stored OAuth access tokens are encrypted at rest with AES-256-GCM using a dedicated encryption key. Before this release, TOTP seeds were stored as plaintext — and the OAuth tokens alongside them. We were not comfortable leaving that state untouched, so the backfill migration encrypts every legacy row before declaring the work done.
If you log in with Google or GitHub, we store:
- A link between your Boottify account and the provider's user ID
- The access token and (if the provider issues one) the refresh token — again, encrypted at rest
- Basic profile fields (display name, avatar) so your dashboard looks like you
What we don't store
We don't store your payment card numbers. Stripe handles those end-to-end; we get a reference, they handle the cryptography and the compliance. Same with PayPal (when we ship that payment method).
We don't harvest behavioural or browsing data from users who haven't explicitly signed in. Our analytics tracking is consent-gated and disabled until you actively accept marketing cookies.
We don't sell or rent anything to third parties. Full stop.
Where data lives
Your account lives in a MySQL database in our Hetzner-hosted Kubernetes cluster (Nuremberg, EU). Backups are encrypted and retained for 30 days in a region-pinned AWS S3 bucket with CloudFront in front for CDN delivery of public assets. No user data leaves the EU except to reach third-party processors you've explicitly authorised (see below).
Session state uses encrypted session cookies issued by Lucia Auth v3. Sessions expire after 15 minutes of idle (we tightened this from 30 in v3.6.0) — stolen-cookie exposure is correspondingly capped.
Third parties in the loop
The short list of processors that ever see any of your data:
- Stripe — payment processing, when you upgrade or subscribe. They see billing details directly; we see references.
- Google & GitHub — OAuth sign-in providers. Only touched when you actively log in with one.
- Hetzner — physical infrastructure provider (EU-hosted). They cannot read your data; they host the machines that do.
- AWS S3 / CloudFront — encrypted backup storage and CDN for public assets.
- An email delivery provider — for transactional emails (verification, password reset, notifications). Envelope metadata only.
That's the full list. There is no analytics provider, session replay service, or marketing pixel at the core of the platform. When those appear on public pages, they are strictly consent-gated.
Retention
- Active account data — kept as long as your account is active, plus a grace period for potential reactivation.
- Deployment logs — retained per plan tier (30 days for Starter, 90 days for Growth, 180 days for Scale), then aggregated and anonymised before deletion.
- Billing records — 7 years, per standard tax/accounting retention.
- Deleted accounts — purged from live systems within 30 days; anonymised traces may persist in rolling backups until those backups age out (30 days).
Your rights
If you're in a jurisdiction with data-subject rights (GDPR, CCPA, etc.), you can:
- Request an export of what we hold about you.
- Request deletion of your account and associated data (subject to the retention windows above — billing records in particular have a legal retention floor).
- Rectify or update your account data at any time from the control centre.
Email privacy@boottify.com for any of these. We answer within 30 days.
What changed in v3.6.0 — a summary
- TOTP 2FA seeds: plaintext → AES-256-GCM encrypted at rest, with an idempotent backfill migration for legacy rows.
- OAuth access/refresh tokens: plaintext → encrypted at rest, same scheme.
- SessionGuard idle timeout: 30 minutes → 15 minutes.
- Sign-up response: leaked whether an address was registered → identical response on both paths, with equal CPU cost to prevent timing leaks.
- Email verification: now blocks deployment creation until confirmed.
- Password reset: made atomic one-time-use — a concurrent race on the same token can no longer succeed twice.
If you want the full engineering context, our Under the hood: how we hardened Boottify auth post walks through each change in detail.
If any of this is unclear — or if you want specifics that aren't in this post — email privacy@boottify.com and we'll get back to you. This isn't a legal document; it's a plain-English version of how we operate. The formal Privacy Policy and Terms of Service live at /privacy and /terms respectively.
