Try Warden in the Browser: How the Live Demo Works

The Warden homepage now includes a Try it out button that opens a live browser terminal. The goal is simple: let someone experience Warden's remote shell workflow without installing a client, creating an account, or sharing SSH credentials.

This is not a static video. The demo creates a disposable shell session on a small VPS, connects it to the Warden relay, and then embeds the guest terminal back into the website. It is intentionally small, but it exercises the same product ideas that matter in real support sessions: browser access, outbound host connection, policy checks, command approval, and output redaction.

It is also very honestly a budget demo. There is no expensive Kubernetes cluster behind it, no managed gateway, no load-balanced fleet, and no polished enterprise staging environment. The current VPS has 1 CPU and 1GB of memory. That is enough to prove the workflow, but not enough to invite a large crowd to hammer it at once.

##What the visitor sees

The visitor clicks Try it out on the Warden site. A modal opens, shows a short connection sequence, then loads a terminal frame. From there the visitor can type into a temporary Ubuntu shell.

Some commands are allowed immediately. Some commands are blocked by the demo policy. Sensitive reads, such as cat /etc/shadow, are allowed only through the redaction path so the visitor can see Warden mask sensitive fields before terminal output reaches the browser.

That last detail is important for the demo. A terminal security product is easier to understand when people can see the control plane act on a real command instead of reading another diagram.

The tradeoff is capacity. This demo is for a handful of curious visitors, not a benchmark. If several people open sessions at the same time, the tiny server may run out of room or start rejecting new sessions. That is a limitation of the current budget, not the intended product ceiling.

##High-level architecture

The demo has four moving parts:

• Vercel serves the marketing site and the Try it out modal.
• A VPS runs the Warden server and owns short-lived demo sessions.
• Caddy terminates HTTPS and reverse proxies traffic to the local Warden server.
• Podman starts one disposable Ubuntu container per demo session.

The browser never talks directly to Podman. It talks to the Warden guest page over HTTPS and WebSocket. The Warden server coordinates the host side and guest side of the session.

This architecture was chosen because it is cheap and understandable. One small VPS can run the relay, Caddy, and a few disposable containers. That keeps operating cost low while still showing the important technical path.

##Why build it this way on a tiny budget?

The short answer is that early infrastructure should be good enough to learn from, not expensive enough to look impressive.

At this stage, Warden does not need a production-grade demo platform with autoscaling, regional routing, and managed container orchestration. It needs a public proof that a browser can connect to a temporary shell, that commands can be mediated by policy, and that sensitive output can be redacted before it reaches the guest.

The current setup is deliberately modest:

• 1 CPU VPS.
• 1GB memory.
• Free IP-based DNS through nip.io.
• Caddy for automatic HTTPS.
• Podman containers instead of a larger orchestration stack.
• A 15-minute session TTL to avoid leaving demo shells around.

That means the demo has real constraints. It should not be treated as a hosted shell service. It is a small window into the workflow, built with the cheapest infrastructure that can still demonstrate the core idea.

##Session startup flow

When the modal opens, the frontend sends one request:

POST https://159.54.190.39.nip.io:8443/v1/demo-sessions

The Warden server creates a short-lived demo_session_id, starts a containerized demo host, waits for that host to register a session, waits for the host WebSocket to connect, and then returns a guest URL.

{
  "session_id": "sess_...",
  "guest_url": "https://159.54.190.39.nip.io:8443/s/...",
  "expires_in_seconds": 900
}

The frontend loads that guest_url inside the modal. The guest page then opens its own WebSocket connection back to Warden.

##Why HTTPS was required

The marketing site is served from Vercel over HTTPS. Modern browsers block an HTTPS page from fetching or embedding insecure HTTP content. That means a backend URL like this will fail in production:

http://159.54.190.39:8080/v1/demo-sessions

The fix is to put the demo backend behind HTTPS:

https://159.54.190.39.nip.io:8443/v1/demo-sessions

The same rule applies to the terminal frame and WebSocket connection. If the page is HTTPS, the browser terminal needs HTTPS and WSS, not HTTP and WS.

##DNS without buying a domain first

