Getting Started Guides

Team Setup Guide for WhoDB

Team Setup Guide for WhoDB

Managing databases across a team requires the right tools and proper workflows. WhoDB makes it simple to give your entire team secure, intuitive database access. This guide walks you through setting up WhoDB for your team, from initial deployment to establishing best practices.

Why WhoDB for Teams?

Unified Interface

All team members use the same tool regardless of database type

No Installation Per User

Deploy once, team accesses via browser—no individual setups

Database-Side Access Control

Use separate database users for read-only, editing, and admin workflows

Connection Profiles

Save multiple database connections for easy team access

Operational Visibility

Combine reverse-proxy logs, database-native auditing, and CLI checks in team workflows

Secure

SSL/TLS encryption, reverse proxies, and network isolation

Deployment Options

Docker is the simplest way to deploy WhoDB for your team. Everyone connects to a single instance that handles all databases.

Prerequisites:

  • Docker and Docker Compose installed
  • Server with at least 2GB RAM
  • Network access from your team

Step 1: Create docker-compose.yml

YAML

version: '3.8'

services:
  whodb:
    image: clidey/whodb:latest
    container_name: whodb
    ports:
      - "3000:8080"
    environment:
      PORT: 8080
      WHODB_LOG_LEVEL: info
      # Optional: environment-defined connection profile shown on the login page
      # WHODB_POSTGRES_1: '{"alias":"staging","host":"staging-db.internal","user":"whodb_readonly","database":"myapp","port":"5432","password":"..."}'
    restart: unless-stopped
    networks:
      - whodb_network

  # Optional: PostgreSQL for testing
  postgres:
    image: postgres:15-alpine
    container_name: postgres_demo
    environment:
      POSTGRES_PASSWORD: demo_password
      POSTGRES_DB: demo_db
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - whodb_network
    # Only expose if needed for local testing
    # ports:
    #   - "5432:5432"

volumes:
  postgres_data:

networks:
  whodb_network:
    driver: bridge

Step 2: Deploy

Bash

# Copy the above YAML to docker-compose.yml
# Start the services
docker-compose up -d

# Verify it's running
docker-compose logs -f whodb

# Check status
docker ps | grep whodb

Step 3: Access WhoDB

Navigate to http://your_server:3000 in your browser. WhoDB is now accessible to your team.

Option 2: Kubernetes Deployment

For large teams with Kubernetes infrastructure:

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whodb
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: whodb
  template:
    metadata:
      labels:
        app: whodb
    spec:
      containers:
      - name: whodb
        image: clidey/whodb:latest
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: whodb-service
spec:
  selector:
    app: whodb
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: LoadBalancer

Deploy with:

Bash

kubectl apply -f whodb-deployment.yaml

Option 3: Traditional Server Deployment

For teams without Docker or Kubernetes:

Bash

# Build the server from source
git clone https://github.com/clidey/whodb.git
cd whodb/core
go build ./cmd/whodb

# Run as background service
./whodb &

# Or use systemd
sudo systemctl start whodb

Securing Your Team Instance

Enable HTTPS/SSL

Put WhoDB behind a TLS-terminating reverse proxy. With nginx and a Let's Encrypt certificate (sudo certbot certonly --standalone -d yourdomain.com):

nginx

server {
    listen 443 ssl http2;
    server_name yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    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;
        proxy_cache_bypass $http_upgrade;
    }
}

# Redirect HTTP to HTTPS
server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$server_name$request_uri;
}

Enable the site and reload nginx (sudo nginx -t && sudo systemctl restart nginx). When WhoDB is served over HTTPS this way, also set WHODB_SECURE=true so the session cookie is marked Secure (see Installation).

Network Security

Managing Database Connections for Your Team

Creating Shared Connection Profiles

Instead of giving team members raw credentials, create connection profiles:

Managing Multiple Database Access Levels

Production Environment:

