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 aladdin@devino.ca — 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 written guide, the machine-readable plan, the camera receipt (which parts of the video are zoomed, and onto which click), the logs of what the recording did, 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. You can also add a file from your Google Drive: you sign in to Google in a popup, your browser reads the file from Google Drive, and your browser uploads it to the same bucket.
• A browser session you attach to one demo. If you attach a session file (cookies and local storage saved from a signed-in browser, 2 MB at most) so a demo can be filmed signed in, your browser uploads it to the bucket under that demo’s id. It is never handed back to a browser through a signed address, and it is not sealed with envelope encryption the way a saved login is. The worker deletes it as soon as the recording finishes, or when the demo ends if it fails before then. If that deletion itself fails, the failure is logged. If the site changes and Demofy re-shoots the demo automatically, the session is copied to the re-shoot under its own id, and is deleted there the same way.

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.

When you create an account we save where you first arrived from (the campaign parameters, ad-click identifiers, the referring domain, the landing page and the time) on your account record, so we know which of our campaigns work. Nothing is stored in your browser for this before you answer the cookie question. If you accepted analytics cookies, we also send it to our analytics product with the sign-up event; if you declined, it stays on your account record only and is deleted with your account. If you accepted analytics cookies on demofy.io, that same information about where you first arrived from also travels with you when you follow a link or submit a form from demofy.io to the studio at app.demofy.io: it is added after the # in the address, a part your browser never sends to any server, and app.demofy.io reads it, removes it from your address bar, and writes it to your browser only once analytics cookies are accepted on app.demofy.io as well (your answer on either site is shared with the other through a cookie listed on the cookies page).

Workspaces

Which workspaces you belong to and what role you hold in each. An invitation keeps the address it was sent to, with the role offered and its status (pending, accepted, rejected or canceled), after it is accepted, rejected or canceled; it is deleted only when the workspace or the account that sent it is deleted.

Referrals

If you arrived through a partner’s referral link, the click id that link carried, kept with your account id so the partner can be credited when you sign up. For a workspace that pays, a record of each payment reported to the partner program — its transaction id and its amount in US dollars — kept so that a refund or a chargeback can take the partner’s commission back.

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 by the controls below, apart from the backups and logs listed in the retention table, 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 is private, loopback, link-local or in the shared carrier-grade NAT range — the kind Demofy’s own servers and tunnel use between themselves — is discarded rather than counted. A visitor’s VPN or public proxy address is a public address, so it is kept like any other. It is written when the demo is created, to a 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. Beside the address, that record holds the demo’s id, the id of the account that made it, the time, whether it was made in a guest session, and, once the demo ends, whether it finished or failed. The address itself is never changed after it is written; the outcome is filled in later, and the account id is moved onto the new account if a guest session is turned into one. The account id on the record is not removed when the account is deleted.

