Privacy

Demofy is made by Devino. This page describes what the running service actually holds, where each thing goes, and how long it stays — not what a policy template says a company of this shape usually does. Where something is uncomfortable, it is written down anyway; the two paragraphs most people would skip are the one about IP addresses and the one about the record that survives deleting your account.

Who to contact

Devino Solutions Inc, the legal entity behind Demofy, registered at 2149 Johnston Road, Ottawa, Ontario, Canada, K1G 5K1. Reach us at [email protected] — the address the security policy publishes, read by a person — and treat it as the contact point for any request below. Which law these terms are governed by is stated on the terms page.

What Demofy holds about you

The demos you make

• The address you paste and the line of intent you write. Both are stored on the job, because both are what a re-shoot replays. Every member of the workspace the demo belongs to can read them.
• The video and everything beside it — the finished MP4, its poster frame, the caption track, the transcript, the written guide, the machine-readable plan, the cost record, and the frames the explorer photographed while it worked. These live in a Backblaze B2 bucket, under a path built from the demo’s id.
• Anything you upload to the media library — intro and outro clips, audio, logos — under a path built from your account id.

Demofy visits the URL you give it with a real browser and records what it sees. Whatever is on those pages ends up in the video, which is worth saying plainly: if you film a signed-in view of your own product, the video contains whatever that view was showing.

Your account

An opaque account id, your email address, and a display name and avatar URL if you signed in with a provider that supplies them. A guest account is a real account with a generated address that is not yours and never reaches anybody.

Workspaces

Which workspaces you belong to and what role you hold in each. An invitation holds the address it was sent to until it is accepted or removed.

Saved logins

The highest-sensitivity thing Demofy ever holds, and it has a page of its own in the documentation. In short: a saved login is a browser session for your product, sealed with envelope encryption before it reaches storage, never written to the database, never handed out through a signed URL in either direction, and deleted after thirty days of not being used.

The address your device connected from

Demofy stores the IP address of the device that created a demo, in plain text, and this is the one record that is not deleted when you delete your account. It exists for one reason: an abuse cap that stops one machine minting unlimited guest demos. It is never used to identify a signed-in person, and an address that belongs to a proxy rather than to a device is discarded rather than counted. It is written to an append-only creation record that every deletion path deliberately leaves alone — that record is what makes the daily limits enforceable at all, and a limit a deletion refunds is not a limit.

Who else receives something

Each of these gets exactly what the line says and nothing else.

• Backblaze B2 — every file above. Storage only; nothing is analysed there.
• DeepSeek — during exploration, a numbered digest of the interactive elements on the page being filmed, plus your intent line. This is how a demo is planned. If you would rather a page’s contents did not reach a model, do not film that page.
• VoiceLabs — the narration text, when a demo is narrated, in exchange for the audio.
• RevenueCat — the workspace id; the workspace’s name and the email address of whoever owns it, so a receipt, a renewal notice and a billing-portal link reach a person rather than a uuid; and, alongside those, a short list of facts about the account that opened checkout: which sign-in method it uses, its language and time zone, when it was created, and — only if you accepted analytics cookies — the campaign link you first arrived from if there was one. Card details never touch Demofy: checkout runs inside RevenueCat’s hosted flow, which loads Stripe’s own fields in their own frames.
• Sendly — the recipient’s address and whatever the message needs to make sense, for the transactional email this product sends. There are seven kinds and no others: a workspace invitation (which also carries the workspace name and the inviter’s name or address), a welcome on your first sign-in, a note when your first video is ready, a warning two days before a trial ends, a note when it has ended, a confirmation when a subscription is cancelled, and a copy of each support request you send — your message itself, its reference number and topic, and the address you asked us to reply to — delivered to our own support inbox. That last one is the single case where prose you typed travels through Sendly, and it goes only to us, so that a person can read it and answer you. Every one of them is transactional — each is a reply to something you did. There is no marketing mail, no newsletter, no verification mail and no password-reset mail, because none of those exist, and consequently no unsubscribe link: the way to stop all of it is to close the account, which the footer of every message links.
• Cloudflare — sits in front of every request and therefore sees the connection, as any proxy does.
• Sentry and PostHog and Google Analytics — described in their own section below, in detail.

Measurement and error reporting

Four products can receive something about your use of Demofy. Two of them run only if you accept analytics cookies; two of them run regardless, because they are how the service works and how it is repaired. None of them is ever sent the URL you asked Demofy to film, the intent line you wrote, the title you gave a demo, or your email address.

