Issue Resolved
Issue #42 closed: Rethink data storage: Use COOLIFY_PROJECT_ID env instead of local database
Problem
Currently the project stores Coolify data in a local database. This is problematic because:
- Uses dev database - This is stupid and fragile
- Data loss risk - If the database is emptied, all Coolify resource mappings are lost
- No single source of truth - Coolify itself should be the source of truth
Proposed Solution
Replace local database storage with a simpler approach:
Environment-based configuration
COOLIFY_PROJECT_ID=your-project-uuid
On-demand data fetching
Instead of storing Coolify data locally, fetch it from the Coolify API when needed:
GET /projects/{uuid}- Get project detailsGET /projects/{uuid}/environments- Get environments- Resources, services, databases etc. fetched on demand
Benefits
- Self-healing - If local state is lost, just re-fetch from Coolify
- Always in sync - No stale data, always reflects Coolify's current state
- Simpler setup - Just one env var instead of database migrations
- Stateless - Can be deployed anywhere without worrying about data persistence
Implementation Ideas
- Add
COOLIFY_PROJECT_IDto config - Create a
CoolifyProjectServicethat fetches and caches project data - Cache with short TTL (or use Redis) for performance
- Remove local database tables for Coolify resources
- Add artisan command to verify/test connection:
php artisan coolify:sync
Questions to Consider
- Should we cache at all, or always fetch fresh?
- What about offline/disconnected scenarios?
- How to handle rate limiting on Coolify API?