Demo & evaluation

Vaks PM · Demo data & evaluation · June 2026

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.

Which mode am I in, and what exactly do I fill in?

Two axes decide the exact steps. They are independent — pick your row in each.

The demo always uses the same fixed values: organization slug demo, administrator admin@vaks-demo.local, password Demo1234! (shared by every seeded account). The seeded accounts come in ready to use (each already holds a seat), so the demo works the moment it is loaded — nothing has to be granted by hand.

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:

Option A — seed at deploy time (from the manifest, pooled)

The cleanest way to have a demo ready the instant the instance comes up is to declare it in the deployment manifest (infra/cluster.json), so the orchestrator provisions and seeds it during bash out/deploy-ssh.sh — no manual step afterwards. Add a tenant to the tenants array carrying a "seed" field:

"tenants": [
  {
    "slug": "demo",
    "domain": "demo.<baseDomain>",
    "seed": "demo"
  }
]

At deploy time the orchestrator runs provision-tenant.js demo --seed demo, which creates the tenant database <dbName>_demo, applies the schema and loads the demo dataset. The "seed" field is the only demo-specific value; every other field is an ordinary tenant entry (see Provisioning tenants for the full schema). This path is for pooled tenancy — the demo is then reached at demo.<baseDomain>. To add a demo to an already-running pooled instance instead, use the post-deploy path below.

Option B — post-deploy, pooled tenancy (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. This is the manual equivalent of Option A, for adding a demo after the instance is already up. In a multi-host (HA) 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'"

Sign in and verify

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

Sign-in happens on the demo tenant's subdomain (for example demo.<baseDomain>); the shared front door resolves the tenant from the request's Host header. The login is always admin@vaks-demo.local / Demo1234! — the email is an account identifier, not the host name. A successful sign-in returns an access token and the demo's projects are visible. A quick command-line check:

# 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!"}'

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.

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.

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.

Related: Product guide · Docker Swarm deployment · Kubernetes deployment · Operations · Security · Documentation home