PostHog — product analytics

Demofy records eight named events, all of them from the server, and no others:

• A demo was created.
• An account was created.
• A guest account became a real one.
• A shared link was opened.
• A support request was submitted.
• A tip or prompt was shown to you.
• You closed one.
• You took one up.

The last three are the only ones that wait for your permission. They are how we tell whether an interruption was worth making, so they are recorded from the server like the rest, but nothing is sent at all unless you accepted analytics cookies — and switching the prompts off in your settings stops both the interruption and the record of it.

The properties an event may carry are a closed list, and this is all of it: the kind of job, the quality tier, the video format, whether the author was a guest, whether a saved login was used, which workspace the video landed in, which tip or prompt was on screen, whether you were in a browser or in an installed app, which kind of device that was, the few the support event adds below, and — on every event, stamped by us rather than by the thing that happened — which of our apps this is and whether the deployment is the production one. The vocabulary our code is even able to spell is a closed list too, and a wider one: it is a set of names Devino’s apps share so that one query can span them, most of which Demofy never sends. Nothing here can spell a name outside it, and it has no name for a URL, a prompt, a title, an email address or an IP address.

The support event is the one worth spelling out, because the form it comes from is a box you type prose into. What travels is the reference number printed on your confirmation, which topic you picked, which screen you wrote from, whether you were a guest, and the workspace, the video and the error report the message is about when there are any. Your message itself never travels — not truncated, not hashed, not at all. Prose is where an address, a URL or a pasted password ends up, and the properties object has nowhere to put one.

The identifier on an event is the opaque account id, never an address. There are two exceptions and both narrow it further rather than widening it. The shared-link event’s identifier is the video’s own id, and it explicitly asks PostHog not to create a person profile — so a share view records which video was opened and nothing whatever about who opened it. And a support request sent by somebody who is not signed in is identified by its own reference number, never by the address they gave us so we could reply.

A PostHog browser SDK also exists and counts page views. It runs only after you accept analytics cookies, and only when the deployment has been given a key; it writes one first-party cookie and a matching localStorage entry, both listed on the cookies page. Which PostHog instance receives any of this is set per deployment — demofy.io sends to Devino’s own PostHog rather than to PostHog’s cloud.

PostHog also holds one profile per account, under the same opaque account id. Most of it is attached by that browser SDK while you are signed in, and is therefore written only if you accepted analytics cookies. The billing facts are the exception: they are attached by our own server when a workspace’s subscription changes, for every member of that workspace, whether or not anybody has a browser open and whether or not analytics cookies were accepted. They are plan words and billing labels and nothing else — no address, no name, and no page anybody visited. A few facts arrive from both sides: your plan and its standing are attached by the server when they change and by the browser on a screen that has already looked them up, and the two labels naming our app and its deployment ride on everything either side writes. The list of facts a profile may carry is closed, and this is all of it: the id of the workspace you are working in, whether the account is a guest one, how you sign in (a password, or Google), your plan and its current standing, when it runs out, which billing product, store, billing period and billing environment stand behind that plan, the opaque billing id that names the same workspace in our billing provider, your browser’s language and time zone, when the account was created, which version of our app you were using and the platform it runs on, and which of our apps this is and whether the deployment is the production one. It records once, and never again, where you first arrived from: the campaign parameters on the link you followed, the domain that referred you — never the full address, the page you landed on, and which app, and which version of it, that first visit used. Your email address, your name and the workspace’s name are not among them, in the same way and for the same reason as on the events above: the list of things a profile may carry has no entry for any of them.

Those arrival details are held in this browser and nowhere else until you accept analytics cookies. If you decline, nothing is written down and they are forgotten when the tab closes; the entry that stores them once you accept is listed on the cookies page beside the others.

Sentry — error reporting

When something fails, the stack trace is sent to a Sentry instance Devino runs itself (sentry.devino.ca). It carries the opaque account id — the type has room for nothing else about you — the workspace the failure belongs to, and a short list of low-cardinality labels: which of our apps this is, which service failed, which job, what kind of job it was, and which phase it was in. Sending IP addresses, cookies and request headers along with a stack trace is a single SDK flag, and it is explicitly turned off rather than left at a default a dependency could change. There is no field for an address, a URL or a prompt.

Google Analytics 4 — page views

