Stu Mason
Stu Mason

Activity

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:

  1. Uses dev database - This is stupid and fragile
  2. Data loss risk - If the database is emptied, all Coolify resource mappings are lost
  3. 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 details
  • GET /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

  1. Add COOLIFY_PROJECT_ID to config
  2. Create a CoolifyProjectService that fetches and caches project data
  3. Cache with short TTL (or use Redis) for performance
  4. Remove local database tables for Coolify resources
  5. 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?