feat: add wildcard domain restriction feature

[TuroYT]

Summary

This PR implements the wildcard domain restriction feature, allowing administrators to define allowed domain patterns (e.g., *.example.com) that restrict which domains can be created for applications.

Closes: #2859, #3941, #2560, #1404
Supersedes: #3324, #3929

Changes

• Add domainRestrictionConfig field to webServerSettings schema (JSONB with enabled and allowedWildcards array)
• Add wildcard pattern matching utility (*.example.com for single-level, **.example.com for multi-level)
• Add API endpoints: getDomainRestrictionConfig and updateDomainRestriction
• Add DomainRestriction settings UI component in Server Settings
• Modify domain creation UI: when restriction is enabled, users select a subdomain + base domain from dropdown instead of free-form input
• Integrate domain validation in createDomain service

How it works

1. Admin enables Domain Restriction in Settings > Server
2. Admin adds wildcard patterns (e.g., *.example.com, *.app.company.io)
3. When creating a domain, users enter a subdomain and select the base domain from a dropdown
4. The full domain (e.g., my-app.example.com) is validated and registered

SSL/HTTPS Support

Yes, SSL works correctly. Each subdomain gets its own individual SSL certificate via Let's Encrypt HTTP-01 challenge. For example:

• app1.example.com → individual certificate
• app2.example.com → individual certificate

This is the standard approach and works perfectly. Wildcard SSL certificates (*.example.com) would require DNS-01 challenge configuration, which is a separate enhancement.

Test plan

• Enable Domain Restriction in Settings > Server
• Add wildcard patterns (e.g., *.test.com, *.prod.io)
• Create an application and add a domain
• Verify subdomain input + domain dropdown appears
• Verify domain is created correctly (e.g., myapp.test.com)
• Verify HTTPS/Let's Encrypt works for the created domain
• Disable restriction and verify free-form input returns

Greptile Summary

This PR adds a wildcard domain restriction feature that lets admins define allowed domain patterns (e.g. *.example.com) enforced at domain creation time, with a new settings UI, a domainRestrictionConfig JSONB column, and a wildcard-matching utility.

• Domain restriction bypass via update: validateDomainRestriction is only called in createDomain; updateDomainById has no equivalent check, so any user with domain-edit permission can change a domain's host to an arbitrary value after creation, circumventing the restriction entirely.

Confidence Score: 4/5

The core restriction can be bypassed via the domain update path; fix required before the feature is effective.

One P1 finding: updateDomainById does not call validateDomainRestriction, meaning the admin-defined restriction is trivially bypassed by editing an existing domain's host. The remaining findings are P2 (wildcard check ordering, schema validation, client-side UX). The migration and schema additions look correct.

packages/server/src/services/domain.ts — missing restriction check in updateDomainById.

Comments Outside Diff (1)

1. packages/server/src/services/domain.ts, line 127-141 (link)

   Domain restriction not enforced on update

   updateDomainById is called directly without running validateDomainRestriction, so any user with domain-edit permission can change a domain's host to an arbitrary value and completely bypass the admin-defined wildcard restriction. The enforcement in createDomain (line 20) has no effect once an edit is possible.

   Add the same validation guard here:

_{Reviews (1): Last reviewed commit: "feat: add wildcard domain restriction fe..." | Re-trigger Greptile}

Greptile also left 3 inline comments on this PR.

[TuroYT]

Hey @Siumauricio , could you take a look at this? This was a highly requested feature that could greatly improve Dokploy.