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?
All team members use the same tool regardless of database type
Deploy once, team accesses via browser—no individual setups
Use separate database users for read-only, editing, and admin workflows
Save multiple database connections for easy team access
Combine reverse-proxy logs, database-native auditing, and CLI checks in team workflows
SSL/TLS encryption, reverse proxies, and network isolation
Deployment Options
Option 1: Docker Deployment (Recommended for Teams)
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
Tip
Environment-defined profiles (such as WHODB_POSTGRES_1) put connection details in your deployment config so team members pick a profile on the login page instead of typing credentials. See Database Connectivity for the format.
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.
Tip
Use http://localhost:3000 for local testing, or replace with your server's IP/hostname for team access.
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
Warning
WhoDB stores login sessions in a per-instance encrypted store, so a single replica is the simplest reliable setup. If you run multiple replicas, you must configure session affinity (sticky sessions) on your load balancer and set a shared WHODB_ENCRYPTION_KEY across replicas — otherwise logins will intermittently fail.
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
Warning
Never expose WhoDB over HTTP in production. Always use HTTPS/SSL encryption.
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.
Warning
Establish clear policies to prevent data breaches:
- Never store production credentials in version control
- Use strong, unique passwords for each database user
- Create separate users for different access levels
- Rotate credentials when team members leave
- Audit query history regularly
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
All team connections encrypted with SSL/TLS
Restrict WhoDB access to team networks/VPN
Enforce complex passwords for database users
Give read-only where possible, full access only when needed
Log and review all queries regularly
Change database passwords monthly
Automated daily backups with offsite storage
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
Info
Setting up WhoDB for your team is straightforward, but if you need guidance:
- Check the Installation Guide
- Review Database Connectivity
- Read Security Best Practices
Check
After completing this guide, your team has WhoDB deployed securely, read-only and read-write access configured, and backup and monitoring in place.