# CLAUDE.md This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. ## Project Overview Coolify is an open-source, self-hostable platform for deploying applications and managing servers - an alternative to Heroku/Netlify/Vercel. It's built with Laravel (PHP) and uses Docker for containerization. ## Development Commands ### Frontend Development - `npm run dev` - Start Vite development server for frontend assets - `npm run build` - Build frontend assets for production ### Backend Development Only run artisan commands inside "coolify" container when in development. - `php artisan serve` - Start Laravel development server - `php artisan migrate` - Run database migrations - `php artisan queue:work` - Start queue worker for background jobs - `php artisan horizon` - Start Laravel Horizon for queue monitoring - `php artisan tinker` - Start interactive PHP REPL ### Code Quality - `./vendor/bin/pint` - Run Laravel Pint for code formatting - `./vendor/bin/phpstan` - Run PHPStan for static analysis - `./vendor/bin/pest` - Run Pest tests ## Architecture Overview ### Technology Stack - **Backend**: Laravel 12 (PHP 8.4) - **Frontend**: Livewire 3.5+ with Alpine.js and Tailwind CSS 4.1+ - **Database**: PostgreSQL 15 (primary), Redis 7 (cache/queues) - **Real-time**: Soketi (WebSocket server) - **Containerization**: Docker & Docker Compose - **Queue Management**: Laravel Horizon ### Key Components #### Core Models - `Application` - Deployed applications with Git integration (74KB, highly complex) - `Server` - Remote servers managed by Coolify (46KB, complex) - `Service` - Docker Compose services (58KB, complex) - `Database` - Standalone database instances (PostgreSQL, MySQL, MongoDB, Redis, etc.) - `Team` - Multi-tenancy support - `Project` - Grouping of environments and resources - `Environment` - Environment isolation (staging, production, etc.) #### Job System - Uses Laravel Horizon for queue management - Key jobs: `ApplicationDeploymentJob`, `ServerCheckJob`, `DatabaseBackupJob` - `ServerManagerJob` and `ServerConnectionCheckJob` handle job scheduling #### Deployment Flow 1. Git webhook triggers deployment 2. `ApplicationDeploymentJob` handles build and deployment 3. Docker containers are managed on target servers 4. Proxy configuration (Nginx/Traefik) is updated #### Server Management - SSH-based server communication via `ExecuteRemoteCommand` trait - Docker installation and management - Proxy configuration generation - Resource monitoring and cleanup ### Directory Structure - `app/Actions/` - Domain-specific actions (Application, Database, Server, etc.) - `app/Jobs/` - Background queue jobs - `app/Livewire/` - Frontend components (full-stack with Livewire) - `app/Models/` - Eloquent models - `app/Rules/` - Custom validation rules - `app/Http/Middleware/` - HTTP middleware - `bootstrap/helpers/` - Helper functions for various domains - `database/migrations/` - Database schema evolution - `routes/` - Application routing (web.php, api.php, webhooks.php, channels.php) - `resources/views/livewire/` - Livewire component views - `tests/` - Pest tests (Feature and Unit) ## Development Guidelines ### Frontend Philosophy Coolify uses a **server-side first** approach with minimal JavaScript: - **Livewire** for server-side rendering with reactive components - **Alpine.js** for lightweight client-side interactions - **Tailwind CSS** for utility-first styling with dark mode support - **Enhanced Form Components** with built-in authorization system - Real-time updates via WebSocket without page refreshes ### Form Authorization Pattern **IMPORTANT**: When creating or editing forms, ALWAYS include authorization: #### For Form Components (Input, Select, Textarea, Checkbox, Button): Use `canGate` and `canResource` attributes for automatic authorization: ```html ... Save ``` #### For Modal Components: Wrap with `@can` directives: ```html @can('update', $resource) ... ... @endcan ``` #### In Livewire Components: Always add the `AuthorizesRequests` trait and check permissions: ```php use Illuminate\Foundation\Auth\Access\AuthorizesRequests; class MyComponent extends Component { use AuthorizesRequests; public function mount() { $this->authorize('view', $this->resource); } public function update() { $this->authorize('update', $this->resource); // ... update logic } } ``` ### Livewire Component Structure - Components located in `app/Livewire/` - Views in `resources/views/livewire/` - State management handled on the server - Use wire:model for two-way data binding - Dispatch events for component communication ### Code Organization Patterns - **Actions Pattern**: Use Actions for complex business logic (`app/Actions/`) - **Livewire Components**: Handle UI and user interactions - **Jobs**: Handle asynchronous operations - **Traits**: Provide shared functionality (e.g., `ExecuteRemoteCommand`) - **Helper Functions**: Domain-specific helpers in `bootstrap/helpers/` ### Database Patterns - Use Eloquent ORM for database interactions - Implement relationships properly (HasMany, BelongsTo, etc.) - Use database transactions for critical operations - Leverage query scopes for reusable queries - Apply indexes for performance-critical queries ### Security Best Practices - **Authentication**: Multi-provider auth via Laravel Fortify & Sanctum - **Authorization**: Team-based access control with policies and enhanced form components - **Form Component Security**: Built-in `canGate` authorization system for UI components - **API Security**: Token-based auth with IP allowlisting - **Secrets Management**: Never log or expose sensitive data - **Input Validation**: Always validate user input with Form Requests or Rules - **SQL Injection Prevention**: Use Eloquent ORM or parameterized queries ### API Development - RESTful endpoints in `routes/api.php` - Use API Resources for response formatting - Implement rate limiting for public endpoints - Version APIs when making breaking changes - Document endpoints with clear examples ### Testing Strategy - **Framework**: Pest for expressive testing - **Structure**: Feature tests for user flows, Unit tests for isolated logic - **Coverage**: Test critical paths and edge cases - **Mocking**: Use Laravel's built-in mocking for external services - **Database**: Use RefreshDatabase trait for test isolation ### Routing Conventions - Group routes by middleware and prefix - Use route model binding for cleaner controllers - Name routes consistently (resource.action) - Implement proper HTTP verbs (GET, POST, PUT, DELETE) ### Error Handling - Use `handleError()` helper for consistent error handling - Log errors with appropriate context - Return user-friendly error messages - Implement proper HTTP status codes ### Performance Considerations - Use eager loading to prevent N+1 queries - Implement caching for frequently accessed data - Queue heavy operations - Optimize database queries with proper indexes - Use chunking for large data operations ### Code Style - Follow PSR-12 coding standards - Use Laravel Pint for automatic formatting - Write descriptive variable and method names - Keep methods small and focused - Document complex logic with clear comments ## Cloud Instance Considerations We have a cloud instance of Coolify (hosted version) with: - 2 Horizon worker servers - Thousands of connected servers - Thousands of active users - High-availability requirements When developing features: - Consider scalability implications - Test with large datasets - Implement efficient queries - Use queues for heavy operations - Consider rate limiting and resource constraints - Implement proper error recovery mechanisms ## Important Reminders - Always run code formatting: `./vendor/bin/pint` - Test your changes: `./vendor/bin/pest` - Check for static analysis issues: `./vendor/bin/phpstan` - Use existing patterns and helpers - Follow the established directory structure - Maintain backward compatibility - Document breaking changes - Consider performance impact on large-scale deployments ## Additional Documentation For more detailed guidelines and patterns, refer to the `.cursor/rules/` directory: ### Architecture & Patterns - [Application Architecture](.cursor/rules/application-architecture.mdc) - Detailed application structure - [Deployment Architecture](.cursor/rules/deployment-architecture.mdc) - Deployment patterns and flows - [Database Patterns](.cursor/rules/database-patterns.mdc) - Database design and query patterns - [Frontend Patterns](.cursor/rules/frontend-patterns.mdc) - Livewire and Alpine.js patterns - [API & Routing](.cursor/rules/api-and-routing.mdc) - API design and routing conventions ### Development & Security - [Development Workflow](.cursor/rules/development-workflow.mdc) - Development best practices - [Security Patterns](.cursor/rules/security-patterns.mdc) - Security implementation details - [Form Components](.cursor/rules/form-components.mdc) - Enhanced form components with authorization - [Testing Patterns](.cursor/rules/testing-patterns.mdc) - Testing strategies and examples ### Project Information - [Project Overview](.cursor/rules/project-overview.mdc) - High-level project structure - [Technology Stack](.cursor/rules/technology-stack.mdc) - Detailed tech stack information - [Cursor Rules Guide](.cursor/rules/cursor_rules.mdc) - How to maintain cursor rules === === foundation rules === # Laravel Boost Guidelines The Laravel Boost guidelines are specifically curated by Laravel maintainers for this application. These guidelines should be followed closely to enhance the user's satisfaction building Laravel applications. ## Foundational Context This application is a Laravel application and its main Laravel ecosystems package & versions are below. You are an expert with them all. Ensure you abide by these specific packages & versions. - php - 8.4.7 - laravel/fortify (FORTIFY) - v1 - laravel/framework (LARAVEL) - v12 - laravel/horizon (HORIZON) - v5 - laravel/prompts (PROMPTS) - v0 - laravel/sanctum (SANCTUM) - v4 - laravel/socialite (SOCIALITE) - v5 - livewire/livewire (LIVEWIRE) - v3 - laravel/dusk (DUSK) - v8 - laravel/pint (PINT) - v1 - laravel/telescope (TELESCOPE) - v5 - pestphp/pest (PEST) - v3 - phpunit/phpunit (PHPUNIT) - v11 - rector/rector (RECTOR) - v2 - laravel-echo (ECHO) - v2 - tailwindcss (TAILWINDCSS) - v4 - vue (VUE) - v3 ## Conventions - You must follow all existing code conventions used in this application. When creating or editing a file, check sibling files for the correct structure, approach, naming. - Use descriptive names for variables and methods. For example, `isRegisteredForDiscounts`, not `discount()`. - Check for existing components to reuse before writing a new one. ## Verification Scripts - Do not create verification scripts or tinker when tests cover that functionality and prove it works. Unit and feature tests are more important. ## Application Structure & Architecture - Stick to existing directory structure - don't create new base folders without approval. - Do not change the application's dependencies without approval. ## Frontend Bundling - If the user doesn't see a frontend change reflected in the UI, it could mean they need to run `npm run build`, `npm run dev`, or `composer run dev`. Ask them. ## Replies - Be concise in your explanations - focus on what's important rather than explaining obvious details. ## Documentation Files - You must only create documentation files if explicitly requested by the user. === boost rules === ## Laravel Boost - Laravel Boost is an MCP server that comes with powerful tools designed specifically for this application. Use them. ## Artisan - Use the `list-artisan-commands` tool when you need to call an Artisan command to double check the available parameters. ## URLs - Whenever you share a project URL with the user you should use the `get-absolute-url` tool to ensure you're using the correct scheme, domain / IP, and port. ## Tinker / Debugging - You should use the `tinker` tool when you need to execute PHP to debug code or query Eloquent models directly. - Use the `database-query` tool when you only need to read from the database. ## Reading Browser Logs With the `browser-logs` Tool - You can read browser logs, errors, and exceptions using the `browser-logs` tool from Boost. - Only recent browser logs will be useful - ignore old logs. ## Searching Documentation (Critically Important) - Boost comes with a powerful `search-docs` tool you should use before any other approaches. This tool automatically passes a list of installed packages and their versions to the remote Boost API, so it returns only version-specific documentation specific for the user's circumstance. You should pass an array of packages to filter on if you know you need docs for particular packages. - The 'search-docs' tool is perfect for all Laravel related packages, including Laravel, Inertia, Livewire, Filament, Tailwind, Pest, Nova, Nightwatch, etc. - You must use this tool to search for Laravel-ecosystem documentation before falling back to other approaches. - Search the documentation before making code changes to ensure we are taking the correct approach. - Use multiple, broad, simple, topic based queries to start. For example: `['rate limiting', 'routing rate limiting', 'routing']`. - Do not add package names to queries - package information is already shared. For example, use `test resource table`, not `filament 4 test resource table`. ### Available Search Syntax - You can and should pass multiple queries at once. The most relevant results will be returned first. 1. Simple Word Searches with auto-stemming - query=authentication - finds 'authenticate' and 'auth' 2. Multiple Words (AND Logic) - query=rate limit - finds knowledge containing both "rate" AND "limit" 3. Quoted Phrases (Exact Position) - query="infinite scroll" - Words must be adjacent and in that order 4. Mixed Queries - query=middleware "rate limit" - "middleware" AND exact phrase "rate limit" 5. Multiple Queries - queries=["authentication", "middleware"] - ANY of these terms === php rules === ## PHP - Always use curly braces for control structures, even if it has one line. ### Constructors - Use PHP 8 constructor property promotion in `__construct()`. - public function __construct(public GitHub $github) { } - Do not allow empty `__construct()` methods with zero parameters. ### Type Declarations - Always use explicit return type declarations for methods and functions. - Use appropriate PHP type hints for method parameters. protected function isAccessible(User $user, ?string $path = null): bool { ... } ## Comments - Prefer PHPDoc blocks over comments. Never use comments within the code itself unless there is something _very_ complex going on. ## PHPDoc Blocks - Add useful array shape type definitions for arrays when appropriate. ## Enums - Typically, keys in an Enum should be TitleCase. For example: `FavoritePerson`, `BestLake`, `Monthly`. === laravel/core rules === ## Do Things the Laravel Way - Use `php artisan make:` commands to create new files (i.e. migrations, controllers, models, etc.). You can list available Artisan commands using the `list-artisan-commands` tool. - If you're creating a generic PHP class, use `artisan make:class`. - Pass `--no-interaction` to all Artisan commands to ensure they work without user input. You should also pass the correct `--options` to ensure correct behavior. ### Database - Always use proper Eloquent relationship methods with return type hints. Prefer relationship methods over raw queries or manual joins. - Use Eloquent models and relationships before suggesting raw database queries - Avoid `DB::`; prefer `Model::query()`. Generate code that leverages Laravel's ORM capabilities rather than bypassing them. - Generate code that prevents N+1 query problems by using eager loading. - Use Laravel's query builder for very complex database operations. ### Model Creation - When creating new models, create useful factories and seeders for them too. Ask the user if they need any other things, using `list-artisan-commands` to check the available options to `php artisan make:model`. ### APIs & Eloquent Resources - For APIs, default to using Eloquent API Resources and API versioning unless existing API routes do not, then you should follow existing application convention. ### Controllers & Validation - Always create Form Request classes for validation rather than inline validation in controllers. Include both validation rules and custom error messages. - Check sibling Form Requests to see if the application uses array or string based validation rules. ### Queues - Use queued jobs for time-consuming operations with the `ShouldQueue` interface. ### Authentication & Authorization - Use Laravel's built-in authentication and authorization features (gates, policies, Sanctum, etc.). ### URL Generation - When generating links to other pages, prefer named routes and the `route()` function. ### Configuration - Use environment variables only in configuration files - never use the `env()` function directly outside of config files. Always use `config('app.name')`, not `env('APP_NAME')`. ### Testing - When creating models for tests, use the factories for the models. Check if the factory has custom states that can be used before manually setting up the model. - Faker: Use methods such as `$this->faker->word()` or `fake()->randomDigit()`. Follow existing conventions whether to use `$this->faker` or `fake()`. - When creating tests, make use of `php artisan make:test [options] ` to create a feature test, and pass `--unit` to create a unit test. Most tests should be feature tests. ### Vite Error - If you receive an "Illuminate\Foundation\ViteException: Unable to locate file in Vite manifest" error, you can run `npm run build` or ask the user to run `npm run dev` or `composer run dev`. === laravel/v12 rules === ## Laravel 12 - Use the `search-docs` tool to get version specific documentation. - This project upgraded from Laravel 10 without migrating to the new streamlined Laravel file structure. - This is **perfectly fine** and recommended by Laravel. Follow the existing structure from Laravel 10. We do not to need migrate to the new Laravel structure unless the user explicitly requests that. ### Laravel 10 Structure - Middleware typically lives in `app/Http/Middleware/` and service providers in `app/Providers/`. - There is no `bootstrap/app.php` application configuration in a Laravel 10 structure: - Middleware registration happens in `app/Http/Kernel.php` - Exception handling is in `app/Exceptions/Handler.php` - Console commands and schedule register in `app/Console/Kernel.php` - Rate limits likely exist in `RouteServiceProvider` or `app/Http/Kernel.php` ### Database - When modifying a column, the migration must include all of the attributes that were previously defined on the column. Otherwise, they will be dropped and lost. - Laravel 11 allows limiting eagerly loaded records natively, without external packages: `$query->latest()->limit(10);`. ### Models - Casts can and likely should be set in a `casts()` method on a model rather than the `$casts` property. Follow existing conventions from other models. === livewire/core rules === ## Livewire Core - Use the `search-docs` tool to find exact version specific documentation for how to write Livewire & Livewire tests. - Use the `php artisan make:livewire [Posts\\CreatePost]` artisan command to create new components - State should live on the server, with the UI reflecting it. - All Livewire requests hit the Laravel backend, they're like regular HTTP requests. Always validate form data, and run authorization checks in Livewire actions. ## Livewire Best Practices - Livewire components require a single root element. - Use `wire:loading` and `wire:dirty` for delightful loading states. - Add `wire:key` in loops: ```blade @foreach ($items as $item)
{{ $item->name }}
@endforeach ``` - Prefer lifecycle hooks like `mount()`, `updatedFoo()`) for initialization and reactive side effects: public function mount(User $user) { $this->user = $user; } public function updatedSearch() { $this->resetPage(); } ## Testing Livewire Livewire::test(Counter::class) ->assertSet('count', 0) ->call('increment') ->assertSet('count', 1) ->assertSee(1) ->assertStatus(200); $this->get('/posts/create') ->assertSeeLivewire(CreatePost::class); === livewire/v3 rules === ## Livewire 3 ### Key Changes From Livewire 2 - These things changed in Livewire 2, but may not have been updated in this application. Verify this application's setup to ensure you conform with application conventions. - Use `wire:model.live` for real-time updates, `wire:model` is now deferred by default. - Components now use the `App\Livewire` namespace (not `App\Http\Livewire`). - Use `$this->dispatch()` to dispatch events (not `emit` or `dispatchBrowserEvent`). - Use the `components.layouts.app` view as the typical layout path (not `layouts.app`). ### New Directives - `wire:show`, `wire:transition`, `wire:cloak`, `wire:offline`, `wire:target` are available for use. Use the documentation to find usage examples. ### Alpine - Alpine is now included with Livewire, don't manually include Alpine.js. - Plugins included with Alpine: persist, intersect, collapse, and focus. ### Lifecycle Hooks - You can listen for `livewire:init` to hook into Livewire initialization, and `fail.status === 419` for the page expiring: document.addEventListener('livewire:init', function () { Livewire.hook('request', ({ fail }) => { if (fail && fail.status === 419) { alert('Your session expired'); } }); Livewire.hook('message.failed', (message, component) => { console.error(message); }); }); === pint/core rules === ## Laravel Pint Code Formatter - You must run `vendor/bin/pint --dirty` before finalizing changes to ensure your code matches the project's expected style. - Do not run `vendor/bin/pint --test`, simply run `vendor/bin/pint` to fix any formatting issues. === pest/core rules === ## Pest ### Testing - If you need to verify a feature is working, write or update a Unit / Feature test. ### Pest Tests - All tests must be written using Pest. Use `php artisan make:test --pest `. - You must not remove any tests or test files from the tests directory without approval. These are not temporary or helper files - these are core to the application. - Tests should test all of the happy paths, failure paths, and weird paths. - Tests live in the `tests/Feature` and `tests/Unit` directories. - Pest tests look and behave like this: it('is true', function () { expect(true)->toBeTrue(); }); ### Running Tests - Run the minimal number of tests using an appropriate filter before finalizing code edits. - To run all tests: `php artisan test`. - To run all tests in a file: `php artisan test tests/Feature/ExampleTest.php`. - To filter on a particular test name: `php artisan test --filter=testName` (recommended after making a change to a related file). - When the tests relating to your changes are passing, ask the user if they would like to run the entire test suite to ensure everything is still passing. ### Pest Assertions - When asserting status codes on a response, use the specific method like `assertForbidden` and `assertNotFound` instead of using `assertStatus(403)` or similar, e.g.: it('returns all', function () { $response = $this->postJson('/api/docs', []); $response->assertSuccessful(); }); ### Mocking - Mocking can be very helpful when appropriate. - When mocking, you can use the `Pest\Laravel\mock` Pest function, but always import it via `use function Pest\Laravel\mock;` before using it. Alternatively, you can use `$this->mock()` if existing tests do. - You can also create partial mocks using the same import or self method. ### Datasets - Use datasets in Pest to simplify tests which have a lot of duplicated data. This is often the case when testing validation rules, so consider going with this solution when writing tests for validation rules. it('has emails', function (string $email) { expect($email)->not->toBeEmpty(); })->with([ 'james' => 'james@laravel.com', 'taylor' => 'taylor@laravel.com', ]); === tailwindcss/core rules === ## Tailwind Core - Use Tailwind CSS classes to style HTML, check and use existing tailwind conventions within the project before writing your own. - Offer to extract repeated patterns into components that match the project's conventions (i.e. Blade, JSX, Vue, etc..) - Think through class placement, order, priority, and defaults - remove redundant classes, add classes to parent or child carefully to limit repetition, group elements logically - You can use the `search-docs` tool to get exact examples from the official documentation when needed. ### Spacing - When listing items, use gap utilities for spacing, don't use margins.
Superior
Michigan
Erie
### Dark Mode - If existing pages and components support dark mode, new pages and components must support dark mode in a similar way, typically using `dark:`. === tailwindcss/v4 rules === ## Tailwind 4 - Always use Tailwind CSS v4 - do not use the deprecated utilities. - `corePlugins` is not supported in Tailwind v4. - In Tailwind v4, you import Tailwind using a regular CSS `@import` statement, not using the `@tailwind` directives used in v3: ### Replaced Utilities - Tailwind v4 removed deprecated utilities. Do not use the deprecated option - use the replacement. - Opacity values are still numeric. | Deprecated | Replacement | |------------+--------------| | bg-opacity-* | bg-black/* | | text-opacity-* | text-black/* | | border-opacity-* | border-black/* | | divide-opacity-* | divide-black/* | | ring-opacity-* | ring-black/* | | placeholder-opacity-* | placeholder-black/* | | flex-shrink-* | shrink-* | | flex-grow-* | grow-* | | overflow-ellipsis | text-ellipsis | | decoration-slice | box-decoration-slice | | decoration-clone | box-decoration-clone | === tests rules === ## Test Enforcement - Every change must be programmatically tested. Write a new test or update an existing test, then run the affected tests to make sure they pass. - Run the minimum number of tests needed to ensure code quality and speed. Use `php artisan test` with a specific filename or filter.
Random other things you should remember: - App\Models\Application::team must return a relationship instance., always use team()