Strategy: Scaling BukidBountyApp for Multiple Companies

This document outlines the recommended approach for deploying BukidBountyApp across different companies while maintaining efficiency and code quality.

Comparison of Approaches

Feature	Option 1: Split Repositories	Option 2: Single Codebase (Multi-Instance)
Maintenance	High Overhead. A bug fix in one repo must be manually copied to others.	Low Overhead. One fix in the main repo benefits all instances.
Consistency	Low. Repos will drift apart over time, making cross-support difficult.	High. All companies run the same version of the platform.
Customization	Easy. Just edit the code for that one company.	Config-Driven. Use environment variables or flags to toggle features.
Data Privacy	Physical Isolation. Separate repos usually mean separate DBs.	Physical Isolation. Each instance connects to its own database.
Scalability	Poor. Adding a 4th company requires another repo and more maintenance.	Excellent. Just add a new deployment in Dokploy.

Proposed Plan: Single Codebase, Multi-Instance

I propose a Single Codebase approach using Environment-Based Deployments. This is the standard "Best Practice" for SaaS-like applications.

1. Repository Management

Keep one single repository for all core logic.
Use branches (production, staging) to manage release cycles.
Every company pulls from the same codebase.

2. Deployment Architecture (Dokploy)

Instead of one Dokploy project, you create multiple deployments pointing to the same repository:

Instance A: company-a.bukid.app
Instance B: company-b.bukid.app
Instance C: company-c.bukid.app

3. Environment Variables (.env) for Customization

Use the .env file for each instance to differentiate the identity and behavior:

# Instance A .env
APP_NAME="Company A Bounty"
APP_URL="https://company-a.bukid.app"
PRIMARY_COLOR="#4CAF50"
DB_DATABASE="bukid_company_a"
ENABLE_MODULE_FARMER=true

# Instance B .env
APP_NAME="Company B Marketplace"
APP_URL="https://company-b.bukid.app"
PRIMARY_COLOR="#2196F3"
DB_DATABASE="bukid_company_b"
ENABLE_MODULE_FARMER=false

4. Code Adjustments for Customization

To make the UI "dynamic" based on the company:

Identity: Use {{ config('app.name') }} in the frontend (passed via Inertia or API).
Theming: In app.js or index.css, use CSS variables that can be injected based on environment.

Features: Wrap specific modules (like Farmer Management) in Feature Flags:

// In a Controller or Vue component
if (config('features.farmer_module')) {
    // Show farmer features
}

5. Database Isolation

Since each instance has its own DB_DATABASE env variable, the data is physically isolated. This ensures that:

Company A cannot see Company B's data.
Migrations are run per instance.
You can backup/restore Company A without affecting others.

Migration Steps (Advice)

Audit hardcoded strings: Scan the code for "BukidBounty" and replace them with config('app.name').
Move Colors to variables: If you have hardcoded colors in CSS, move them to :root variables in index.css and allow them to be overridden or controlled by the app name.
Setup Dokploy Multi-Project: Create a second project in Dokploy, use the same SSH key/Repo URL, and configure a second database.
Feature Toggles: Create a config/features.php file that reads from env() to enable/disable specific modules for specific companies.

Conclusion

Option 2 (Single Codebase) is the significantly better long-term choice. It prevents "Maintenance Hell" and ensures that as you improve the app for one company, you are improving it for everyone.

3.8 KiB Raw Blame History