Playground architecture: how we built a zero-setup demo

[ferhimedamine]

The goal

We wanted a live demo of Dakera that any developer could try in 30 seconds — no account, no API key, no backend to spin up. The result is the Dakera Playground, which lets you interact with a live memory server in your browser.

Here’s a behind-the-scenes look at how it works.

The constraint: truly zero setup

Most "live demo" playgrounds cheat a little. They use a shared cloud database where all users share state, or they require you to sign up before you can do anything meaningful. We wanted something different: each visitor gets an isolated, stateful session with no signup required.

Architecture

The playground is a static frontend (no server-side rendering) that calls the real Dakera REST API:

Browser → REST API (same server as production)
              → Vector index (per-session isolation)
              → Decay engine

Each playground session is backed by an ephemeral agent_id scoped to that tab. When you run a scenario, the browser sends real API calls:

# What the browser actually sends:
POST /v1/memories
{
  "agent_id": "playground-session-abc123",
  "content": "User said: I like hiking and mountain biking",
  "importance": 0.75
}

POST /v1/memories/recall
{
  "agent_id": "playground-session-abc123",
  "query": "What are the user's outdoor interests?"
}

Seven live scenarios

The playground ships with 7 guided scenarios, each demonstrating a different memory pattern:

1. Conversational memory — store and recall across turns
2. Importance scoring — see how high vs. low importance affects recall rank
3. Session isolation — memories scoped to a session, not shared globally
4. Memory decay — watch low-importance memories fade over time
5. Semantic search — recall by meaning, not keyword
6. Tag filtering — retrieve memories by category
7. Multi-agent — isolated memory namespaces per agent

Each scenario shows the raw API request, the response, and explains what’s happening under the hood.

Why Docker Compose made this possible

The self-hosted Dakera server runs as a single container with no external dependencies (no Postgres, no Redis, no separate vector database):

docker compose -f docker/docker-compose.local.yml up -d
# Server ready at http://localhost:3000

This meant we could run a playground server at very low cost without provisioning multiple managed services. The same configuration developers use locally is what powers the demo.

Lessons learned

• Rate limiting per session is essential. Without it, a single user can exhaust server resources. We rate-limit at the API layer by playground session ID.
• Scenario descriptions matter more than you think. The most common user feedback was “what is this showing me?” — we added an explanation panel to each scenario.
• Keep the state visible. Showing the raw JSON request/response built more trust than hiding it behind a friendly UI.

---

We’re curious: what would you build with a self-hosted Dakera instance? Any scenarios you’d want to see in the playground?