[Bug]: Scheduled backups for coolify-db stopped working after upgrade to v4.1.2

[Motii1]

Error Message and Logs

No error messages are visible in the UI.

Scheduled backups work correctly for regular database resources, but scheduled backups for the built-in Coolify database (coolify-db) are never executed.

No backup files are created locally, and there is no indication in the UI or backup history that the scheduled job has run.

Steps to Reproduce

1. Upgrade Coolify to v4.1.2.
2. Use a self-hosted installation without any S3-compatible storage configured.
3. Configure backups for the built-in coolify-db database with the following settings:
   • Frequency: 0 1 * * *
   • Timezone: UTC
   • Timeout: 3600
   • Number of backups to keep: 1
   • Days to keep backups: 0
   • Maximum storage (GB): 10
4. Wait until the scheduled backup time passes.
5. Check the local backup storage location and backup history.

Expected result:

• A local backup file should be created according to the schedule.

Actual result:

• No backup file is created.
• No trace of the scheduled backup execution can be found.
• Scheduled backups for regular databases continue to work correctly.
• Only coolify-db scheduled backups are affected.

Example Repository URL

No response

Coolify Version

v4.1.2

Are you using Coolify Cloud?

No (self-hosted)

Operating System and Version (self-hosted)

Ubuntu 24.04

Additional Information

This setup worked correctly before upgrading to Coolify v4.1.2.

The issue appeared immediately after the upgrade.

Important details:

• No S3 integration is configured.
• Backups are intended to be stored locally only.
• Scheduled backups for other databases are working as expected.
• The problem only affects the built-in Coolify database (coolify-db).

[coderabbitai]

🔗 Related PRs

#10527 - fix(scheduled-jobs): link skipped service database backups [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[jankohlbach]

same issue here

[pimpeters]

Same happened here, directly after updating to v4.1.2. Manual backups still seem to work.

[aspantel]

We just noticed that too, last auto backup a month ago.
Is there a way to fix this?

Also, we still can't turn on S3 backups, the UI resets the checkbox!

[Motii1]

We just noticed that too, last auto backup a month ago. Is there a way to fix this?

Also, we still can't turn on S3 backups, the UI resets the checkbox!

@aspantel You could try experimenting with the CLI. In my setup I am able to trigger the backup with the following command used by a cronjob

docker exec coolify php artisan tinker --execute="(new \App\Jobs\DatabaseBackupJob(\App\Models\ScheduledDatabaseBackup::find(0)))->handle();"

[sebastianbiallas]

Hit this too on 4.1.2, and I think I have the root cause: the instance backup row has id = 0, and the dispatcher's keyset pagination starts at id > 0, so it is the one row that can never be selected.

app/Jobs/ScheduledJobManager.php (still present on main):

