Privacy Policy

Account and profile. Your email address, username, name, and anything you choose to add to your public profile: display name, bio, avatar, cover image, website, and GitHub or LinkedIn links. If you sign in with a password we store a bcrypt hash of it, never the password. If you enrol two-factor authentication we store your TOTP secret encrypted with AES-256-GCM, your registered passkeys, and hashed recovery codes.

Sign-in. If you sign in with Google, GitHub, or LinkedIn we receive your email address, name, and profile picture from that provider, plus the tokens needed to keep the connection working. If your organisation uses SAML or OIDC single sign-on, we receive the identity attributes your identity provider sends.

Your content. The blueprints, diagrams, documents, foliums, files, comments, and version history you create, upload, or import, together with the metadata that makes them work: titles, tags, folder paths, visibility settings, collaborator lists, and access grants.

Billing. On paid plans we store your plan, seat count, subscription status, and a Stripe customer reference. Card numbers are entered into Stripe and held by Stripe. We never see or store them.

Security and audit records. Sign-ins, permission changes, admin actions, and other security-relevant events are written to an audit log with the acting account, a timestamp, the user-agent string, and a salted SHA-256 hash of the IP address. We hash rather than store the IP so the log still works for abuse investigation without keeping a plain address on file. Rate-limit counters are keyed on the same hash, and on a hash of the recipient address for outbound email.

Reading and usage records. When a page is viewed we record which page, when, how long, and the referring domain (the domain only, never the full URL), against a hashed session identifier rather than a name. Signed-in views are linked to the account. Automated traffic from search crawlers and AI agents is flagged so it can be counted separately from people.

Access logs. Our content delivery network (Amazon CloudFront) writes a standard access log for every request: the time, the address, the user-agent string, the page requested, the response status, the referring domain and the country the address resolves to. We keep those raw logs for three days, fold them into per-minute visitor counts keyed by a salted hash of the address and browser rather than the address itself, and delete them. The salt changes every day, so one day’s rows cannot be joined to the next; the hashed rows are kept for thirteen months, and the page and referrer tallies made from them, which carry no identifier, indefinitely. They contain no cookies and no query strings. On our own pages, though not in the embeds we serve on other sites, a page you have open also sends us a short signal once a minute, carrying only the page address, so that we can see how many people are on the service right now and roughly where. From it we keep, for one day and against the same daily hash, the city and approximate coordinates (to about a kilometre) that your network address resolves to and the time, and for thirteen months a note that a browser ran a page that day, which is how our counts tell people from crawlers.

Search. Search queries are logged with the result count and how long the query took, linked to your account when you are signed in and anonymous when you are not. We use this to find searches that return nothing and fix them.

AI features. When you use an AI feature we store the conversation, the model used, token counts, latency, and the credits it consumed, so that usage limits, billing, and the “resume a generation” affordance work.

• Card numbers, bank details, or any payment instrument. Those go straight to Stripe.
• Raw IP addresses in the audit log or the analytics tables. They are hashed with a secret salt on the way in.
• Advertising identifiers, cross-site advertising profiles, or data bought from third parties. We run no advertising and no ad network on our own pages, and the analytics in clause 13 are never used to build an advertising profile of you.
• Special-category data. Nothing in the product asks for health, biometric, political, religious, or similar data, and you should not put it in your content.

• To run your account and the service: authentication, sessions, permissions, storage, publishing, collaboration, and search.
• To take payment: subscriptions, seats, credit packs, renewals, invoices, and tax.
• To keep the service up and honest: debugging, capacity, rate limiting, fraud and abuse investigation, and responding to reports.
• To show you your own numbers: views, reading depth, and engagement on the content you publish.
• To answer you when you write to us, and to send account, security, and service notices.
• To meet legal obligations and to enforce our Terms.

We do not sell personal data, we do not share it with data brokers, and we do not use your private content to train AI models of our own.

Under the GDPR we rely on the following bases:

• Performance of a contract — running your account, hosting your content, and delivering the plan you paid for.
• Legitimate interests — security, abuse prevention, debugging, and understanding how the service is used, weighed against your interests. Our balancing is that this data is minimised at collection: hashed identifiers rather than names, referrer domains rather than URLs.
• Legal obligation — tax and accounting records, and responding to lawful requests.
• Consent — where we ask for it, such as optional email. You can withdraw consent at any time without affecting what came before.

