Demo & evaluation

Vaks PM · Demo data & evaluation · June 2026

Purpose of this guide. This document explains how to prepare a realistic demonstration dataset on an already-running Vaks PM instance, so that an evaluator can sign in and try the application against representative projects, tasks and people. It then covers how to wipe everything cleanly once the evaluation is over. It is written for a system administrator new to the product, and is fully self-contained. It does not cover installing the application itself; for that, see the deployment guides linked under Prerequisites.

Overview

Vaks PM is a multi-user project-management (PM) web application that runs entirely on infrastructure the organization controls (on-premise). To let someone evaluate it without entering data by hand, the product ships a seed: a bootstrap dataset that fills a database with a believable picture of a working company, including teams, staff, a skills catalog, clients and a portfolio of ongoing projects with tasks, schedules, time entries and workload.

The whole demo lives inside a single dedicated tenant (an isolated organization served by the instance, where each tenant has its own database). Because of that isolation, two operations cover the entire lifecycle:

Seed: fill the demo organization with the sample dataset and a known administrator account.
Reset: empty or remove the demo organization afterwards, touching nothing else on the instance.

The seed is idempotent (it can be run repeatedly without creating duplicates: each run purges then rebuilds), so a demo can be refreshed at any time and reset without risk to other data.

Prerequisites

The seed does not deploy the application; it only fills the database of an instance that is already running. The expected starting point is:

A working Vaks PM instance, deployed either on a single machine (good for evaluation) or in a multi-host high-availability topology. To stand one up first, see the deployment guides: Docker Swarm deployment or Kubernetes deployment.
The api service running in a container. The seed scripts run inside that container, where the database connection details are already available.
Shell access to the api container: directly with docker exec on a single machine, or over SSH (Secure Shell, an encrypted remote-administration protocol) to the host that runs the container in a multi-host install.

The database connection string (DATABASE_URL) is read at runtime from a cluster secret, never typed in plaintext. On Docker Swarm it is the secret database_url; in other environments it is supplied through the environment. The commands below read it from there.

If the instance serves several organizations

An instance can run in one of two tenancy modes. Dedicated mode hosts a single organization; the demo simply targets that one database. Pooled mode hosts several organizations on one instance, each resolved from its host name and isolated in its own database. In that mode the demo gets its own database (named <dbName>_demo), which must be provisioned before seeding. The seeding section covers both cases.

Seed the demo organization

The seed scripts ship with the api image and are present at /app/api/prisma/ inside the container. Two are run directly:

Script	Role
`seed-demo.js`	Builds (or rebuilds) the demo dataset. Idempotent: purges then rebuilds.
`reset-demo.js`	Empties the demo organization, or removes it entirely (see Wipe everything).

Single machine: dedicated organization

With one organization on the instance, the seed targets the single database. First locate the api container, then run the seed inside it:

# find the api container id
docker ps | grep api

# seed (DATABASE_URL is read from the cluster secret)
docker exec <api-cid> sh -c 'export DATABASE_URL=$(cat /run/secrets/database_url) \
  && cd /app/api && node prisma/seed-demo.js'

The script prints a summary in JSON (JavaScript Object Notation, a structured text format): the organization, the accounts created, and per-project counters.

Pooled mode: a dedicated demo database

When several organizations share the instance, the demo gets its own database. Two steps: provision the tenant, then seed its database. In a multi-host install the api container usually runs on an application host rather than the manager host; reach it over SSH using the access details kept in the local environment file.

Step 1, provision the demo tenant. This creates the database <dbName>_demo, applies the schema, and bootstraps the administrator account:

source .env.local
# resolve the api container id on the application host
CID=$(ssh -i "$SSH_KEY" "$VM_USER@$APP_HOST" \
  "echo '$VM_PASS' | sudo -S docker ps -q -f name=vaks-pm_api | head -1")

ssh -i "$SSH_KEY" "$VM_USER@$APP_HOST" "echo '$VM_PASS' | sudo -S \
  docker exec $CID sh -c 'export DATABASE_URL=\$(cat /run/secrets/database_url) \
  && cd /app/api && node prisma/provision-tenant.js demo admin@vaks-demo.local'"

Step 2, seed the demo database. Point DATABASE_URL at the _demo database, then run the seed:

ssh -i "$SSH_KEY" "$VM_USER@$APP_HOST" "echo '$VM_PASS' | sudo -S \
  docker exec $CID sh -c '
    BASE=\$(cat /run/secrets/database_url)
    export DATABASE_URL=\$(node -e \"const u=new URL(process.argv[1]);u.pathname=u.pathname+\\\"_demo\\\";console.log(u.toString())\" \"\$BASE\")
    cd /app/api && node prisma/seed-demo.js'"

$APP_HOST, $SSH_KEY, $VM_USER and $VM_PASS are placeholders for the host address, the SSH key path, and the login/sudo credentials kept in the administrator's local environment file. That file is never committed to source control.

Sign in and verify

All seeded accounts share the password Demo1234!. The administrator created at seed time is admin@vaks-demo.local.

Change the default password before exposing the demo. The seed credentials (admin@vaks-demo.local / Demo1234!) are well-known and intended only for a throwaway evaluation. If the instance is reachable beyond a closed environment, sign in once and change the password, or disable the account, immediately. Never reuse these credentials for anything other than the demo.

In dedicated mode, sign-in is global on the instance's host name. In pooled mode, sign-in happens on the demo tenant's subdomain (for example demo.<domain>); the shared front door resolves the tenant from the request's Host header. A successful sign-in returns an access token and the demo's projects are visible. A quick command-line check in pooled mode:

# resolve the demo subdomain to the entry point and sign in → expect a token
curl -sk --resolve demo.<domain>:443:<entry-point-ip> \
  -X POST https://demo.<domain>/api/v1/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"admin@vaks-demo.local","password":"Demo1234!"}'

Expected result: an accessToken in the response. Presenting it in an Authorization: Bearer <token> header on GET /api/v1/projects then lists the demo's projects.

What the dataset contains

The seed simulates an IT services company (Information Technology) with realistic teams, staff and a portfolio of projects. It exercises the main areas of the product so an evaluator can explore a Kanban board (task board with status columns), a Gantt chart (schedule with dependencies and critical path), time tracking, workload and capacity, the skills catalog, clients and the full project lifecycle. The content is in English and stays confined to the demo tenant.

Element	Detail
Organization	A single demo IT-services company, isolated in its own tenant.
Users	About two dozen accounts (staff plus one administrator), all with password `Demo1234!`.
Teams	Several teams (for example Infrastructure, Developers, IT Security, HR, Commercial, Project Management, Management), with team leads.
Skills	A populated skills catalog with per-person levels and per-team coverage.
Clients	A handful of clients and contacts, attached to projects.
Projects	Several projects spread across the lifecycle statuses.
Tasks	Dozens of dated tasks with estimates, priorities, milestones, and a task group with subtasks.
Dependencies	Finish-to-Start links that drive the Gantt schedule and critical path.
Time & workload	Time entries (including overtime and billable time), workload allocations and time-off entries.
Collaboration	Comments with `@mentions`.
Skill requests	Requests from a project manager to a team lead, across the open / acknowledged / resolved states.
Public holidays	A default country plus per-user country overrides, to demonstrate capacity warnings.

A few accounts carry distinct organization roles so that role-based access can be observed: a portfolio manager and a report viewer, for instance, alongside the administrator and the standard members. All share the same demo password.

Wipe everything

When the evaluation is over, reset-demo.js removes the demo content. It acts strictly on the demo organization; no other organization on the instance is affected.

# soft reset: empty the org (content + users), keep the empty organization
docker exec <api-cid> sh -c 'export DATABASE_URL=… && cd /app/api && node prisma/reset-demo.js'

# hard reset: also remove the organization record
docker exec <api-cid> sh -c 'export DATABASE_URL=… && cd /app/api && node prisma/reset-demo.js --hard'

To re-seed afterwards, run seed-demo.js again; it is idempotent.

In pooled mode the demo tenant is a separate database, so the cleanest disposal is to drop that database entirely and, if a demo is needed again later, re-provision and re-seed it. This carries no risk to any other organization on the instance.

Reset removes data permanently. Make sure the target is the demo organization (or the <dbName>_demo database in pooled mode) and not a real one before running a hard reset or dropping a database.

Where to go next

With the demo seeded and an administrator signed in, the application is ready to explore. To understand what each area does and how to drive a meaningful walkthrough (Kanban, Gantt, time tracking, workload, skills, clients, reporting and the rest), see the product guide. For operating the instance behind the demo, see operations and security.