Secrets Management

Best practices for managing API keys, tokens, and other secrets with Moltbot.

Secrets Management

Properly managing secrets (API keys, tokens, passwords) is critical for security. This guide covers best practices for Moltbot deployments.

The Golden Rules

Never hardcode secrets in source code
Never commit secrets to version control
Never give agents access to production secrets
Always rotate secrets regularly

Environment Variables

The simplest and recommended approach for most setups.

Basic Setup

Create a .env file:

# .env (never commit this file!)
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxx
TELEGRAM_BOT_TOKEN=123456789:ABCdefGHI
DATABASE_URL=postgresql://user:pass@localhost:5432/db

Add to .gitignore:

.env
.env.*
!.env.example

Loading in Docker

# docker-compose.yml
services:
  moltbot:
    image: moltbot/moltbot
    env_file:
      - .env

Or pass specific variables:

services:
  moltbot:
    environment:
      - OPENAI_API_KEY=${OPENAI_API_KEY}

Secret Rotation

When to Rotate

Immediately: After any suspected compromise
Quarterly: Regular rotation schedule
On employee departure: Anyone with secret access
After incidents: Security breaches or leaks

Rotation Checklist

Generate new secret
Update in secrets manager/env file
Restart affected services
Verify everything works
Revoke old secret
Update documentation if needed

What Secrets Does Moltbot Use?

Secret	Purpose	Where to Get
`OPENAI_API_KEY`	AI provider	OpenAI Dashboard
`ANTHROPIC_API_KEY`	AI provider	Anthropic Console
`TELEGRAM_BOT_TOKEN`	Messaging	@BotFather
`DISCORD_BOT_TOKEN`	Messaging	Discord Dev Portal
`DATABASE_URL`	Storage	Your database provider

Least Privilege Principle

Don't Do This

# BAD: Production database with full access
DATABASE_URL=postgresql://admin:admin123@prod-db:5432/production

Do This Instead

# GOOD: Read-only staging database
DATABASE_URL=postgresql://readonly:xxx@staging-db:5432/staging

API Key Best Practices

Most AI providers allow you to:

Create multiple API keys
Set spending limits
Restrict permissions
Set expiration dates

Always create separate keys for:

Development
Testing
Production
Each service/deployment

Emergency Procedures

If you suspect a secret is compromised:

1. Immediate Actions

# Rotate the compromised key immediately
# For OpenAI:
# 1. Go to platform.openai.com/api-keys
# 2. Create new key
# 3. Delete old key

# For Telegram:
# Send /revoke to @BotFather

2. Update Your Deployment

# Update .env file with new key
nano .env

# Restart services
docker-compose restart

3. Audit

Check API usage for unauthorized activity
Review logs for suspicious requests
Monitor for ongoing abuse

Common Mistakes

Mistake: Committing .env file to Git

Fix: Add .env to .gitignore immediately. If already committed, rotate ALL secrets in that file.

Mistake: Sharing secrets in chat/email

Fix: Use a secrets manager or secure file transfer. If shared insecurely, rotate immediately.

Mistake: Using the same API key everywhere

Fix: Create separate keys for each environment/service. Limits damage if one is compromised.

Mistake: No spending limits on AI accounts

Fix: Set spending limits on OpenAI/Anthropic dashboards. A leaked key could cost thousands.

FAQ

Can I store secrets in the database?

Yes, if encrypted at rest. But environment variables are simpler for most cases.

What if I accidentally committed a secret?

Rotate the secret immediately
Remove from Git history: git filter-branch or BFG Repo-Cleaner
Force push (coordinate with team)
Consider the secret permanently compromised

Should I encrypt my .env file?

For most single-server setups, file permissions are sufficient. For teams, consider using a secrets manager.