How it is secured. Demofy is served over HTTPS with HSTS. A saved login is sealed with envelope encryption before it reaches storage, as described above. Files are stored in a private Backblaze B2 bucket under paths built from ids.

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.
• The AI model that plans the demo — requests go through Devino’s own AI gateway, which passes them to a hosted open model (currently GLM 5.3, with Kimi K3 as the fallback). During exploration it receives the address and title of the page being filmed, a numbered digest of its visible interactive elements — their names (a field that holds a typed or pre-filled value and has no aria-label, placeholder or title is named by that value, up to its first 60 characters, even when a visible label sits beside it) and, where two controls share a name, the text of the row each one sits in — and your intent line. When you press Refine on the intent box, it receives the rough intent you typed, and the address you entered if there is one, before any demo exists. 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: its account id, which sign-in method it uses, its language and time zone, when it was created, that the request comes from the web app, and — only if you accepted analytics cookies — the campaign link and the referring domain 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 nine kinds and no others: a workspace invitation (which also carries the workspace name and the inviter’s name or address), a link to confirm your email address when one is asked for on that address (it lets Google or Apple sign in to a password account on the same address; anybody can ask for one to be sent to an address, which gives them nothing, because the link goes only to that inbox and changes nothing until its reader presses Confirm), a link to choose a new password when one is asked for on that address (anybody can ask for one to be sent to an address, which gives them nothing, because the link goes only to that inbox, works once and for one hour, and changes nothing until its reader chooses a password, which signs that account out everywhere), 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 answers something done on your account or address. There is no marketing mail and no newsletter, because neither exists, and consequently no unsubscribe link on these nine: the way to stop all of them is to close the account, which the footer of the welcome, first-video, trial and cancellation messages links.
• Notifly — Devino’s own notification service, and the only route for Refer & Earn email, which is the one kind of mail outside the nine above. Your account id, email address and first name, and the message itself. There are ten kinds and no others: a first click on your referral link, a first sign-up through it, your first commission, a daily count of new commissions, a commission that cleared its holding period, earnings ready to withdraw, a commission that was taken back, a reminder a week after you joined if your link has not been opened, further reminders — three at most — if it still has not, and a monthly summary once it is being used. At most one a day, and only to an address that has been verified: an account you sign in to with Google or Apple, or one whose address you have confirmed with the emailed link above. An account made with a password gets none of these until its address is confirmed. The reminders and the summary carry a link that switches them off without signing in, for 90 days after the email was sent (after that, the same switch is on the Refer & Earn page once you sign in); the other seven are news about your own link and money, and arrive either way.
• Devino Partners, at partners.devino.ca — Devino’s own partner program: a copy of the open-source Dub that Devino runs on its own servers, not a service of Dub’s company. Accounts are enrolled in it as partners automatically, with the account id, email address and display name, because that is what makes your Refer & Earn link exist the moment you want it and lets a commission build up before you have set up payouts. An account whose address is verified (Google, Apple, or the emailed confirmation link) is enrolled when the Refer & Earn email check first reaches it, usually within a day of being created, whether or not you ever open Refer & Earn; any other account that is not a guest profile is enrolled the first time you open Refer & Earn, copy your link or download a copy of your data. A guest profile is never enrolled. The partner record holds your link and its counts of clicks, sign-ups and commissions. Deleting your Demofy account does not delete it today: it stays at Devino Partners until you ask us to remove it, by writing to the address at the top of this page. Separately, when somebody who arrived through a partner’s link creates an account: the click id, the account id, the email address and the display name. For every payment: the paying workspace owner’s account id, the amount in US dollars and the transaction id — the program credits it to a partner only when that account arrived through one of the partner’s links, and records nothing for anybody else. A refund or chargeback sends the same transaction id back, to take the credit away.
• 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 — except that Sentry also has a half that runs in your browser, and that half waits for your permission like the first two. None of them is sent the intent line you wrote, the title you gave a demo, or your email address, and no event we record carries the address of the site you film. The one place an address can appear is a page view, an error report or a session replay, which names the address of the page involved: on the create form the browser extension opens, that includes the address the button filled in. A page view is recorded only if you accepted analytics cookies.

PostHog — product analytics

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

• A demo was created.
• A demo finished, or failed.
• An account was created.
• A paid subscription, or a free trial of one, began.
• A paid subscription renewed.
• Somebody chose to cancel a paid subscription.
• 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 apps page was opened.
• An install badge on it was pressed.
• The Add to Chrome button for the browser extension was pressed.
• The browser extension opened its welcome page after it was installed.
• The browser extension opened its goodbye page after it was removed.
• You sent the short form on that goodbye page, with the reason you picked and anything you chose to type.
• A link to one of our other apps was followed.
• A coding agent's setup pill was copied.
• Your Refer & Earn page was opened.
• You copied your referral link.
• You shared it through one of the share buttons.
• You pressed Withdraw.
• You opened one of its questions.
• You told us whether the page was clear.
• You opened Refer & Earn from its card in the sidebar.
• You closed that card.

The last nineteen are the only ones that wait for your permission. Three are how we tell whether an interruption was worth making, three are how we tell whether the apps page did its job, four are how we tell whether people who press Add to Chrome end up with the browser extension, whether they keep it and, if they leave, what they tell us about why, one is how we tell whether a piece of copy was useful, and eight are how we tell whether the referral program is easy to use — none of them names who you referred, and the link itself never travels. All nineteen 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 video an event is about, whether a finished demo succeeded or failed, the short fixed name of why it failed, never the error message itself, for a failure that has no short name yet, the name of the kind of error our own software raised, never its message, which step of making the video a failed one had reached, how many seconds it took, whether it was an automatic repair of an earlier demo, which tip or prompt was on screen, whether you were in a browser or in an installed app, which kind of device that was, which store or install method a badge on the apps page named, which of our other apps a cross-app link pointed to, which coding agent a setup pill was copied for, if any, which of our apps sent that one event, restated on it directly, where on screen a referral link was copied or shared, which share button was used, which referral question was opened, whether you found the referral page clear, whether an account was created with an email, Google or Apple, on the sign-up, subscription and browser-extension install events only where the account or the install first came from — the campaign parameters and ad-click identifiers on the link followed, the domain that referred you, the page you landed on and the time — and only if you had accepted analytics cookies when you signed up or pressed Add to Chrome, on the subscription events only which plan, billing product, store and billing period the subscription is for, the currency and amount charged, whether it was a test purchase, on the browser-extension events only which address opened the welcome page — always the extension’s own, whether this browser had recorded a campaign or a referring site here before the install, or none and which version of the extension was removed, on the extension’s goodbye-form event only which reason you picked from a fixed list and, if you chose to type one, your comment, up to 500 characters, as you wrote it once control characters are removed, 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 that event has nowhere to put one.

