Production Checklist
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
| Item | Status |
|---|---|
| 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 |