For the first public demo, the VPS uses a free wildcard DNS service:

159.54.190.39.nip.io -> 159.54.190.39

The hostname contains the IP address, and nip.io resolves it back to that IP. This is useful for early demos because it avoids waiting on registrar setup or production DNS changes.

It is not the final branding choice. It is the pragmatic choice while the project is still operating on a small budget. Buying and managing another production domain, moving DNS, and setting up a cleaner branded endpoint can wait until there is enough traffic to justify it.

A production deployment should use a proper subdomain such as:

demo.remotewarden.com

But for validating the pipeline, nip.io is enough: it gives Caddy a hostname, Let's Encrypt can issue a certificate for it, and Vercel can call it without mixed-content errors.

##Caddy in front of Warden

The VPS runs Caddy as a small Podman container. Caddy owns public HTTPS and forwards requests to the local Warden server.

159.54.190.39.nip.io:8443 {
    reverse_proxy 127.0.0.1:8080
}

The cloud firewall must allow the ports needed for certificate challenges and browser traffic:

TCP 80
TCP 443
TCP 8443

80 and 443 are for Let's Encrypt validation. 8443 is where the public demo endpoint currently lives. The Warden server itself does not need to be exposed directly to the internet.

##Disposable Ubuntu containers

Each demo session starts a fresh Ubuntu container. The Warden client binary is mounted read-only into the container, then launched in demo-host mode:

podman run --rm --name warden-demo-{demo_session_id} \
  --pull never \
  --memory 192m \
  --pids-limit 64 \
  --read-only \
  --tmpfs /tmp:rw,size=64m \
  --security-opt no-new-privileges \
  --cap-drop all \
  -e WARDEN_DEMO_SESSION_ID={demo_session_id} \
  -v /home/ubuntu/warden/bin:/opt/warden:ro \
  docker.io/library/ubuntu:24.04 \
  /opt/warden/warden demo-host \
  --server http://host.containers.internal:8080 \
  --idle-timeout 900 \
  --shell bash

The container is removed when the session ends. It is still a demo sandbox, not a hardened multi-tenant platform, but it is much safer than running arbitrary visitor commands directly on the VPS host.

The resource limits are intentionally low because the VPS is tiny. A single container gets a small memory budget and process limit. That keeps one session from consuming the whole machine, but it also means there is no promise of large parallel usage yet.

##WebSocket routing

The browser guest and the containerized host both connect to the same Warden relay, but from different network perspectives.

The guest uses the public HTTPS host:

wss://159.54.190.39.nip.io:8443/ws/guest

The demo host runs inside a Podman container, so it cannot use 127.0.0.1 to reach the host machine. It uses Podman's host alias instead:

ws://host.containers.internal:8080/ws/host

That split matters. Public URLs are for browsers. Internal relay URLs are for the containerized host process.

##Policy behavior in the demo

The demo policy is deliberately visible:

• Safe shell commands run normally.
• Dangerous commands are blocked.
• Sensitive files can trigger approval and redacted output.

For example, /etc/shadow is configured as a sensitive resource with redaction enabled. In demo-host mode, Warden automatically takes the redaction path instead of asking a human host to approve it.

The visitor sees that the command was reviewed and that output was redacted:

command approved with redacted output
root:********:...
daemon:********:...

This is a better demo than a blanket deny because it shows the product's core value: Warden can preserve a useful terminal workflow while reducing sensitive data exposure.

##Try it and send feedback

This demo is small on purpose, but it is real enough to show the core workflow. You can open the terminal, run a few commands, try a blocked command, and test the redaction path with something like cat /etc/shadow.

Because the current VPS only has 1 CPU and 1GB of memory, it may not always handle many concurrent sessions. If the demo is busy, fails to connect, or behaves strangely, that feedback is still useful. It tells me where the next bottleneck is before I spend money on a larger setup.

The project is being built in public. If you try the demo and have questions, bugs, or ideas, you can find me on GitHub at github.com/AIRemoteWarden/warden or on X at x.com/airemotewarden.

That is the point of building in public. The demo is small, but it makes Warden's promise inspectable: browser-based terminal support without handing out SSH credentials, with policy controls in the path.