The one place words you typed do travel is the optional comment on the goodbye page’s form, and only when you press its button with analytics cookies accepted. It is sent beside the reason you picked, trimmed, cut to 500 characters, with control characters removed and any token= value in a pasted link blanked. We do not ask for your email address there, and the box asks you to leave out names, addresses and passwords; what you type is still your choice, and it is sent as you wrote it. That event is sent without a person profile, like the other extension events.

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. It counts page views and records a sample of sessions (see Session replay below). It runs only after you accept analytics cookies, and only when the deployment has been given a key; it writes one first-party cookie, a matching localStorage entry and two session-storage entries that tell one tab from another, all 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, Google or Apple), 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, the ad-click identifiers on that link, if there were any, the time of that first visit, 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; the one exception is that creating an account saves where you first arrived from on your account record (see Your account above), and that copy is not sent to our analytics product unless you had accepted. If you decline, nothing is written down in your browser 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.

Sentry also runs in your browser, but only after you accept analytics cookies and only when the deployment has been given a browser key. There it reports script errors with the same flag turned off, but without the account id or the workspace: the browser is never told either. Like any browser error report, each one names the address of the page, your browser’s user-agent string and the page you arrived from, and carries a short trail of what led up to the error: the elements you clicked or typed in (never what you typed, and with the words of any label masked), the page changes, the requests (each with its query cut off) and the console messages. It is the same Sentry instance, and it is what makes the session replays below possible.

Session replay — PostHog and Sentry

If you accepted analytics cookies, a sample of your sessions is recorded as a replay that can be played back like a video of the page. PostHog records about 10 in every 100 sessions this way and Sentry about 10 in every 100, and each makes that choice for itself, in your browser. Of the other sessions, Sentry keeps a replay of 100% of those in which the page hits an error that Sentry reports: it holds up to the last minute of such a session in your browser’s memory and sends none of it until that error, then sends that minute and goes on recording. An unsampled session without such an error sends Sentry no replay.

A replay is built from the shape of the page, not from what is on it. All text on the page, the words of a tooltip, a placeholder or an accessible label included, is replaced by placeholder characters, every value in a form field is masked, images, video, canvases and embedded frames are not recorded, the address a link points to is masked and no console message and no request or response header or body is recorded. PostHog records no request at all; Sentry notes the address of each request and file the page loaded, with its query cut off, its method, status, size and timing. Anything on a page marked ph-no-capture or ph-sensitive is blocked outright. What a replay does show is the layout of the page, where the pointer moved and what was pressed, and the address of each page you visited, with its query string — the same address a page view names.

Replays are stored in the same PostHog and Sentry instances described on this page, which Devino runs itself. PostHog keeps a replay for 5 years and Sentry for 90 days; each is a setting of our own instance, not of the code. Nothing is recorded unless you accepted analytics cookies, and nothing is recorded on a shared video embedded in another site. Switching analytics off on the cookies page stops the recording in the visit you are in. PostHog records only if its project has recording switched on.

Google Analytics 4 — page views

On every page except a shared video embedded in another site, 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 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: AI Product Demo Video Maker. 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 what the button does.

When you install the extension it opens a welcome page on demofy.io, and when you remove it your browser opens a short goodbye page there. The extension itself collects and sends nothing; visits to those pages follow the same cookie and consent choices as the rest of demofy.io.

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. The extension itself holds nothing to delete; removing it from your browser removes it.

When that new tab loads, your browser asks app.demofy.io for the create form, so the address of the tab you pressed the button on reaches Demofy’s servers as part of that page address, and passes through Cloudflare, which sits in front of them. Demofy does not save it to a demo or an account unless you press Create demo. It can appear in ordinary web-server and Cloudflare request logs, and, if you have accepted analytics cookies, in the page view that the measurement section above describes. Once you press Create demo, the address and your intent line are stored on the demo; the address, the page title, the names of the page’s visible controls and your intent line are sent to the AI model that plans the demo, through Devino’s AI gateway; and the narration text is sent to VoiceLabs. Both are listed above with everything else Demofy shares.

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. It also refuses while any of your demos is still running, until you cancel it or it finishes. A guest profile has no sign-in to confirm a deletion with, so it cannot delete itself this way; Delete everything removes every video and file in 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. It also carries your Refer & Earn link and the totals its page shows you, as the partner program reports them. 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 us to delete what the controls above cannot reach, such as a demo from a guest session you can no longer open, by writing to aladdin@devino.ca. We act on it within 30 days, except for the creation record and the referral records described above, which are kept for the reasons given there.
• 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.