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 when it opens, once a minute while it is in view, when you come back to it, and when you leave it or switch away from it. The signal contains the page address, a random identifier made for that page view, how long the page has been in view, the date by your device’s clock, whether the page is drawn in dark or light mode, and the domain of the site that sent you. When you move to another page, the signal for the new page also contains the previous page’s identifier and its final time in view. We use it to see how many people are on the service right now, roughly where, and how it is used. 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. We also keep a page history for thirty days so that our staff can see how the service is used: under your account when you are signed in, and otherwise under the same daily hash with a made-up name that changes when the hash does. It records the page address, the times, the time in view, the domain of the site that sent you to us, your browser, operating system and type of device, whether the page was shown to you in dark or light mode, and the city and country your network address resolves to.

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 see how the service is used so that we can improve it: the thirty-day page history described in clause 1, which our staff read.
• 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 for people who are not signed in, referrer domains rather than URLs, and page history kept for thirty days. When you are signed in, your page history is linked to your account, and our staff see it with your name, username and email.
• 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 database, and uploaded files are hosted in the European Economic Area. 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.

Continuum Local. On an Enterprise plan your organisation can run Continuum Local, an agent you install on a machine in your own network, so Blueprintr can sweep that network for SNMP devices and draw it, and read monitoring systems that it cannot reach itself. The agent sends us:

• From every version: its name, version, platform and capabilities, the connectors it serves, the address ranges it may sweep, and when it last checked in. We use this to send each job to an agent that can run it and to show whether it is online.
• From version 0.3.0, in addition: the host name of the machine it runs on, and how it is managed: whether it is configured from Blueprintr or from a file on its machine, why, whether that file sets network discovery and how many connectors it configures, and the collectors the agent has. An agent managed from Blueprintr also reports the configuration version it applied, a summary of any local limit its administrator set on the machine (the address ranges and exclusions, the rate caps, the SNMP versions and collectors it allows, and whether credentials may be entered in Blueprintr), which of its credential sets hold a credential, and the public half of the key it encrypts credentials with. We use this to show how the agent is configured and to check a change against its limit before saving it.
• What it collects for you: the answers to the reads a connector makes, and what a network sweep finds: devices, ports, addresses, routes and links, the BGP, OSPF and IS-IS sessions each device reports, and the MAC and IP addresses those devices have learned, which can identify the people whose laptops and phones they are. From version 0.4.0 it also looks up the name your DNS servers give each of those IP addresses and sends it with the address. We never keep a device's contact field.

The people who can manage Continuum integrations for the organisation or team that owns an agent see all of this, and so do our staff when they support you. Staff who run the service also see each agent’s name, owner, status, version, platform and capabilities. Every change, by your team or by our staff, is in your audit log. Once your organisation manages its agents from Blueprintr, changes to agents, credentials and discovery ranges are also emailed to your organisation’s owners and admins. We keep an agent’s record, its latest report and its discovery settings until you delete the agent, a connector’s answer for two minutes, and sweep results for 90 days, apart from each agent’s latest complete sweep, which is kept until a newer one completes. A credential you enter for an agent is encrypted in your browser for that agent, and we cannot decrypt it: we delete the encrypted value when the agent collects it, or if it is not collected within two minutes, at the latest at our next quarter-hourly cleanup, and our database backups hold an encrypted copy only for their retention period. Credentials for your monitoring systems stay on the agent’s machine; one you choose to send from Blueprintr instead passes through our servers to the agent and is not stored. The Continuum Local security page has the details.

A network drawing is different. When someone allowed to draw networks with Continuum Local draws a sweep as a blueprint, from the sweep’s results or from a Continuum tab in the blueprint, the devices it found, with their names, locations, management addresses, interfaces and addresses, the links between them, their routing, and summaries of the network, become part of that blueprint, and everyone who can read the blueprint sees them. The summaries count the devices connected to each VLAN and switch; they never list them. A new drawing is private until an editor publishes it. It never holds a device’s contact field, and it stays until an editor removes it or deletes the blueprint, with copies in that blueprint’s versions and exports.

A drawing also shows, for each network device, its route table, its MAC address table and its ARP table. The last two list the devices connected to your network by their MAC and IP addresses, with the maker of each device worked out from its MAC address using the IEEE’s public list and, from agent version 0.4.0, the name your DNS servers give each IP address. They can identify the people whose laptops and phones those devices are. We show them so that readers of the blueprint can see what is connected where, and everyone who can read the blueprint sees them. A redraw from a newer sweep replaces them, and removes them from any device that sweep did not read; otherwise they stay until an editor removes the drawing or deletes the blueprint. Saved versions and templates of the blueprint leave them out, and so do search and the index our AI features answer from, but an export someone makes of the blueprint keeps its copy. The people who manage the agent can switch the ARP and forwarding tables off in its settings, which also stops the DNS lookups: sweeps from then on leave them out, and a redraw from such a sweep removes them from the drawing. They can also turn the DNS lookups off on their own.

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: 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, apart from work you made for a team or organization, which stays with that workspace, and the files that work still uses (clause 12).

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. The page history described under access logs in clause 1 is the exception: it is deleted automatically after thirty days, and with your account if you delete it sooner.

Audit records outlive the accounts they mention. Records written from 8 October 2026 hold email addresses only as hashed identifiers, never in plain form, and IP addresses have only ever been written as a salted hash. Records written before then keep the details they were recorded with. The record of an account deletion itself never identifies the person whose account it was. 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, and it cannot be undone. It removes your account, your profile, your comments, and the blueprints and diagrams you own personally. A topic or comment thread you started that others replied to stays as a deleted placeholder so their replies remain, with nothing of yours left in it. Files you uploaded are deleted from storage unless they are still used by work that stays with a workspace. Copies of your profile picture and cover image already cached by our content delivery network can still be served from there until they expire, which can take up to a year; ask us and we will clear them sooner. Backup versions of deleted files are removed after 30 days. Your username stays reserved for 90 days so that nobody else can take it straight away. Blueprints, diagrams, cloud connections and integrations you made for a team or organization stay with that workspace, under one of its owners or administrators, and records of what you did in shared work, such as uploads, reviews and access you granted, stay without the link to your account. If you are the only owner of a team or organization, hand it over or delete it first.
• 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].