How to demo on-prem software without shipping a VM

You can demo on-prem or air-gapped software without shipping a VM. Capture the product's front end from a demo install you control. Replace the data with sample data. Then give the buyer a clickable copy of the screens. The environment, the back end and any real data never leave your network. You bring up a live install only for the parts of the evaluation that need one, which is usually the proof of concept.

That is the short answer. The rest of this piece covers why the VM became the default, what each type of captured demo can and can't do, and how to tell which part of your evaluation needs which.

Why does on-prem software end up demoed from a VM?

Because a VM is the only way to send the product without sending a person. If the software runs in the customer's data centre, the seller has no hosted account to point a buyer at. So presales packs the whole stack into an image and ships it, or hosts one per buyer.

That costs time. Internal Storylane data from the call analysis behind our Modern Buying Trends 2026 report includes one ERP company that put a number on it. It took eight hours to build a single demo on a VM, and the VM could not be reset afterwards. Every buyer after the first gets either a messy environment or another day of SE time.

The bigger cost is harder to see. A VM is something the buyer's security team now has to review. They want to know what is in the image, what it connects to, and whose data it holds. You set out to answer questions about the product, and you created new questions about the demo.

Show the front end and keep the environment at home

Here is the idea I'd hold on to. In most on-prem evaluations, the buyer needs to see the front end long before they need to touch the environment. They want to see the workflow, the screens, and what a user would see on a normal Tuesday morning. None of that needs the database, the services or the network behind them to travel.

So split the demo in two. The front end travels. It is a captured, clickable copy of the interface with sample data in it. The environment stays at home. That is the live install, the integrations and anything with real data, used by your SE on a call or by the buyer in a proof of concept you plan together.

This matters more for on-prem vendors than for anyone else. Storylane looked at 300 recorded conversations with about 150 B2B software companies (Aug 18 to Sep 10, 2026). In that internal Storylane data, contracts and regulation made up 43% of the 28 reasons sellers gave for why buyers can't try the software on their own. On-prem and air-gapped products sit almost entirely inside that 43%. Limited access isn't a sales choice. It was usually settled in a contract years ago.

Is a captured demo just a recording?

Visitors to our booth at industry events in October 2026 asked exactly this. They also asked how a captured demo copies the front end. Those are the right questions, and the answer depends on the type of capture.

• Screenshots or video. A series of images with hotspots and guide text on top. You can click through it like a slideshow. It is fast to make and works for anything on a screen, including desktop software.
• HTML capture. The tool saves the page as your browser drew it (the HTML and CSS). Buttons, scrolling and menus behave like the real thing, and you can edit any text, number or chart in the copy. Nothing behind it runs. There is no server, no query and no live data.
• Sandbox. Several HTML captures linked together, so the buyer can explore beyond a set path. It feels like the product, with the same safe, static copy underneath.

So a captured demo is more than a recording and less than the full product. It looks and clicks like the software, and it shows what you captured. I think that trade is exactly right for on-prem. The missing back end is the very thing that makes it safe to send. For a longer comparison of the formats, see screenshot or HTML, picking the right demo format.

What does an on-prem buyer actually worry about?

Where their data goes. The Storylane Buyability Index scanned 529 B2B websites between Sep 8 and Oct 20, 2026, and checked each site against questions a buyer would plausibly ask. Two caveats apply every time I quote it. The questions were generated per company, not logged from real buyers. And the sites were chosen by the people who ran the scans.

In that set, questions about how the product is deployed ("do you support on-premises deployment?", "can we self-host?") got a full answer on the website 80% of the time (66 of 83). Questions about where data is stored ("where is our data stored, and can we choose the region?") got a full answer 42% of the time (141 of 334). They got a partial answer 53% of the time.

I have a theory for the gap. "Do you run on-prem?" is about a feature, and vendors are proud of features. "Where does our data go?" is a promise, and promises need legal sign-off. On-prem vendors answer the first question easily. A shipped demo VM quietly reopens the second, because it is a copy of your software, with someone's data in it, outside your control.

A captured front end is much easier to defend if you build it with that question in mind.

1. Capture from a demo install you own, never from a customer's environment. The capture is only as clean as the screen it came from.
2. Replace data before you share. In an HTML capture, every name, number and record is editable text. Swap it for sample data, and blur or delete what you can't swap.
3. Remember where the copy is stored. If your demo tool is a cloud service, the captured pages are stored there. That is fine for sample data, and one more reason to never capture real data.
4. Control the link. Password protection, link expiry and access limited to the buyer's email domain mean the copy reaches the people you meant it for and stops working when the evaluation ends.

What if the buyer's network is air-gapped too?

Then the buyer may not be able to open a cloud link from their desk. You have three options. Here they are in the order I'd try them.

• Let the champion review it from a normal laptop. Most air-gapped teams still have company laptops on the internet for email and research. The evaluation team rarely sits inside the secure network.
• Send an offline copy. Some demo tools, Storylane included, let you download a demo to view offline (Storylane records no analytics in that mode). Whether a file may enter a secure network is the buyer's decision, so ask before you send it.
• Send a static export. A PDF of the walkthrough is the simplest leave-behind. It loses the clicking but keeps the screens and the story.

All three work the same way. You are sending pictures of the interface, not software. That is a far easier conversation with a security officer.

When do you still need the VM?

When the buyer's question can only be answered by the software running. I would keep a live environment for these cases.

• Proof of concept. Performance at their scale, behaviour on their hardware, and how it fails. A copy of the front end proves none of that.
• Their own data. In the same internal Storylane call analysis, 25% of the reasons were that the product does nothing until the buyer's own data or systems are connected. If your product is in that group, the proof of concept is the demo.
• Integration questions. "Will it work with our directory, our SIEM, our mainframe?" needs a live system, not a picture of a settings page.
• Unscripted technical deep dives. A captured demo follows the path you recorded. An architect who wants to test edge cases needs an SE and a lab.

The win is not getting rid of the VM. It is moving the VM to the end of the evaluation. One well-planned environment replaces a fresh build for every buyer who only wanted to see a screen. The SE's guide to demo environment types maps which environment fits which stage. When sandbox demos won't work lists the cases where a copy is the wrong format.

How this works in Storylane

We make a demo tool, so weigh this section with that in mind. Storylane's HTML capture runs from a Chrome extension. Open your demo install in the browser and record. Storylane saves an editable HTML and CSS copy of the interface, where you can blur, edit or delete sensitive data. For desktop software, the Mac and Windows apps capture screens from any desktop application (see how to build a desktop app demo). Demos can be password protected, set to expire and limited to an email domain.

Storylane is a good fit for on-prem and air-gapped vendors whose buyers need to see the workflow before a proof of concept. Here is how the plans line up.

• Screenshot and video demos start on Starter, at $50 a month billed monthly or $40 a month billed yearly.
• HTML capture starts on Growth, at $625 a month billed monthly or $500 a month billed yearly.
• Sandbox demos are on Enterprise, which has custom pricing.

What to do on Monday

Look at the last five buyers who asked for a demo environment. Write down what each one actually needed to see before the proof of concept. If most of it was screens and workflows, capture those from your lab once, replace the data, and send the copy instead of building the next VM. Save the eight hours for the buyer who is ready for a live environment.

If you want to see what that looks like for your product, book a demo with our team and bring the screen your SEs rebuild most often.