Commit Graph
7 Commits
Author SHA1 Message Date
Andras Bacsai c6b8dfe367 fix(status): store the status of a database or service right after it starts
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.
2026-10-03 21:16:44 +02:00
Andras Bacsai f1f7272494 fix(queue): run service and database start commands on the deployment queue
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.
2026-10-03 20:50:49 +02:00
Andras BacsaiandClaude Opus 5.5 49ae227f6e fix(compose): keep the old volume of existing resources for external volumes
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>
2026-09-27 17:24:51 +02:00
Andras BacsaiandClaude Opus 5.5 fe6854c73e fix(storage): write content files before compose up and never drop their content
- 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>
2026-09-27 16:26:56 +02:00
Andras Bacsai 908b5cc09d feat(api): add service database management endpoints
Add service database CRUD, logs, and lifecycle actions, and document service application operations with OpenAPI tests.
2026-07-15 12:29:58 +02:00
Andras Bacsai a165e03d06 fix(service-apps): harden updates and docker commands
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.
2026-07-07 15:10:24 +02:00
Bakr 8ad65a0ef8 eat(api): add service-applications API to manage service applications 2026-03-29 06:03:47 +03:00