Level 1: Analysts (Read-Only)
- Can view all data
- Cannot modify or delete
- Cannot access sensitive tables

Level 2: Developers (Read-Write)
- Can view and edit data
- Can run queries
- Cannot drop tables

Level 3: DBAs (Admin)
- Full access
- Can modify schema
- Can backup/restore

Implementation:

sql

-- PostgreSQL example: Create three access levels

-- Level 1: Read-only
CREATE USER analyst_user WITH PASSWORD 'analyst_pass';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO analyst_user;

-- Level 2: Read-write
CREATE USER developer_user WITH PASSWORD 'dev_pass';
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO developer_user;

-- Level 3: Admin (superuser or high privileges)
CREATE USER dba_user WITH SUPERUSER PASSWORD 'dba_pass';

Workflow Templates for Teams

Template 1: Daily Data Review

Scenario: Your team reviews key metrics daily

Template 2: QA Data Preparation

Scenario: QA team needs consistent test data

Template 3: Debugging Production Issues

Scenario: Customer reports a bug, team needs to investigate

Team Practices

Keep a short team guide covering how to connect to each database, which environments are production vs. test, common queries, and who to ask for help. For query sharing and documentation practices, see Team Collaboration and Database Documentation.

Onboarding: create a restricted database user at the right access level, hand over the team guide, help with a first connection to the development database, and grant production access only once they're ready.

Offboarding: immediately disable the person's database accounts, review database-native audit logs for recent access, rotate any shared credentials they knew, and transfer their SQL files or exported reports to the owning team.

Monitoring and Maintenance

Regular Backups

Back up the databases your team works with using the database's native tools on a schedule, for example a nightly pg_dump per database from cron, keeping the last 30 days:

Bash

# crontab: daily at 2 AM
0 2 * * * pg_dump -U "$DB_USER" -h "$DB_HOST" myapp_prod > /backups/myapp_prod_$(date +\%Y\%m\%d).sql

Performance Monitoring

Monitor WhoDB instance health:

Bash

# Check system resources
docker stats whodb

# Check error logs
docker logs whodb | grep -i error

# Monitor database connections
# In WhoDB Scratchpad:
SELECT count(*) FROM pg_stat_activity;

Upgrading WhoDB

Keep your instance updated:

Bash

# Pull latest image
docker pull clidey/whodb:latest

# Restart with the new image
docker-compose down
docker-compose up -d

# Verify it's running
docker ps | grep whodb

Troubleshooting Team Issues

Team Access Management

For larger teams, manage database access through your database roles, network controls, and your team's password manager.

Recommended controls:

  • Use read-only database users for exploration.
  • Keep write credentials limited to trusted operators.
  • Store shared credentials in your password manager.
  • Restrict WhoDB access to trusted networks.
  • Review saved browser profiles on shared machines.

Security Checklist for Production Teams

Enable HTTPS

All team connections encrypted with SSL/TLS

Firewall Rules

Restrict WhoDB access to team networks/VPN

Strong Passwords

Enforce complex passwords for database users

Read-Only Access

Give read-only where possible, full access only when needed

Query Auditing

Log and review all queries regularly

Credential Rotation

Change database passwords monthly

Backup Strategy

Automated daily backups with offsite storage

Access Reviews

Quarterly review of who has access to what

Scaling as Your Team Grows

  • 3-10 people: a single WhoDB instance, a shared development database, read-only production access, and basic documentation.
  • 10-50 people: a dedicated Docker deployment, separate dev/staging/prod connections, database-side role-based access control, regular backups, and database-native audit logging.
  • 50+ people: a Kubernetes deployment (see the sticky-session note above if you run multiple replicas), database-side pooling or proxies where needed, monitoring and alerting, and compliance-grade audit logging.

WhoDB itself is free and open source, so the only costs are the infrastructure you run it on — typically a small VPS, backup storage, and free Let's Encrypt certificates.

Getting Help for Team Setup