API tokens in Dokploy are currently instance-wide

What problem will this feature address?

Any external tool that integrates with Dokploy via API token must be granted
more privilege than it actually needs. For example, a secret sync tool that
only needs to update environment variables for a single application currently
receives read/write access to every service, every project, and every admin
operation on the instance.

This violates the principle of least privilege and makes it harder to safely
hand out tokens to third-party tools, CI pipelines, or self-hosted integrations
without accepting unnecessary risk.

Describe the solution you'd like

Allow API tokens to be scoped at creation time:

Optionally, scoped tokens could also be restricted by operation type
(read-only vs read-write) for finer-grained control.

Describe alternatives you've considered

None

Additional context

Why this matters

Without scoped tokens, integrating Dokploy with external tooling always carries
unnecessary blast radius. If a scoped token is leaked or misused, the damage is
contained to the resource it was issued for rather than the entire instance.

This came up while building Infibridge,
a self-hosted webhook bridge that syncs Infisical secrets to Dokploy. Users must
currently provide an instance-wide API token, which is documented as a known
limitation. Scoped tokens would eliminate that concern entirely.

Willingness to contribute

Happy to discuss the API design or contribute if the Dokploy team is open to it.

Will you send a PR to implement it?

Yes

No files, tests, or entry points are named. Start by locating the current API-token creation and authorization paths, then trace how instance-wide permissions are applied. Done means tokens can be scoped to an instance, project, or service, with the existing instance-wide behavior preserved; read-only versus read-write restrictions are described as optional.