OpportunityDAO Deployment Guide
Overview
This document helps you choose the right deployment method for your OpportunityDAO instance.
Quick Decision Matrix
| Your Setup | Recommended Method | Documentation |
|---|---|---|
| Self-hosted GitLab + EC2 | GitLab Runner (most secure) | GitLab CI |
| EC2 + Virtualmin + Multiple sites | Docker | Docker Deployment |
| EC2 + Single app + Simple setup | Systemd | Systemd Deployment |
| Managed platform (Vercel, Railway) | Native | Platform docs |
Deployment Methods
1. GitLab Runner (Most Secure for Self-hosted GitLab)
Best for:
- Self-hosted GitLab instance
- Maximum security (no SSH keys in GitLab)
- Direct deployment without network transfers
- Simplified CI/CD pipeline
Pros:
- ✅ No SSH keys needed - Most secure approach
- ✅ Runner executes directly on EC2
- ✅ Faster deployments (no file transfer)
- ✅ Simpler CI/CD configuration
- ✅ Better debugging (local logs)
- ✅ Direct access to Docker and system
Cons:
- ⚠️ Requires GitLab Runner installation on EC2
- ⚠️ One-time setup per server
Setup time: ~15 minutes
See: GitLab CI Deployment
2. Docker (Recommended for Shared Hosting)
Best for:
- Virtualmin/cPanel shared hosting
- Running multiple applications
- Strong isolation requirements
- Easy rollback capabilities
Pros:
- ✅ Complete isolation from other apps
- ✅ Consistent environment (dev = prod)
- ✅ Easy version management
- ✅ Built-in health checks
- ✅ Simple rollback (just use previous image)
Cons:
- ⚠️ Requires Docker knowledge
- ⚠️ Slightly more resources
- ⚠️ Additional layer of complexity
Setup time: ~30 minutes
See: Docker Deployment
2. Systemd (Native Linux)
Best for:
- Dedicated server
- Single application deployment
- Minimal overhead requirements
- Teams comfortable with Linux
Pros:
- ✅ Simple, native Linux
- ✅ Lower resource overhead
- ✅ Direct access to logs (journalctl)
- ✅ You're already using it (deposit processor)
Cons:
- ⚠️ Less isolation
- ⚠️ Node.js version shared with host
- ⚠️ Manual dependency management
- ⚠️ Harder rollback
Setup time: ~20 minutes
See: Systemd Deployment
3. PM2 (Alternative Process Manager)
Best for:
- Quick development deployments
- Small-scale production
- Node.js-focused teams
Pros:
- ✅ Very easy to use
- ✅ Built-in clustering
- ✅ Nice dashboard (pm2 monit)
- ✅ Fast setup
Cons:
- ⚠️ Less robust than systemd
- ⚠️ Another dependency to manage
- ⚠️ Not as common in enterprise
Quick setup:
npm install -g pm2
pm2 start npm --name opportunitydao -- start
pm2 save
pm2 startup
Your Current Setup
Based on your environment:
- Platform: EC2 (Ubuntu 24)
- Web Server: Apache
- Control Panel: Virtualmin
- Use Case: Shared hosting
- Database: PostgreSQL
Recommendation: Docker ✅
Docker provides the best isolation for shared hosting while maintaining flexibility and rollback capabilities.
Files Included
Docker Deployment
Dockerfile- Main Next.js app containerDockerfile.processor- Background job containerdocker-compose.yml- Orchestration config.dockerignore- Build optimization.gitlab-ci.yml- CI/CD pipelinedocs/DEPLOYMENT_DOCKER.md- Full guide
Systemd Deployment (Alternative)
systemd/opportunitydao-deposit-processor.service- Background jobsystemd/opportunitydao-deposit-processor.timer- Job schedulerdocs/DEPLOYMENT_SYSTEMD.md- Full guide
Deployment Checklist
Pre-Deployment
- Domain DNS pointed to EC2
- SSL certificate ready (Let's Encrypt)
- Database created and accessible
-
.envfile configured on server - GitLab CI/CD variables set
- SSH access to EC2 configured
Docker Deployment
- Docker and Docker Compose installed
- Apache modules enabled (proxy, ssl)
- Virtual host configured
- Initial
docker-compose upsuccessful - Migrations applied
- GitLab pipeline tested
Systemd Deployment
- Node.js 20 installed
- Systemd services created
- Services enabled and started
- Apache virtual host configured
- GitLab pipeline tested
Common Apache Configuration
Both deployment methods use Apache as reverse proxy.
Required modules:
sudo a2enmod proxy proxy_http proxy_wstunnel ssl headers
sudo systemctl restart apache2
Basic virtual host:
<VirtualHost *:443>
ServerName opportunitydao.com
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/opportunitydao.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/opportunitydao.com/privkey.pem
ProxyPreserveHost On
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
</VirtualHost>
Full configuration in deployment guides.
GitLab CI/CD
Both methods support automated deployment via GitLab CI/CD:
- Push to
mainbranch - Pipeline builds/syncs application
- Manual approval (or automatic)
- Deployment to EC2
- Services restart automatically
See .gitlab-ci.yml for Docker or .gitlab-ci.yml.systemd for systemd.
Environment Variables
Required for both methods:
# Core
DATABASE_URL="postgresql://user:pass@host:5432/opportunitydao"
JWT_SECRET="your-secret-key"
NEXT_PUBLIC_API_URL="https://opportunitydao.app"
# Optional blockchain RPC
BSC_RPC_URL=""
ETH_RPC_URL=""
POLYGON_RPC_URL=""
BLOCKFROST_API_KEY=""
BLOCKFROST_NETWORK="mainnet"
Store in /var/www/opportunitydao/.env on server.
Background Jobs
Both methods run the deposit processor:
Docker: Container with supercronic (cron-like) Systemd: Timer (runs every 3 minutes)
Monitors pending deposits and credits users when blockchain confirmations complete.
Monitoring
Docker
docker-compose logs -f
docker stats
Systemd
sudo journalctl -u opportunitydao-app -f
systemctl status opportunitydao-app
Rollback
Docker
docker-compose down
docker-compose up -d # Uses previous image
Systemd
cd /var/www/opportunitydao
git checkout HEAD~1
npm ci && npm run build
sudo systemctl restart opportunitydao-app
Support
For detailed instructions, see:
- Docker: Docker Deployment
- Systemd: Systemd Deployment
- Deposit Tracking: Deposit Tracking System
Next Steps
- Choose deployment method (Docker recommended)
- Follow the relevant deployment guide
- Setup GitLab CI/CD pipeline
- Test deployment
- Configure monitoring and backups