Open Source Demo Platform: Self-Host Your Product Demos

Why Self-Host Your Demos?

Most demo platforms are SaaS-only. You upload your content to their servers, and they host everything. For many teams, that's fine. But some organizations have requirements that make self-hosting essential:

Security & Compliance

Financial services, healthcare, and government organizations often can't send data to third-party SaaS platforms. Even demo content—API schemas, example data, workflow screenshots—may be considered sensitive.

Self-hosting keeps everything within your security perimeter. No data leaves your network. No third-party access to your content.

Air-Gapped Networks

Some environments have no internet access by design. Defense contractors, secure research facilities, and critical infrastructure operators need tools that work completely offline.

SaaS demo platforms are useless in these environments. Self-hosted solutions work anywhere you can run a web server.

Cost at Scale

SaaS pricing often scales with users or views. At enterprise scale, costs can grow quickly. Self-hosting has fixed infrastructure costs regardless of usage.

Vendor Independence

What happens if your demo vendor gets acquired, pivots, or shuts down? With a self-hosted open-source solution, your demos keep working. You own the code and the content.

Self-Hosting Options Compared

Most demo platforms offer no self-hosting option. DemoScript is MIT-licensed open source—you can deploy it anywhere, modify it as needed, and use it commercially without restrictions.

Self-Hosting DemoScript: Three Approaches

Option 1: Static Export (Simplest)

The easiest approach is building static HTML files and hosting them on any web server. This works for demos with pre-recorded responses (no live API execution).

npm install -g demoscript

# demo.yaml
title: "API Quick Start"
settings:
  base_url: "https://api.example.com"
steps:
  - slide: |
      # Welcome
      Let's explore the API.
  - rest: GET /users
    title: "List Users"

demoscript record ./my-demo

demoscript build ./my-demo -o dist

Pros: Simple deployment, works offline, no runtime dependencies.
Cons: No live API execution—viewers see pre-recorded responses.

Option 2: Node.js Server (Live Execution)

For demos that need to execute live API calls, run DemoScript as a Node.js application.

git clone https://github.com/aximcode/demoscript.git
cd demoscript
npm install
npm run build

demoscript serve ./my-demo --port 3000 --host

# nginx example
server {
    listen 443 ssl;
    server_name demos.yourcompany.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
    }
}

Pros: Live API execution, real-time responses.
Cons: Requires Node.js runtime, more infrastructure to manage.

Option 3: Docker Container

For teams with container infrastructure, Docker provides consistent deployments.

FROM node:20-alpine
WORKDIR /app

# Install DemoScript globally
RUN npm install -g demoscript

# Copy your demo files
COPY ./my-demo /app/demo

EXPOSE 3000

CMD ["demoscript", "serve", "/app/demo", "--port", "3000", "--host"]

docker build -t my-demo .
docker run -p 3000:3000 my-demo

Pros: Portable, reproducible, works with existing container infrastructure.
Cons: Container runtime required.

Air-Gapped Deployment

For networks with no internet access:

1. On a connected machine: Download DemoScript and all npm dependencies
2. Bundle everything: Create a tarball with node_modules included
3. Transfer: Move via approved media (USB, secure file transfer)
4. Deploy: Extract and run on the air-gapped network

# On connected machine
npm pack demoscript
# Transfer the .tgz file
# On air-gapped machine
npm install ./demoscript-*.tgz

For static exports, you don't even need Node.js on the target—just a web server to serve HTML files.

Security Considerations

API Credentials

If your demos execute against real APIs, be careful with credentials:

• Use read-only API keys when possible
• Scope permissions to only what the demo needs
• Consider a demo-specific environment/database
• Never commit credentials to your demo repository

Network Isolation

Run demo servers in isolated network segments. They should only be able to reach the APIs they need to demonstrate.

Access Control

For internal demos, put them behind your SSO or VPN. DemoScript supports password protection for individual demos via YAML configuration.

When to Use Cloud Instead

Self-hosting isn't always the best choice. Consider the managed cloud platform if:

• You don't have strict compliance requirements
• Your team doesn't want to manage infrastructure
• You need analytics and collaboration features
• You want automatic updates and new features

DemoScript Cloud offers hosted demos, analytics, team collaboration, and custom domains—without the operational overhead. It's $9/month for individuals or $19/month per user for teams.

Summary

Self-hosting product demos makes sense when you have security requirements, compliance constraints, or need to operate in air-gapped environments. DemoScript is one of the few demo tools that supports this—it's MIT-licensed open source that you can deploy anywhere.

Three deployment options:

• Static export: Build HTML files, host anywhere, works offline
• Node.js server: Live API execution, run behind reverse proxy
• Docker container: Portable deployment to any container platform

The MIT license means you can use DemoScript commercially, modify it, and distribute it without restrictions. No vendor lock-in, no surprise pricing changes, no dependency on a third party's roadmap.