The compose parser queued ServerFilesFromServerJob for every volume on
each parse, and pages that only show data parse the Compose file. Each
sync also sent two SSH commands for each file.
- Queue the sync only for a compose deployment, and for each service
resource with file storages when the service starts or deploys.
- Read the compose service names without a parse on the Domains and
scheduled task pages.
- Check all file storages with one remote command, and stop when a
symbolic link, a special file, or an unknown state is at a file path.
- Keep the application path in a file storage when a pull request
preview is parsed. Preview deployments of the current parser write
their `-pr-<id>` copies through LocalFileVolume::forPullRequest().
- Remove the unreachable file sync from the service resource page.
Create the containers with --no-start, connect them to the destination
network, then start them. A container that crashed before the late
connect was restarting, the connect failed silently, and it never
joined the network.
Closes#11371
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The service start script goes to the server over stdin. When the
configuration of an existing volume changed, docker compose asked to
recreate the volume and read the next script line as the answer. That
line, for example the proxy network connect, did not run.
- Add < /dev/null to the service compose up and pull commands
- Do not use --yes, because it recreates the volume and deletes data
After a start, the UI showed "exited" until the regular status check ran.
That check runs on the shared high queue, which can be busy (60 s on Cloud).
The start job (database) and the start task (service, on the deployment
queue) now inspect only the started containers and store their status
before they broadcast. While a health check reports "starting", they
inspect again for up to about 15 s.
ContainerStatusAggregator now builds the per-container status and the
Compose aggregation for both writers, so GetContainersStatus and the
targeted check store the same strings.
On cloud, StartService and DeployServiceApplication dispatched their
CoolifyTask on the high queue, so service starts competed with all other
high jobs. remote_process() and CoolifyTask now accept a queue (default
high); start paths pass deployment_queue(). The queued RestartDatabase
action also runs on deployment_queue() instead of the default queue.
Switching an external volume from the old <uuid>_<name> volume to the
declared external volume on redeploy could make an app look as if it
lost its data (for example a database that initializes a new, empty
data directory).
- If a resource already has the storage entry with the old generated
name, the parsers keep using that volume and show a warning in the
deployment log and the service start log, with the steps to switch.
- Without that entry (new resources, or external volumes added later)
the external volume is used as declared.
- Deleting the old storage entry (storage page) switches to the
external volume on the next deployment; the storage entry shows a
note about it.
- Legacy Compose applications (parser versions 1 and 2) never stored
their volumes, so they keep the old volume names.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Compose content files are written by a queued job. Deployments and
service starts now check all content files with one command before
docker compose up: a missing file or an empty directory (left by
Docker) is written; an existing file is kept; a directory with files
is kept with a visible warning.
- The server file sync that runs after every parse marked a file
storage as a directory and deleted its configured content when a
directory was at its path. A storage with content now keeps its
content; an empty directory is replaced with the file.
- Saving a storage no longer fails for an existing file, replaces an
empty directory, and no longer deletes a directory with files.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Escape service application lifecycle command arguments for deploy, restart, stop, and log status checks.
Validate API update payloads from JSON/form data before applying allowed fields, preserving explicit boolean and null values.
Add coverage for service application API authorization, team isolation, validation, and command escaping.
Andras Bacsai
Bakr