Cron jobs never register on a fresh install: initCronJobs returns early because the owner does not exist yet

Version: v0.30.5, self-hosted, single node (no remote servers)

Summary

On a fresh install, initCronJobs() runs while the database has no owner member yet — the owner is only created a couple of minutes later, when the user completes onboarding in the browser. The function returns before scheduling anything, and nothing re-runs it afterwards. Docker cleanup, log cleanup and backup schedules stay unregistered until the process is restarted, with no error and no warning in the UI.

In my case the instance ran for a few days with enableDockerCleanup = true in the UI while no cleanup ever executed. Stale build images accumulated the whole time: dozens of untagged images from superseded builds, plus orphaned preview-* images from closed pull requests.

Root cause

packages/server/src/utils/backups/index.ts:

export const initCronJobs = async () => {
  console.log("Setting up cron jobs....");          // :18

  const admin = await db.query.member.findFirst({   // :20
    where: eq(member.role, "owner"),
    with: { user: true },
  });

  if (!admin) {                                     // :27
    return;                                         // :28  <- fresh install exits here
  }

  const webServerSettings = await getWebServerSettings();
  if (webServerSettings?.enableDockerCleanup) {
    scheduleJob("docker-cleanup", CLEANUP_CRON_JOB, ...);  // :35
  }
  // ... backups ...
  // "Starting log requests cleanup"                        // :102
};

initCronJobs() is called once, from apps/dokploy/server/server.ts:64, during startup.

Timeline from my instance

15:24:16   dokploy container starts
15:24:2x   "Setting up cron jobs...."      <- initCronJobs runs, no owner yet, returns at :28
15:26:26   owner member created (onboarding completed in the browser)
           process never restarted -> no cron registered

Evidence

The tell is that initCronJobs' last log line never appears. Before the restart, the startup log jumps straight from Setting up cron jobs.... to the next init function:

Server Started on: http://0.0.0.0:3000
Setting up cron jobs....
Initializing 0 schedules          <- initSchedules; log cleanup line missing
Setting up volume backups cron jobs....

Thousands of log lines across several days contained zero occurrences of cleanup and zero output at 23:4x-23:5x (CLEANUP_CRON_JOB = "50 23 * * *", packages/server/src/constants/index.ts:14).

After docker service update --force dokploy, with the owner now present:

Server Started on: http://0.0.0.0:3000
Setting up cron jobs....
Starting log requests cleanup 0 0 * * *    <- reached the end of initCronJobs
Initializing 0 schedules

Reproduce

1. Fresh install on a new host.
2. Complete onboarding in the browser (creates the first owner).
3. Grep the container logs: Setting up cron jobs.... is present, Starting log requests cleanup is not.
4. Leave it running. Docker cleanup never fires, even though the setting reads enabled.

Impact

• Docker cleanup, log cleanup and any backup schedules silently never run.
• The UI shows cleanup as enabled, so there is no way to notice short of reading logs.
• On a host building preview deployments this piles up quickly — each build leaves a multi-GB image behind.

Workaround

Restart Dokploy once after onboarding: docker service update --force dokploy.

Toggling the docker-cleanup switch is only a partial workaround — settings.ts:387 re-registers that one job, but not log cleanup or backups.

Suggested hotfix

Re-run initCronJobs() after onboarding creates the first owner, or drop the early return and register the settings-driven jobs (docker cleanup, log cleanup) independently of whether an owner exists — admin.user.id is only needed for the notification call, which could be resolved lazily inside the job callback.

Start with packages/server/src/utils/backups/index.ts and the startup call in apps/dokploy/server/server.ts:64; inspect the owner lookup, settings-driven jobs, and the onboarding path that creates the first member. Check settings.ts:387 and packages/server/src/constants/index.ts:14, then reproduce a fresh install and verify logs. Done means cleanup and backup schedules register after onboarding without a restart, while notification behavior remains valid.