On the public pages only, and only after you accept analytics cookies. It counts page views and where visitors arrived from. The tag is handed three settings and these are all of them: no Google signals, no ad-personalisation signals — so nothing here feeds an advertising audience — and identifier cookies that expire after 90 days instead of Google’s default two years. IP anonymisation is unconditional in GA4 and is not something Demofy can switch on or off. Declining leaves the tag unloaded: it makes no request and sets no cookie.

What is deliberately absent

• No session recording, no heatmaps or scroll maps, no dead-click capture, no rage-click capture and no autocapture of clicks anywhere — each one switched off in the SDK’s own options rather than left at a default a dependency or a dashboard could change.
• No advertising or retargeting pixel of any kind, on any page, from any vendor.
• No cross-site identifier, and no user-id sync between Google Analytics and your Demofy account.
• No analytics at all on a shared video page when it is embedded in someone else’s site.
• Audience analytics on a shared demo are stored as a count per video and per moment reached — no viewer, no address, no session and no timestamp is recorded, so an individual’s viewing is not merely unqueryable, it was never written down.
• No measurement or error product named on this page has a field for an email address, a person’s name, a phone number, the address of a page we filmed, the intent line you wrote, the title you gave a demo or your IP address — not a field left empty, a field that does not exist: the vocabularies these products are allowed to speak are closed lists, and not one of those names appears in any of them.

This page covers what is recorded and where it goes. Every cookie and browser-storage key any of it sets in your browser is listed, name by name, on the cookies page — including which of them wait for your consent, and the switch that changes your answer.

The browser extension

Demofy has one browser extension, Demofy — demo videos from any page. It is a shortcut and nothing else. If you have it installed, pressing its toolbar button reads the web address of the tab you pressed it on, at the moment you press it, and opens a new tab at Demofy’s create form with that address already filled in. That is the whole of it.

It asks the browser for one permission, activeTab, which the browser grants only on your click, only for the tab you clicked on, and takes back as soon as that tab navigates away. The extension runs no code on the pages you visit and reads nothing on them beyond that address; it asks for access to no site; it does not enumerate your tabs. It keeps nothing — it has no storage, no settings, no account and no server of its own, and it makes no request of its own. The only thing that travels is the address, into a Demofy URL in your own browser, exactly as it would if you copied it out of the address bar and pasted it into the create form yourself. On a tab it cannot vouch for — a browser settings page, a local file, another extension’s page — it opens nothing at all.

From the moment that form opens you are on Demofy, and everything else on this page applies as written: what you submit there becomes a demo like any other.

Chrome asks that one sentence about all of this be stated on a page belonging to the extension rather than only in its dashboard, so it is stated here in the words Chrome publishes for it: The use of information received from Google APIs will adhere to the Chrome Web Store User Data Policy, including the Limited Use requirements.

How long things are kept

There is no automatic expiry on a demo. Demofy does not delete your work because it is old.

What you can do

• Delete one demo from its own page. The files are removed from storage as well as the row.
• Delete everything you have made — every demo and the whole media library, keeping the account — from the danger zone in account settings. It asks you to type a phrase, because it acts on things you cannot all see at once.
• Delete the account itself, from the same page. That removes the demos and files it can still reach, its personal workspace, and the account. Your sign-in stops working immediately. It refuses while you still own a workspace that has other members in it, so deleting your account can never take a colleague’s workspace down with it.
• Download a copy of everything, from the same page. It is one JSON file, assembled from exactly the records the delete controls above act on: your account, the workspaces you belong to and your role in each, every demo the account can still reach, and your whole media library — each with a short-lived link to the files themselves. Saved logins are listed by name and address only; the session itself is sealed with encryption and cannot be exported, in either direction. Share links are left out on purpose, because a share link is the password to the video it opens — each demo’s own page still has its. The file states what it leaves out, and why. A guest profile has no account to export: create one first, and the videos from that session come with it.
• Ask a question about any of the above — write to us.

All three controls work in bounded passes and tell you honestly what they could not remove or could not include, rather than reporting success and leaving files behind.

Children

Demofy is not for anyone under 16, and nothing here is designed for or directed at children.

Changes to this page

When what the code does changes, this page changes in the same commit as the code — that obligation is written into the source file the measurement section lives in. There is no “last updated” stamp anywhere on this site, deliberately: a date nothing keeps true is a worse signal than no date. The changelog is where changes are dated.