The application, its Postgres database, and uploaded files all run in Amazon Web Services in the eu-west-1 region in Ireland. Cloudflare sits in front for DNS, caching, and the vanity subdomains, so pages you publish are cached on servers around the world. Real-time collaboration in the Vellum editor runs on Cloudflare’s edge network while a document is open.

If you publish a blueprint or folium, you can attach your own Google Analytics, PostHog, Mixpanel, or Segment account to it in your analytics settings. When you do, that vendor’s script loads on your public pages and that vendor collects data about the people who read them. This matters both ways:

• As a publisher, you are the controller for that vendor's collection. You are responsible for having a legal basis, for whatever consent your visitors are owed, and for the vendor's own terms. We do not vet what you attach.
• As a reader, a page on blueprintr.io may run analytics belonging to whoever published it. We show only the first-party counts described in clause 1 unless a publisher has configured one of these vendors.
• Publishers can also enable click heatmaps. That is our own collection, not a third party's: it samples click coordinates relative to the viewport, against the same hashed session identifier, and it is off unless the publisher switches it on.

Continuum lets you connect an AWS or Azure account so Blueprintr can read your infrastructure and draw it. What we hold depends on the provider, and in the normal case it is not a credential:

• AWS — the account id, the ARN of a role you create, an external id, and the regions you allow. We assume that role for short-lived credentials at read time. No long-lived AWS keys are stored.
• Azure — the tenant id, the client id, the subscriptions and regions you allow, and either an OIDC federated-identity subject (no secret stored) or a reference to a client secret held in a secret store.
• Resource metadata — names, identifiers, tags, regions, relationships, and configuration of the resources in the scopes you select, cached so the diagram renders without a live call on every open.

Grant the narrowest read-only role that does the job. Resource names and tags frequently carry people’s names, team names, and project names, and once pulled they live in our database under whatever visibility you set on the containing blueprint. Deleting the connection deletes the cached metadata with it.

AI features send the prompt you write, plus the content you point them at, to a model provider. Generation is done by Anthropic (Claude). Semantic search and tag suggestions use Google’s Gemini embedding model, which converts text into vectors and returns no generated text. Both are used through their commercial APIs, under terms which provide that inputs and outputs are not used to train their general models.

The practical consequence: content you send to an AI feature leaves our infrastructure. If you are under an obligation that stops you disclosing something to a third-party processor, do not put it in an AI prompt or point an AI feature at it. Nothing in the product forces you to use these features.

AI output can be wrong. Treat it as a draft, not as fact, and never as professional advice.

We use the following processors. Each one gets only what its job requires.

• Amazon Web Services (Ireland) — hosting, database, and file storage.
• Cloudflare — DNS, CDN, vanity subdomain routing, and real-time collaboration sessions.
• Stripe — payments, subscriptions, invoicing, and tax calculation.
• Resend — transactional email: verification, invitations, password resets, and security notices.
• Anthropic — the model behind AI generation features.
• Google — the embedding model behind semantic search and tag suggestions, and (with your consent, per clause 13) Google Analytics and Tag Manager on our own marketing pages.

Beyond these, we disclose data only where the law requires it, where it is necessary to establish or defend a legal claim, or where you have asked us to. If Blueprintr is ever transferred to someone else, we will tell you before your data moves and you will have the chance to delete your account first.

Your content and account data are stored in the EEA. Pages you publish are cached by the CDN worldwide, as described in clause 5, and several of the processors in clause 9 are established in the United States and will process data there or in other countries. Where that happens we rely on the European Commission’s Standard Contractual Clauses, on an adequacy decision where one applies, or on the provider’s EU data-residency option where we have selected one.

Account, profile, and content data lives for as long as your account does. Deleting your account removes it.

