Schedule and Service Permission Model#

Dokploy's schedule permission model applies a two-track authorization pattern based on the schedule's type. Schedules attached to an application or compose service go through a service-scoped check; standalone server-level and host-level schedules go through an org-role-gated check. All schedule permissions (read, create, update, delete) are classified as enterprise-only resources in the access-control layer — for static roles (owner, admin, member) the resource-level check is bypassed, and fine-grained enforcement via custom roles requires an enterprise license. 1

Schedule Types#

The scheduleType field determines which authorization branch is taken 2:

checkServicePermissionAndAccess#

Defined in permission.ts, this is the central guard for all service-linked operations:

1. Looks up the caller's member record in the active organization via findMemberByUserId.
2. Runs the generic checkPermission which resolves the member's role (static: owner/admin/member, or custom enterprise role) and authorizes against the requested actions.
3. For non-owner/non-admin members, also verifies the serviceId is in memberRecord.accessedServices. If not, throws UNAUTHORIZED.

This means a regular member can pass the RBAC check but still be blocked if they haven't been explicitly granted access to the specific service.

Host / Server Schedule Checks#

For schedules without a service (scheduleType === "server" or "dokploy-server"), every mutating endpoint (create, update, delete, runManually) runs three sequential checks 3:

1. checkPermission(ctx, { schedule: ["create"|"update"|"delete"] }) — base RBAC check.
2. Role guard: findMemberByUserId is called again; if the member's role is not owner or admin, a FORBIDDEN error is thrown: "Only owners and admins can manage server-level schedules."
3. Org ownership check (server type only): loads the target server via findServerById and compares targetServer.organizationId to ctx.session.activeOrganizationId; throws UNAUTHORIZED if mismatched. 4

dokploy-server schedules are additionally blocked entirely in the Cloud tier and are keyed to organizationId rather than serverId. 5

deployment.allByType Resolution Fix#

A prior bug (fixed in PR #4733) passed a raw scheduleId into checkServicePermissionAndAccess, which expects a service id, causing 401s for valid members. The fix in deployment.ts now resolves the schedule first:

• If input.type === "schedule": fetch schedule → derive serviceId from schedule.applicationId || schedule.composeId → call service check, or fall back to org ownership check for serverId-based schedules.
• All other types: pass input.id directly as a service id (previous behavior).

This pattern of resolving the schedule to its service before the permission check should be applied consistently whenever a schedule id is used to gate access to service-scoped resources.

Role Definitions#

The three static roles are defined in access-control.ts:

• ownerRole — full access to all schedule actions. 6
• adminRole — identical to owner for schedules; differs only in org-deletion. 7
• memberRole — full schedule CRUD actions, but only within services in accessedServices; cannot touch server or dokploy-server schedules (those require owner/admin). 8

For custom roles, schedule is an enterprise-only resource, so the resolveRole function checks for a valid license before loading the custom role. 9

Key Source Files#

Related PRs:

• PR #4279 — Added authz checks for server and host-level schedules.
• PR #4733 — Fixed allByType resolving scheduleId → serviceId before permission check.