CLI Commands

Production Checklist

Security hardening and operational best practices for production deployments.

Cognova gives an AI agent unrestricted access to the machine it runs on. Before exposing it to any network, work through this checklist.

Security

Use a Dedicated Machine

Never run Cognova on a personal computer or alongside sensitive workloads. Use a dedicated:

  • Virtual machine (e.g., a VPS from Hetzner, DigitalOcean, Linode)
  • Docker container with limited host access
  • Isolated cloud instance

The embedded terminal and Claude Code CLI can read, write, and execute anything the process user has access to.

Put a Reverse Proxy with TLS in Front

Never expose port 3000 directly to the internet. Use a reverse proxy:

Caddy (automatic HTTPS):

cognova.yourdomain.com {
    reverse_proxy localhost:3000
}

Nginx:

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

    ssl_certificate     /etc/letsencrypt/live/cognova.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/cognova.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_set_header X-Real-IP $remote_addr;
    }
}

The Upgrade and Connection headers are required for WebSocket support (terminal and chat features).

Change Default Credentials

If you skipped setting credentials during cognova init, the defaults are admin@example.com / changeme123. Change them immediately.

Generate a Strong Auth Secret

The BETTER_AUTH_SECRET signs session tokens. Use a cryptographically random value:

openssl rand -base64 32

See the Configuration reference for all security-related variables.

Restrict Network Access

Use firewall rules to limit who can reach the app:

# UFW example: allow only your IP
sudo ufw allow from YOUR_IP to any port 443
sudo ufw deny 3000

Do Not Store Secrets on the Machine

Avoid placing SSH keys, cloud credentials, API keys, or production secrets on the Cognova host. The agent has full file system access and could inadvertently read or expose them.

Operations

Configure Swap (Small VMs)

Nuxt builds can exhaust memory on VMs with less than 4 GB RAM. Add swap:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab

PM2 Log Management

PM2 logs grow unbounded by default. Install the log rotation module:

pm2 install pm2-logrotate
pm2 set pm2-logrotate:max_size 50M
pm2 set pm2-logrotate:retain 7

Logs are stored in <install-dir>/logs/.

PM2 Startup on Boot

Ensure Cognova restarts after a server reboot:

pm2 startup
pm2 save

Monitor Resources

pm2 monit          # Real-time CPU/memory
pm2 logs cognova   # Tail logs

Database Backups

For local PostgreSQL (Docker):

docker exec cognova-db pg_dump -U postgres cognova > backup.sql

For hosted databases (Neon, Supabase), use the provider's backup features.

Health Endpoint

The app exposes GET /api/health which returns:

{
  "status": "ok",
  "database": { "available": true }
}

Use this for uptime monitoring (e.g., UptimeRobot, Healthchecks.io).

Pre-Launch Checklist

ItemStatus
Dedicated VM or container
Reverse proxy with TLS configured
BETTER_AUTH_SECRET is a random 32+ byte value
BETTER_AUTH_URL matches the public URL exactly
Default admin credentials changed
Firewall restricts access to trusted IPs
No SSH keys or cloud creds on the host
Swap configured (if < 4 GB RAM)
PM2 log rotation installed
PM2 startup hook configured
Database backups scheduled
Health endpoint monitored
cognova doctor reports all checks passing