Add a /dashboard/canvas page that renders every team server with its
resources and their running or queued deployments, backed by a new
ServerCanvasController::dashboard endpoint and a per-server usage
endpoint for zone headers. The dashboard remembers the list/canvas
choice and each section (projects, servers) its own table/grid view.
- Show Deploying/Queued pills on canvas cards and a foldable recent
deployments panel; add shared CanvasControls component
- Allow backup downloads from the server host via the S3 download
storage (PrepareFileDownloadJob accepts a null container)
- Extract backup toggle/run actions into ManagesDatabaseBackup and
surface them in backup execution headers; merge S3 and retention
sections into the general backup settings
- Move deployments indicator to the top bar and add a main nav
resource menu with submenus; simplify breadcrumbs and settings
layouts
- Add shared variables overview canvas and scheduled task modals
- Add feature tests for dashboard canvas, view modes, navbar
submenus, backup S3 downloads and scheduled task modals
Development mode rewrote /data/coolify paths to the dev Docker volume
for every server. That is only right for the testing-host backend,
which uses the host Docker daemon. The KVM localhost and other dev VMs
have their own /data/coolify, so bind mounts, Compose content files,
the Traefik and Caddy traffic mounts, Sentinel, and database proxies
pointed to wrong paths there.
- Server::sharesDevHostDocker() and devHostDockerPath() decide per
server; only the testing-host server (ip coolify-testing-host) gets
the volume path. Production is unchanged.
- The testing-host volume names come from the Compose project
(DEV_COOLIFY_DATA_VOLUME, DEV_COOLIFY_BACKUPS_VOLUME), with the
legacy names as fallback.
- In development, saved proxy configurations with the old path are
fixed when they load and ask for a proxy restart.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Merge scripts/dev-instances into scripts/dev. Each branch gets its own
Compose project, container, volumes, port block, libvirt network, and
KVM VMs, so stop and start reuse the same data and worktrees do not
collide.
- Name instances after the branch; keep slots and APP_KEYs in the main
checkout's .dev-instances/ so they survive worktree removal
- Reuse existing QEMU VMs instead of recreating them; add dev:qemu --fresh
- Give each instance an isolated libvirt network (10.221.<slot>.0/24)
and VM names coolify-dev-<branch>--<profile>
- Publish per-instance browser ports and publish them with tailscale
serve when APP_URL is a tailnet host
- Add urls, exec, logs, container, destroy, and teardown commands; run
teardown from jean.json before Jean deletes a worktree
- Fix Reverb/terminal browser ports and the testing-host alias in the
instance compose file
- Keep fresh worktree instances working: pre-create laravel.log, log the
host dev:qemu call to stderr, and stop Vite from watching vendor/
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Andras Bacsai