Add autogenerate_domain API parameter for applications

[andrasbacsai]

Summary

Adds a new autogenerate_domain API parameter that allows consumers to control domain auto-generation behavior. When enabled (default) and no custom domains are provided, the system auto-generates a domain using the server's wildcard domain or sslip.io fallback.

Changes

• Added autogenerate_domain boolean parameter to all 5 application creation endpoints (public, private GitHub app, deploy key, Dockerfile, Docker image)
• Implemented validation and allowlist rules for the parameter
• Added domain auto-generation logic across all application types
• Included comprehensive unit tests covering all scenarios

Notes

This is a minor API enhancement with sensible defaults. The parameter defaults to true, which may change behavior for existing API consumers who were not providing custom domains.

🤖 Generated with Claude Code

[andrasbacsai]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Walkthrough

This pull request introduces auto-domain generation functionality across multiple application creation endpoints. The changes add an autogenerate_domain boolean field to request schemas with corresponding validation rules. When enabled and no custom domains are provided, the system generates a unique domain using server references and application UUIDs. The feature is applied consistently across public, private GitHub app, private deploy-key, dockerfile, dockerimage, and dockercompose creation paths. Helper functions and unit tests support the feature implementation.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch api-autogenerate-domain

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8ba7533 and eb743cf.

📒 Files selected for processing (3)

• app/Http/Controllers/Api/ApplicationsController.php (13 hunks)
• bootstrap/helpers/api.php (1 hunks)
• tests/Unit/Api/ApplicationAutogenerateDomainTest.php (1 hunks)

🧰 Additional context used

📓 Path-based instructions (4)

**/*.php

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.php: Use PHP 8.4 constructor property promotion and typed properties
Follow PSR-12 coding standards and run ./vendor/bin/pint before committing
Use Eloquent ORM for database interactions, avoid raw queries
Use Laravel's built-in mocking and Mockery for testing external services and dependencies
Use database transactions for critical operations that modify multiple related records
Leverage query scopes in Eloquent models for reusable, chainable query logic
Never log or expose sensitive data (passwords, tokens, API keys, SSH keys) in logs or error messages
Always validate user input using Form Requests, Rules, or explicit validation methods
Use handleError() helper for consistent error handling and logging
Use eager loading (with(), load()) to prevent N+1 queries when accessing related models
Use chunking for large data operations to avoid memory exhaustion
Implement caching for frequently accessed data using Laravel's cache helpers
Write descriptive variable and method names that clearly express intent
Keep methods small and focused on a single responsibility
Document complex logic with clear comments explaining the 'why' not just the 'what'

Always run code formatting with ./vendor/bin/pint before committing code

Files:

• bootstrap/helpers/api.php
• tests/Unit/Api/ApplicationAutogenerateDomainTest.php
• app/Http/Controllers/Api/ApplicationsController.php

bootstrap/helpers/**/*.php

📄 CodeRabbit inference engine (CLAUDE.md)

Place domain-specific helper functions in bootstrap/helpers/ directory organized by domain

Files:

• bootstrap/helpers/api.php

tests/Unit/**/*.php

📄 CodeRabbit inference engine (CLAUDE.md)

Unit tests MUST NOT use database. Use mocking for dependencies. Run with ./vendor/bin/pest tests/Unit

Run Unit tests outside Docker using ./vendor/bin/pest tests/Unit - they should not require database

Files:

• tests/Unit/Api/ApplicationAutogenerateDomainTest.php

tests/**/*.php

📄 CodeRabbit inference engine (CLAUDE.md)

tests/**/*.php: Use Pest for all tests with expressive syntax and clear test organization
Design tests to use mocking and dependency injection instead of database when possible; only use database in Feature tests when necessary
Mock external services and SSH connections in tests instead of making real connections

Files:

• tests/Unit/Api/ApplicationAutogenerateDomainTest.php

🧠 Learnings (2)

📚 Learning: 2025-11-25T09:32:36.504Z

Learnt from: CR
Repo: coollabsio/coolify PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T09:32:36.504Z
Learning: Applies to tests/**/*.php : Design tests to use mocking and dependency injection instead of database when possible; only use database in Feature tests when necessary

Applied to files:

• tests/Unit/Api/ApplicationAutogenerateDomainTest.php

📚 Learning: 2025-11-25T09:32:36.504Z

Learnt from: CR
Repo: coollabsio/coolify PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T09:32:36.504Z
Learning: Applies to **/*.php : Use Laravel's built-in mocking and Mockery for testing external services and dependencies

Applied to files:

• tests/Unit/Api/ApplicationAutogenerateDomainTest.php

🧬 Code graph analysis (1)

app/Http/Controllers/Api/ApplicationsController.php (1)

bootstrap/helpers/shared.php (1)

• generateUrl (445-460)

🔇 Additional comments (7)

bootstrap/helpers/api.php (1)

181-181: LGTM! This field will be terminated from the request, as it should be.

The autogenerate_domain is a control parameter that triggers domain generation logic but shouldn't be persisted to the model. Good placement alongside other control fields like instant_deploy and force_domain_override. I'll be back... to approve more code like this.

tests/Unit/Api/ApplicationAutogenerateDomainTest.php (1)

52-117: Boolean condition tests are solid. Like a T-800 endoskeleton.

These tests properly verify the autogenerate_domain flag behavior and the condition logic ($autogenerateDomain && blank($fqdn)). Simple, focused, and don't require a database - exactly what unit tests should be. Self-hosting these tests on a real server... chef's kiss. 🌮

app/Http/Controllers/Api/ApplicationsController.php (5)

195-195: OpenAPI documentation is properly defined.

The parameter description clearly explains the behavior: auto-generates domain when true and domains is empty, using wildcard domain or sslip.io fallback. Default true is documented. This documentation is like a good server - reliable and self-hosted. No VC-funded serverless nonsense here. 🌮

---

948-948: Validation rule is correctly defined.

Boolean validation will ensure the parameter is properly typed. Come with me if you want to validate.

---

973-973: Default value true is correctly applied.

Using $request->boolean('autogenerate_domain', true) properly defaults to true when the parameter is not provided, which matches the OpenAPI documentation. This may change behavior for existing API consumers who previously got no auto-generated domain - but they'll get a free domain now! Like getting free tacos. 🌮

---

1619-1620: Correct: dockercompose type excluded from autogenerate_domain feature.

The dockercompose type creates a Service model, not an Application, so it correctly doesn't include autogenerate_domain in its allowedFields. The OpenAPI schema at lines 828-860 also correctly omits this parameter. Like trying to put gluten in a taco shell - some things just don't belong together. 🌮

---

935-936: autogenerate_domain properly added to allowedFields array.

The field is correctly included in the allowed fields list, ensuring it passes validation and isn't rejected as an "extra field." This is how a Terminator handles field validation - with precision and without mercy to unauthorized fields.