Operational records — the audit log, view and analytics events, search queries, and AI conversations and usage — are kept while they remain useful for security, billing, and working out what to build next. We would rather be straight with you than quote a number we do not enforce: there is no automated expiry running on these tables today, so in practice they persist until you delete your account or we prune them by hand. We are working towards automatic expiry at 24 months for security and analytics records and 12 months for search queries. In the meantime, ask us and we will delete records about you sooner.

Audit records outlive the accounts they mention, in a form that no longer identifies anyone: when an account is deleted the link to it is severed, and the IP was only ever written as a salted hash. That is the point of an audit log — it has to be able to answer questions about someone who has already gone.

Billing records are kept for as long as tax and accounting law requires, typically several years. That one we cannot shorten on request.

You have the right to access your data, correct it, delete it, get a portable copy, restrict or object to processing, and withdraw consent. In practice:

• Correction — most of it is editable directly in your account and profile settings.
• Deletion — Settings has a delete-account action. It is a real deletion, not a flag: your account, content, and the records that reference it are removed. It cannot be undone, and it will refuse if you still own a shared resource such as a cloud connection, so that you deal with that deliberately rather than orphaning it.
• Export — request one from your account settings or by email. We fulfil these by hand today, which means it takes days rather than seconds. We will confirm receipt and come back to you within one month.
• Anything else — email us and say what you want.

Write to [email protected] for any of these. We do not charge for it. If you think we have handled your data badly, you can complain to your local data-protection authority; the authority for Portugal is the Comissão Nacional de Proteção de Dados (CNPD).

We use cookies the service needs to function, and — only if you say yes — analytics cookies on our own marketing pages. We set no advertising cookies. Nothing analytics-related is stored on your device until you accept: until then our measurement tools run in a cookieless mode that cannot recognise you, and the session-recording tool is not loaded at all. Declining stores nothing beyond the record of that decision, and you can change your choice at any time. The full list of our own cookies:

• The session cookie (__Secure-authjs.session-token over HTTPS, authjs.session-token in local development) — keeps you signed in. Cleared on sign-out.
• bp_stepup — records that you recently re-authenticated, so sensitive admin actions can require a fresh check. Short-lived.
• bp_theme — remembers light or dark mode.
• bp_tz — set only on our admin pages, for our own staff, so that the admin console prints times in their zone. It is never set for visitors.
• bp_view_sess — a random identifier that lets us count one reader once instead of counting every page load as a new person. It is hashed before anything is stored against it and it is not tied to your identity.
• bp_attr — remembers which campaign or link first brought you to the site (for example a marketing link's utm_source, or the name of the site that linked to us), so that if you later give us your email address we know where you first heard about us. It holds no advertising identifier and nothing about you, and it is only ever read if you submit one of our own forms.
• bp_intent - remembers which plan you were looking at when you started signing up (for example Teams), so that after sign-up we can take you to the right first step. It holds the plan name only and expires after a week.
• bp_consent — records whether you accepted or declined analytics cookies, so we only ask once. Set either way, including when you decline.

If you accept, the tools named in clause 9 set their own cookies on our marketing pages to tell one visit from the next. Those are the vendors’ cookies rather than ours; clearing them in your browser removes them, and declining means they are never set.

A published page may set further cookies belonging to whoever published it, under clause 6. Those are not ours and are not covered by this list.

Everything is served over HTTPS. Passwords are bcrypt-hashed, TOTP secrets are encrypted at rest with AES-256-GCM, and API keys are stored as SHA-256 hashes so we cannot show you a key twice. You can add two-factor authentication by authenticator app or passkey, and organisations can require it. Sensitive administrative actions demand a fresh sign-in. Access is scoped by role and recorded in the audit log, and abuse-prone endpoints are rate-limited.

None of that makes a system unbreakable and we will not claim otherwise. If you find a vulnerability, email [email protected] and we will get back to you.

Blueprintr is for adults and working professionals. It is not intended for anyone under 16, we do not knowingly collect their data, and we will delete an account if we learn it belongs to a child.

When this policy changes, the date at the top changes with it. If a change materially affects you — a new processor, a new category of data, a new purpose — we will tell you by email or in the app before it takes effect rather than quietly editing the page.

Privacy questions, rights requests, and anything else about this policy: [email protected]. General support and questions about the Terms of Service go to [email protected].