Four different arrangements get sold under the same word. Only one of them survives the vendor going away, an air-gapped network, or a security reviewer asking where the data goes.
Applied strictly, self-hosted means the finished demo is an artefact your organisation holds and serves, and that viewing it requires nothing from the vendor at run time. No request to their domain, no account, no player they wrote, no subscription in good standing.
Vendors use the word, and its close relative, offline, for at least four arrangements. A hosted page on your own custom domain is still their server. An embedded iframe is still their server. An offline mode delivered through the vendor's player app or progressive web app is their software on your device. Only the fourth, a file you host on your own infrastructure, satisfies the requirement as written.
If you have "must be self-hosted" in a requirements document, stop arguing about the word and define the tests the artefact has to pass instead. This article gives you three, applies them to each arrangement, and ends with the questions to put to a vendor in writing.
Every disagreement about the word resolves into one of these. Ask them in this order.
The exit test. The contract ends. You cancel, they are acquired, they shut down. Does the demo you already built keep working, and where is it running from at that moment?
The isolation test. The demo has to run on a machine, network segment or training room with no outbound internet at all. Not "slow internet", none. Does it render?
The review test. A reviewer asks what the artefact does at run time: what it connects to, what it transmits, whether a viewer is measured. Can you answer by inspecting the thing itself, or does the answer depend on a vendor's description of their own infrastructure?
These are not the same test, and an arrangement can pass one while failing the others. A cached progressive web app passes isolation once primed and fails exit. A demo on your own custom domain may satisfy a brand requirement and fail all three.
The vendor hosts the demo. You add a CNAME so the address reads demos.yourcompany.com instead of their domain. This is a branding feature and a good one; it is not hosting.
Exit: the DNS record points at infrastructure you do not control. When the account closes the name resolves to nothing, and every link you circulated breaks at once. Isolation: fails; the page is fetched over the internet at view time. Review: every question about run-time behaviour is a question about the vendor's servers, so the answer is their word plus whatever they publish. Your own domain in the address bar makes that harder to notice, not easier.
The demo appears inside a page on your site. The page is yours; the frame's contents are fetched from the vendor when a visitor loads it.
Exit: the frame goes blank on your page, under your branding, and you may not find out until a customer tells you. Isolation: fails for the same reason as above. Review: this is the arrangement reviewers object to most, because an iframe is a live third-party connection made by the viewer's browser from a page you published, bringing the vendor's domain into your content security policy, and any measurement they perform into scope for whatever consent regime applies to you.
The demo is downloaded into software the vendor wrote, an installable player, or a progressive web app cached in the browser. This exists to survive a bad conference-centre connection, and for that job it works.
Exit: the renderer is still theirs. A PWA is served and updated from an origin you do not control, and it is cache, which can be evicted; an installed player is a program whose licensing sits with the vendor. Neither is an artefact you can archive and open in five years. Isolation: usually passes, but conditionally, something has to prime the cache or install the player first. Review: a player is a binary your endpoint team has to approve, and every external viewer must obtain and run it, which turns each share into a support conversation.
The output is a document, ideally a single self-contained HTML file with its markup, styles, images and fonts inside it. You put it on an internal web server, a share, an LMS, a USB stick, or a client's hosting.
Exit: nothing happens, because there is nothing to switch off. Isolation: passes, provided the file genuinely embeds its assets rather than linking to a CDN. Review: answerable by inspection: open the file, read it, load it with the network tab recording, and see what it requests. That is what makes this arrangement different in kind rather than degree: the claim is verifiable by the person who signs it off.
| Arrangement | Exit test | Isolation test | Review test |
|---|---|---|---|
| Hosted link on your custom domain | Fails, link stops resolving | Fails, fetched at view time | Depends on vendor description |
| Embedded iframe | Fails, frame goes blank | Fails, fetched at view time | Third-party connection from your page |
| Vendor player app or PWA | Fails, renderer is theirs | Passes once primed or installed | Endpoint approval; viewers must install |
| Self-contained file you host | Passes, nothing to switch off | Passes if assets are embedded | Answerable by inspecting the file |
Checked September 2026, from the vendors' own published materials.
Of the interactive demo platforms we checked, none documents exporting a self-contained HTML file that the customer hosts. Several document an offline capability, and in each case the published description is a vendor player rather than a file:
Read "not documented" carefully. It means the vendor's published materials do not describe the capability, not that it is impossible, unavailable under a bespoke agreement, or absent from a roadmap. If a platform is otherwise right for you, ask directly and get the answer in writing.
Two things follow. An offline capability available only on a custom-priced Enterprise tier is not a feature you have, it is one you can apply for, and it should be priced into the evaluation rather than ticked in a matrix. And "offline" and "self-hosted" answer different questions, a vendor answering the first when you asked the second is not necessarily being evasive, because the words are used loosely across the category.
Demo Maker Pro's own position is set out on self-hosted interactive demo software; why an export can be real markup rather than video is on HTML interactive demo software.
Email, not a call. Written answers are checkable later; a sales call is not.
The second half is what matters. "Your demos keep working" is compatible with them still being served from the vendor's infrastructure on a grace period. Ask what the artefact is and what machine renders it the day after the subscription lapses.
Assets, fonts, scripts, a licence check, analytics, an error reporter. Ask for a yes or no, then verify it: open the artefact with the browser's network tab recording and look at the request list yourself.
The concrete version of the isolation test, and the one that most reliably produces a straight answer, because it is hard to answer "yes" loosely.
Three more worth adding to the same email:
.html file" is.Worth stating plainly, because a requirements document that treats self-hosting as a security control will be disappointed.
A file is not access control. An HTML document has no login; whoever can reach it can watch it. Any restriction has to come from the server or share you put it on.
A file cannot update itself. The property that makes it survive the vendor is the same one that means a correction requires a re-export and a redistribution. If you need one link whose contents change under the people you sent it to, hosting is the right answer and self-hosting is the wrong requirement.
Self-hosting the output says nothing about the authoring tool. Building demos will still normally require a licensed application and a live subscription. Separate the two in your requirements.
The capture is only as safe as what was on screen. Any tool recording a real application records real data if real data is displayed. That is a process control (record with a test tenant) not something a hosting model fixes.
More articles are in resources.
Export one demo, disconnect the machine, and open the file. That experiment answers more than a vendor questionnaire will.
Start your free 7-day trial