Check enabled volume backup schedules hourly and notify teams when no
execution occurs within the configured number of days. Expose the alert
threshold in the UI and API, with alerts disabled by default.
Route volume backup results and warnings to the appropriate Telegram
backup threads.
Default to sequential dispatch on self-hosted instances and concurrent
per-type dispatch on Coolify Cloud. Allow SCHEDULED_JOBS_DISPATCH_MODE
to override the default, falling back for invalid values.
Cover defaults, overrides, and fallback behavior in scheduler tests.
Count running scheduled tasks, database backups, and volume backups,
excluding runs older than their job timeout. Report scheduled job counts
and keep the progress check active while any scheduled jobs are running.
Keep reserved jobs active and bound missing Horizon records by the server's
deployment timeout. Add regression coverage for active and finished jobs.
Use UTC PostgreSQL sessions and bump the release version to 4.4.1.
- Update tests whose expectations no longer matched intended changes
(GitHub App redirect, wildcard domains, container IDs, nightly
install folders, localhost metadata, Sentinel restart on save)
- Seed the instance settings the 2FA profile test needs
- Run the global Pest hooks for all test folders and release the
Laravel application after each test, so tests do not leak state
- Replace a class alias mock that broke later tests
- Generate factory names that always pass name validation; Faker names
with apostrophes or short words made form tests fail at random
Add an inactive soketi placeholder to production and nightly Compose
files so old custom overrides remain valid without starting soketi.
Cover partial and full legacy overrides with regression tests.
Since aabd12737 a Compose bind volume with a content block had to stay
inside the resource directory. Services and Compose applications saved
in v4.3.23 with other paths, and Git Compose files with them, no longer
started or deployed.
Only admins and owners can edit Compose files, and they can already
write any host file with a plain bind mount, so the rule added no
security.
- Write content files to their host path again, as in v4.3.23
- Keep shell escaping and the safe-character checks on volume sources,
so injection attempts are still rejected
Every released Sentinel with traffic analytics (1.0.0 and later) has
the dashboard and series routes and the requests, bytes_in and app
fields, so the fallbacks for builds without them are not needed.
- Keep "no data" handling for Sentinel without traffic routes (0.0.x)
- Keep the resource-scope fallback, which Sentinel 1.0.1 needs
The per-server schedules reused the cache keys of the old schedule, so
every server ran these checks at once on the first run after the
upgrade. New keys start fresh, so each server runs at its own slot.
A staged upload always won over a server path, so an old upload that
was never imported could be restored instead of the chosen file.
- Record the selected source (checked server file or finished upload)
and import only from it
- Delete a stale staged upload when another source is used
- A dispatch failure for one additional server no longer skips the
other servers or the combined notification
- After a deployment fails to dispatch, the queue starts the next
queued deployment; nested queue advances run in a loop, not as
recursion, so repeated failures end
The policies checked the admin role in the session team. A user who was
demoted in the owning team could still edit its cloud tokens and
cloud-init scripts after switching to a team they administer. View,
update and delete now need admin of the resource's team, as for
integration tokens.
Integration token, cloud provider token and cloud-init script edits
were audit-logged under the session team. After a team switch in
another tab, the owning team missed the entry and the other team saw
the resource name.
- Use the team of the edited resource for every audit row
- Remove credentials, query and fragment from secret manager base URLs
in the audit log
Connection URLs of KeyDB, Dragonfly and Redis queried their password
variables once per database, so the database list API ran extra queries
for every database.
- Read REDIS_PASSWORD and REDIS_USERNAME from the loaded relation
- Load the variables once per type in the database list and the
environment details API
- /security/cloud-tokens returns 403 for members instead of crashing
on a null token list
- /settings/oauth redirects non-admins to the dashboard; it used the
missing route "home" and a wrong redirect return type
Login no longer accepts invitations, so the dashboard lists the
unexpired invitations for the user's email with a link to the
invitation page, where the user accepts them.
A password login added the user to the first team that invited their
email and switched to it, without asking. The user now accepts the
invitation on the invitation page. The invitation link login flow
works again, because login no longer consumes the invitation.
The domain rows of applications and previews, and the DNS validation
flags of application and service domains, were not locked. A user
could change them from the browser to skip the DNS check or store
fake DNS results.
An admin of the root team could delete the root user (id 0) and the
owners of the root team from the user list.
- Never delete the root user here
- Refuse a user whose root-team role is higher than the caller's
- Refuse the caller's own account; the profile has its own flow
Require usage to fall five percentage points below the threshold before releasing the notification throttle. Reset it after Sentinel reports recovery so a new spike alerts immediately.
Add regression coverage for recovery and usage fluctuating near the threshold.
Queued deployments of a deleted server could never start and stayed in
the queue. Deleting a server now marks them failed with the log entry
"The server was deleted."
- A queued deployment on a deleted server no longer stops the queue;
one deployment that fails to start does not stop the others
- Cancelling a deployment starts the queued deployments of the same
application on all servers, as a finished deployment does
Since 17ca63ff4 every deployment except Docker image apps failed on a
build-time variable with a name such as MY-VAR, also restarts and
deployments that reuse an existing image. v4.3.23 failed only when it
built an image.
- Check build-time names right before the build steps; the start of
the deployment only logs a warning
- Names that break the .env file still fail every deployment
- Leave invalid names out of the build secrets helper container, so
restarts with build secrets work
v4.3.23 started Redis with the stored REDIS_PASSWORD value as it is and
unquoted, and the connection URLs used the same value. 4.4.0 resolved a
shared variable reference for the start command only, so after the first
restart the server password changed and no longer matched the URLs.
- Add legacy_password_quoting to standalone_redis; existing databases
keep the v4.3.23 server password
- New databases resolve REDIS_PASSWORD (local, shared or remote secret)
and quote it in the start command
- Connection URLs use the same password as the server
- Hide the flag in the API, as for KeyDB and Dragonfly
Since 50268139b the API returned 422 for custom_internal_name without
is_consistent_container_name_enabled. v4.3.23 accepted it, so clients
such as `coolify app update --custom-internal-name` broke.
- A custom_internal_name sent without the flag turns the flag on, the
same rule as the migration for existing applications
- Keep the 422 only when the request sends the flag as false
The sudo parser read everything after `mkdir -p` as the path, so the
ownership step ended up after the last command of the line. For
`mkdir -p /data/coolify/proxy/dynamic && ls ... | head -n 1000`, `head`
got the `find` options and the proxy dynamic configurations failed on
every server with a non-root user.
- Add the ownership step right after the mkdir path; commands after
`&&` or `;` stay unchanged
- Lines with other forms (redirects, `||`, pipes) get no ownership step
The stored password is the default. Before, a local REDIS_PASSWORD was
rewritten to the stored password, and a shared one replaced the stored
password, so the old password was lost.
- A local, shared, or remote secret REDIS_PASSWORD sets the server
password; the stored password and the variable are not changed
- Removing the variable, or an empty value, uses the stored password
- Connection URLs show the password in use; for a remote secret they
show the reference, not the secret
- Databases created before this release keep the v4.3.23 behavior
Previews of Docker Compose applications used external volumes as
written, so a preview mounted the production volume. Two database
containers on the same data can corrupt it.
- A preview uses {uuid}_<name>-pr-N with a name-only declaration, the
same name as v4.3.23, so old preview volumes are used again
- Production still uses the external volume as written
- Preview cleanup removes the preview volume, never the external one
- Do not show the external volume warning for previews
The high disk usage throttle stayed for 24 hours after usage dropped,
so a new spike in that time sent no alert.
- Release the throttle when disk usage is at or below the threshold
A pull request id above 2147483647 caused a database error and a 500.
- Previews store: validate max 2147483647 (422)
- /deploy: return 400 for pr or pull_request_id out of range
- Preview show, logs, update, and delete: return 422 for ids out of range
- Document the maximum in the OpenAPI spec
Container names use custom_internal_name only when consistent container
naming is on. The API accepted the name and then ignored it.
- Return 422 with a message that says to set
is_consistent_container_name_enabled to true
- Accept the name when the request or the application turns the setting on
- Document the requirement in the OpenAPI spec
Andras Bacsai