private function processScheduledBackupsAndTasks(): void
{
    $lastBackupId = 0;          // <-- cursor starts at zero
    ...
        $backups = $this->scheduledBackupQuery($lastBackupId)->get();

private function scheduledBackupQuery(int $lastBackupId): Builder
{
    return ScheduledDatabaseBackup::with(['database', 'team.subscription'])
        ->where('enabled', true)
        ->where('id', '>', $lastBackupId)   // => WHERE id > 0
        ->orderBy('id')
        ->limit(self::CHUNK_SIZE);
}

Coolify seeds its own instance records at id 0 — servers 0 (localhost), teams 0, instance_settings 0, standalone_postgresqls 0 (coolify-db) and the scheduled_database_backups row for coolify-db. Since 0 > 0 is false, the instance's own backup is silently skipped forever. User-created backups get ids ≥ 1 and are unaffected, which matches the reports here that only coolify-db is broken.

It fails with no diagnostics by construction: the row is never selected, so nothing is dispatched, so no scheduled_database_backup_executions row and no log line is ever written. Nothing appears in the UI, the schedule still shows as enabled, and schedule:work / horizon are perfectly healthy. On my instance it stopped dead the day of the 4.1.2 upgrade and went unnoticed for 49 days.

Reproducing it

On an affected instance, the enabled row exists but the dispatcher's own query returns nothing:

coolify=# select id, enabled, frequency from scheduled_database_backups where enabled = true;
 id | enabled | frequency
----+---------+-----------
  0 | t       | 0 0 * * *

coolify=# select id from scheduled_database_backups where enabled = true and id > 0;
(0 rows)

Suggested fix

Start the cursor below zero so the first page includes id 0:

$lastBackupId = -1;
$lastTaskId = -1;

scheduledTaskQuery() has the same id > $lastTaskId shape, so any seeded task row at id 0 would be affected identically — worth changing both.

Workaround for anyone stuck

Renumbering the row out of the blind spot fixes it without touching code, which matters because a code patch gets replaced by the next auto-update:

BEGIN;
UPDATE scheduled_database_backups SET id = 1 WHERE id = 0;
UPDATE scheduled_database_backup_executions SET scheduled_database_backup_id = 1
  WHERE scheduled_database_backup_id = 0;
SELECT setval('scheduled_database_backups_id_seq',
              (SELECT max(id) FROM scheduled_database_backups));
COMMIT;

Checked before doing this: nothing has a foreign key to scheduled_database_backups, and nothing resolves the backup by id = 0 (the UI addresses it by uuid, which is unchanged). The setval stops a later insert colliding with the renumbered row. Adjust the target id if you already have a backup at id 1.

After that the backup dispatched on the next due tick and completed successfully — first one in 49 days.

[eudson]

I may be seeing a related variant of this issue with scheduled backups of the built-in coolify-db.

Environment:

• Self-hosted Coolify
• Ubuntu 24.04
• Coolify build: v4.5.0-29319337385
• Cloudflare R2 configured as S3-compatible storage
• Schedule: 0 2 * * *
• MinIO Client: RELEASE.2025-05-21T01-59-54Z

The only scheduled/off-server backup I had was from July 23. A later scheduled backup failed during the S3
upload with this error (hostname and address redacted):

  Warning: S3 upload failed: mc: <ERROR> invalid DNS resolve entry <r2-host>:443=[<IPv6-address>]:
  ParseAddr("[<IPv6-address>]"): each colon-separated field must have at least one digit

DNS resolution itself appears healthy: the R2 endpoint resolves to both IPv4 and IPv6 from the host and
from inside the Coolify container.

I inspected the installed code and found that SafeWebhookUrl::minioClientResolveOptions() surrounds
resolved IPv6 addresses with square brackets when constructing the MinIO Client --resolve argument. The
installed mc version rejects that bracketed address.

A manually triggered backup currently completes successfully, so I will use manual backups until this is
resolved. The scheduled backup remains unreliable.

I realize the original report does not use S3 and shows no scheduled execution at all, so this may be a
different failure after scheduling begins. I’m adding it here because it also affects scheduled backups of
the built-in coolify-db. Please let me know if you would prefer this tracked separately.

Additional clarification: manually triggering the backup successfully creates the local PostgreSQL dump, but the S3/R2 upload still fails with the IPv6 mc --resolve parsing error. Therefore, only the Local Storage version succeeds; no new off-server backup is created by Coolify.

The previously successful R2 upload occurred before this installation unintentionally moved from Coolify 4.1.2 to build v4.5.0-29319337385 during a container recreation using the latest image. This may therefore be a regression in the newer backup/S3 resolution path rather than the scheduler alone.

[nKweo]

Same symptom, with some diagnostics that may narrow it

Environment: Coolify v4.1.2 (self-hosted, one instance managing itself plus one remote server), Ubuntu 24.04, Docker 29.6.1, S3 destination is Cloudflare R2.

Symptom: The built-in instance-database backup has never fired on its schedule. Two application-database backups on the same cron expression and the same S3 storage run reliably every night.

From scheduled_database_backup_executions — backup 0 is the instance DB, 1 and 2 are application databases:

id	scheduled_database_backup_id	status	created_at
135	2	success	2026-07-27 01:45:05
134	1	success	2026-07-27 01:45:02
133	0	success	2026-07-26 06:50:01
132	2	success	2026-07-26 01:45:02
131	1	success	2026-07-26 01:45:01

Every execution of backup 0 in the table corresponds to a manual trigger. There are no scheduled ones.

Ruled out:

• S3 destination — all three backups share s3_storage_id, and two of them succeed nightly. Manual triggers of backup 0 upload to R2 successfully.
• enabled — already true; disabling and re-enabling changed only updated_at.
• Cron expression — I temporarily set the frequency to */5 * * * * and left it for several windows. Nothing was dispatched, and no execution row was created.

Possibly relevant: the instance-DB row differs structurally from the working ones.

column	backup 0 (instance)	backup 1 (works)
database_type	App\Models\StandalonePostgresql	App\Models\StandalonePostgresql
database_id	0	1
databases_to_backup	(empty)	n8n
dump_all	false	false
enabled / save_s3	true / true	true / true

database_id = 0 doesn't reference an existing StandalonePostgresql record, since the instance database isn't a managed resource. Manual execution clearly handles this case, so the job itself special-cases it — but whatever the scheduler uses to resolve the target appears to come up empty and skip the row without logging anything. That would explain manual-works/scheduled-never, though I haven't read the scheduler code to confirm.

[palomnik]

I also have this issue - automated daily backups were running until a month ago. Manual backups to local and AWS S3 Still work.

[lempa]

Hit this too on 4.1.2, and I think I have the root cause: the instance backup row has id = 0, and the dispatcher's keyset pagination starts at id > 0, so it is the one row that can never be selected.

app/Jobs/ScheduledJobManager.php (still present on main):

private function processScheduledBackupsAndTasks(): void
{
$lastBackupId = 0; // <-- cursor starts at zero
...
$backups = $this->scheduledBackupQuery($lastBackupId)->get();
private function scheduledBackupQuery(int $lastBackupId): Builder
{
return ScheduledDatabaseBackup::with(['database', 'team.subscription'])
->where('enabled', true)
->where('id', '>', $lastBackupId) // => WHERE id > 0
->orderBy('id')
->limit(self::CHUNK_SIZE);
}
Coolify seeds its own instance records at id 0 — servers 0 (localhost), teams 0, instance_settings 0, standalone_postgresqls 0 (coolify-db) and the scheduled_database_backups row for coolify-db. Since 0 > 0 is false, the instance's own backup is silently skipped forever. User-created backups get ids ≥ 1 and are unaffected, which matches the reports here that only coolify-db is broken.

It fails with no diagnostics by construction: the row is never selected, so nothing is dispatched, so no scheduled_database_backup_executions row and no log line is ever written. Nothing appears in the UI, the schedule still shows as enabled, and schedule:work / horizon are perfectly healthy. On my instance it stopped dead the day of the 4.1.2 upgrade and went unnoticed for 49 days.

Reproducing it

On an affected instance, the enabled row exists but the dispatcher's own query returns nothing:

coolify=# select id, enabled, frequency from scheduled_database_backups where enabled = true;
 id | enabled | frequency
----+---------+-----------
  0 | t       | 0 0 * * *

coolify=# select id from scheduled_database_backups where enabled = true and id > 0;
(0 rows)

Suggested fix

Start the cursor below zero so the first page includes id 0:

$lastBackupId = -1;
$lastTaskId = -1;
scheduledTaskQuery() has the same id > $lastTaskId shape, so any seeded task row at id 0 would be affected identically — worth changing both.

Workaround for anyone stuck

Renumbering the row out of the blind spot fixes it without touching code, which matters because a code patch gets replaced by the next auto-update:

BEGIN;
UPDATE scheduled_database_backups SET id = 1 WHERE id = 0;
UPDATE scheduled_database_backup_executions SET scheduled_database_backup_id = 1
WHERE scheduled_database_backup_id = 0;
SELECT setval('scheduled_database_backups_id_seq',
(SELECT max(id) FROM scheduled_database_backups));
COMMIT;
Checked before doing this: nothing has a foreign key to scheduled_database_backups, and nothing resolves the backup by id = 0 (the UI addresses it by uuid, which is unchanged). The setval stops a later insert colliding with the renumbered row. Adjust the target id if you already have a backup at id 1.

After that the backup dispatched on the next due tick and completed successfully — first one in 49 days.

Confirming this on 4.1.2 — @sebastianbiallas root-cause analysis matches ours exactly. Our coolify-db backup went silent for ~5 weeks: no dump files, no rows in scheduled_database_backup_executions, and no failed notification, while all our service-database backups (id ≥ 1) kept running. The seeded coolify-db instance backup had id = 0 and was never dispatched because of the WHERE id > 0 cursor.

The id-renumbering workaround fixed it for us and the automatic nightly backup resumed immediately; the Settings → Backup UI kept working (it loads the backup by name/relation, not by id). +1 for the $lastBackupId = -1 fix.