Why Separate Breezes?
Running each project on its own Breeze provides isolation, independent scaling, and cleaner resource management. If one project experiences a traffic spike or security issue, your other projects remain unaffected.
Organizing Your Breezes
Use a consistent naming scheme in your portal to keep projects organized:
- project-name-env format (e.g.,
shopify-clone-prod,blog-staging) - Tag Breezes with project names for easy filtering
- Document which Breeze serves which project and domain
Right-Sizing Each Breeze
Not every project needs the same resources. Choose plans based on actual workload:
- Static sites or blogs -- minimal plan with 1 vCPU, 1 GB RAM
- Web applications -- mid-tier plan with 2 vCPUs, 4 GB RAM
- Databases or compute-heavy tasks -- higher plan with 4+ vCPUs, 8+ GB RAM
Managing Billing Across Projects
Your portal dashboard shows all active Breezes with their individual costs. To track spending per project:
- Review the billing summary which lists charges per Breeze
- Use invoices to verify each Breeze's monthly cost
- Consider separate teams or organizations if projects have different billing contacts
Networking Between Breezes
If projects need to communicate (e.g., an API server and a frontend), configure firewall rules to allow traffic only between specific Breeze IPs:
# On the API Breeze, allow connections from the frontend Breeze
sudo ufw allow from 198.51.100.20 to any port 3000Best Practices
- Never run unrelated production projects on the same Breeze
- Use staging Breezes for testing before deploying to production
- Snapshot or back up each Breeze independently on its own schedule