A locked variable used by Docker Compose could not be changed, unlocked,
or deleted, so a lock by mistake had no fix in the UI. A locked value can
now be replaced without showing it. The lock is permanent in the UI, the
API, and MCP, and Lock asks for confirmation.
Closes#6803
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Require write access on the target environment to clone or move a resource
- Check read access on shared variables before a reference is added or resolved
- Limit team credentials, git sources, and imports of other backups to team-wide writers
- Require the delete level for backup, volume, storage, and task deletes
- Require create access for previews, new projects, and git sources
- Use the token team for the access scope, and check team-wide access on Livewire updates
- Require instance admin to toggle the API and MCP server
- Hide server pickers and broadcast details from members without access
Cloning a clone added another "-clone-<id>" to the name, so after about
seven clones the name was longer than 255 characters and the insert failed.
Closes#9976
The log endpoints found containers with `docker ps -a`, then rejected
every container that was not running. Remove that check, so failed
deployments can be diagnosed through the API. Without service_name,
the application endpoint prefers a running container. The old error
stays when no container exists.
Closes#9972
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Add a Database schema and use it for GET /databases and
GET /databases/{uuid}, type the GET /resources items, and stop
requiring both environment_name and environment_uuid on create
endpoints. KeyDB now returns database_type like the other engines.
Closes#10449
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The UI service clone iterated relation builders before parse() created
the sub-resources, so no volume copy ever ran. All service clone paths
now use clone_service(), which parses first and matches volumes by
mount path. VolumeCloneJob no longer forces chown 1000:1000.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A normal delete now removes a resource from Coolify also when its server
is not reachable, so the separate option only left untracked containers
running. The danger zone button is gone, and the services API rejects
delete_from_coolify_only with 422 instead of ignoring it, so old clients
do not delete Docker resources they asked to keep.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Applications: is_container_label_readonly_enabled (turning it back on
regenerates labels), include_coolify_default_variables, and
dockerfile_target_build on create.
- Databases: save is_log_drain_enabled on update instead of dropping it,
include_coolify_default_variables, and disable_local_backup on backups
(only with save_s3).
- Services: include_coolify_default_variables, and redirect on service
applications (www/non-www needs both hosts).
- Servers: wildcard_domain, server_timezone,
backup_compression_cpu_percentage, and the proxy error page.
Closes#11092
Resolve conflicts between main's security fixes and v4.5 features:
- Keep v4.5 features (log redaction, multi-S3 backups, transfer flow,
scheduled task modal, sidebar) and port main's fixes into them.
- Reuse RequiresDeployAbility for the Hostinger create endpoint.
- Align MCP tool abilities and descriptions with main's new deploy
requirements, and use deploy tokens in the affected MCP tests.
- Drop the duplicate DockerCleanupJobTest helper and tests, and the
exportBundle test for a method v4.5 removed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Require deploy permission for API changes that trigger server side effects, including resource deletion, storage access, provider operations, and database imports. Also escape Docker cleanup filters and sanitize log drain server names.
Call updateCompose() after saving an application's fqdn in the services
API urls handler so the domain is written back to the compose file.
Without this, StartService re-parsing the compose before deploy would
drop the domain and its SERVICE_URL_*/SERVICE_FQDN_* variables.
Add a feature test covering persistence after a second parse.
Sentry self-hosted (getsentry/self-hosted 26.8.0) could not be deployed
as a Docker Compose application. Three separate problems blocked it:
- YAML collection aliases: the first fix raised the limit to 256 only in
Application::oldRawParser(). The safety check added in v4.4.0
(validateDockerComposeForInjection) and all other Compose parse calls
still used the Symfony default of 128, so the Sentry file (133 aliases)
failed with "Maximum number of collection aliases (128) exceeded".
Add parseDockerComposeYaml() and use it for every Compose parse.
- Argument list too long: the deployment job sent the generated Compose
file as base64 inside the SSH command. Linux limits one argument to
128 KiB, and the Sentry file is about 370 KB. execute_remote_command()
now accepts an 'input' key that streams content over SSH stdin, and
the job writes the Compose file with it.
- A list-style build arg without a value (build.args: [SENTRY_IMAGE])
merged into a map environment kept its numeric key, so Docker Compose
rejected the file with "non-string key in ...environment: 0". It now
becomes NAME with no value, as in Compose.
Closes#11725
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
Require deploy or root token access when creating managed mounts outside
resource directories or changing their file contents through the API.
Synchronize KeyDB and Dragonfly passwords with local and shared
REDIS_PASSWORD values while preserving secret manager resolution.
Allow validated host file and directory mounts outside resource directories
while protecting external paths from deletion.
Clean up cancelled deployment containers and clear tracked process IDs.
Preserve legacy KeyDB and Dragonfly password parsing, accept server backup
paths without extension restrictions, and allow Compose variable proxy ports.
A stop or delete no longer queues a full cleanup each time. It skips the
cleanup when one finished on the server in the last hour, and the queued
run only cleans when disk usage is at or above the server cleanup
threshold. The docker_cleanup API flag keeps its default of true.
- References to locked (shown once) shared variables keep their reference
text in the UI, copy action, and API instead of the locked value.
- Remove the saved proxy configuration and validation logs from nested
servers (for example destination.server) in API responses unless the
token can read sensitive data.
- The services list API now applies removeSensitiveData to every service.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A renamed template keeps its old key as an alias, so API callers and
services stored with the old key still find the template.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Try to remove every volume and always delete the configuration
directory (it holds the .env with secrets), then report the volumes that
failed.
- Delete volume backup schedules also when a service is removed from
Coolify only.
- The delete API no longer claims the server is unreachable when the
caller asked to delete from Coolify only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Container ownership labels now use UUIDs: coolify.applicationUuid,
coolify.serviceUuid, coolify.service.subUuid and coolify.databaseUuid.
Numeric ids differ between Coolify instances, so after a server transfer
the target could not find existing containers: redeploys left the old
container running and service statuses were wrong.
Containers are matched by UUID label first, then by the compose project
(Swarm: stack namespace), which is the resource UUID since July 2024, and
last by the older numeric id label. Existing containers keep working
without a redeploy and get the UUID labels on the next deploy or restart.
Container logs and scheduled-task commands and output are now shown only to
users who can edit the resource. The API returns them only to tokens with
the read:sensitive or root ability, the same as the MCP tools.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Editing a domain (UI application, service and preview domains, the
General form, API application, preview, service, and service
application updates) now releases the hostnames that the edit
removed, like removing a domain does. Records that another live
resource still uses are kept.
- A per-hostname lock (managed-dns:{team}:{hostname}) now covers the
release (re-check, Cloudflare delete, row delete) and the create
paths. A release can no longer delete a record that is being added
again; a busy lock makes the release retry and the create wait or
retry, and a create after a release makes the record again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- A Compose bind volume with a Coolify `content:` block could make
Coolify write any host file (for example /root/.ssh/authorized_keys)
when the file was loaded. Content sources must now be inside the
resource directory (./ paths); other sources get a clear validation
error for services and applications (UI, API, load, deployment),
and every content write is confined again on the server. Bind
mounts without content are unchanged. All 94 template content
volumes use ./ paths and still work.
- Quote container names in scheduled tasks and in the stop actions for
applications, previews, and services.
- Fix a development-only crash when a preview with a bind mount was
parsed (the preview suffix returned a plain string).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Andras BacsaiandClaude Opus 5.5
github-actions[bot]
