feat(compose): support registry images and remote prebuilt deploys

[designly1]

Closes #5224

Summary

• Adds optional build server and build registry settings to Compose stacks, mirroring the application remote-build flow: images are built and pushed on the build server, then the deploy server pulls prebuilt images instead of building locally.
• Introduces a prebuilt deploy path (pull + up --no-build) when a build server is configured, with registry login on both build and deploy hosts.
• Fixes split build/deploy logging so deploy-phase logs are written on the deploy server (including log directory creation and error-path log aggregation) and corrects chained prebuilt compose commands to prefix follow-up segments with docker compose.

Demo

https://cdn.designly.biz/video/dokploy-test-demo.mp4

Hardening

This feature introduced a second FK from compose to server (buildServerId, alongside existing serverId). Several server-management paths were updated to handle that safely:

Drizzle relation disambiguation

composeRelations already named its two server links (composeServer, composeBuildServer), but serverRelations still had an unnamed compose: many(compose). Any query that loaded a server with with: { compose: ... } — including remote server delete — failed with:

There are multiple relations between "compose" and "server". Please specify relation name

Fix: mirror the application pattern on the server side:

• compose → relationName: "composeServer" (deploy target)
• buildCompose → relationName: "composeBuildServer" (build host)

Server delete guardrails

haveActiveServices() now counts both deploy-target and build-server references before allowing deletion:

• applications + buildApplications
• compose + buildCompose

Previously only the deploy-target side was checked. A server used only as a build host could appear deletable (totalSum === 0 in the UI) even while compose stacks still referenced it via buildServerId.

Registry authorization (compose update)

compose.update now requires the target compose to belong to the active organization (matching one/delete) before any fields are persisted. Registry and build-server IDs are then validated against the same active org. This closes the cross-org credential association Greptile flagged when accessedServices spans organizations.

Split build/deploy log cleanup and read path

• Cleanup: when buildServerId is set, deployment log directories are removed from the build server on cleanup, preventing orphaned log files after split build/deploy runs.
• Read path: deployment.readLogs now resolves the log host as deployment.buildServerId || deployment.serverId || …, matching where createDeploymentCompose writes the main log file on split build/deploy runs.

Database migration

• 0188_sharp_arclight.sql adds compose.buildServerId and compose.buildRegistryId (nullable FKs to server and registry).
• Rebased onto latest canary; upstream already had 0187_grant_terminal_permission_to_read_roles.

Documentation

Companion docs PR: Dokploy/website#178

Test plan

• Run migration on a fresh/canary instance and confirm Compose settings show Build Server + Build Registry fields
• Deploy a compose stack with build directives on the same server (no build server) — behavior unchanged
• Deploy a compose stack with build server + registry on a different deploy server — build/push succeeds on build host, deploy host pulls and starts without --build
• Confirm deployment logs include both build and deploy phases when servers differ
• Verify failed deploys still surface deploy-phase logs in the main deployment log
• Delete a remote server with no services — succeeds (no Drizzle relation error)
• Delete a remote server referenced as a compose build server — blocked with "Server has active services"
• Attempt compose update on a foreign-org service — rejected before registry is persisted
• Read deployment logs via API for a split build/deploy compose run — returns build-server log content
• Run pnpm test __test__/compose/create-command-prebuilt.test.ts
• Run pnpm test __test__/compose/build-compose-command.test.ts
• Run pnpm test __test__/compose/build-registry-images.test.ts

Validated on gpc3 (ghcr.io/designly1/dokploy:local).

[designly1]

Thanks @greptile-apps — both P1s were valid and are fixed in 38bcee3:

1. Unscoped build registry credentials — compose.update now verifies buildRegistryId belongs to the active organization before persisting (same pattern as the registry router).
2. Build-server logs escape cleanup — removeDeployment and removeDeploymentsByComposeId now delete logs via buildServerId || serverId, matching where create writes them.

Note: applications already have a similar buildRegistryId update ACL gap and related log-host cleanup quirks; leaving that as a separate follow-up since it predates this PR.

[greptile-apps]

Both fixes look correct.

Registry ACL (compose.ts) — the update handler now fetches the registry and gates on reg.organizationId !== ctx.session.activeOrganizationId before persisting, exactly matching the pattern used elsewhere. No gaps visible.

Log cleanup (deployment.ts) — both removeDeploymentsByComposeId and removeDeployment now resolve logServerId = deployment.buildServerId || deployment.serverId (or the compose equivalent) and route the rm to that host. createDeploymentCompose was already writing to buildServerId || serverId, so read and delete now use the same host.

The pre-existing application gap note is fair — it predates this PR and is a separate surface. Both P1s here are properly addressed.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.

[designly1]

Re-submitted with an additional hardening commit (a662f163a).

What changed since last review:

• Fixed remote server delete failing with Drizzle's ambiguous compose ↔ server relation error after buildServerId was added
• Named server-side relations (compose / buildCompose) to match the compose schema
• Extended haveActiveServices() to block deletion when a server is referenced as a build host (compose or application)

PR description updated with a Hardening section covering relation disambiguation, delete guardrails, registry org validation, and split build/deploy log cleanup.

Validated on gpc3 (ghcr.io/designly1/dokploy:local).

[designly1]

Re-submitted with Greptile follow-up fixes in e74ffde28.

Addressed since last review:

1. Cross-tenant registry association — compose.update now loads the compose and rejects updates when the service is not in the active organization, before persisting buildRegistryId or other fields (same guard as one/delete).
2. Split logs read from wrong server — deployment.readLogs now prefers deployment.buildServerId when resolving the remote host, matching where split compose deployments write the main log file.

Prior hardening commits remain: server-relation disambiguation (a662f163a), registry org validation + log cleanup (38bcee359), split deploy logging (12a35e133).

Please re-review.

[designly1]

Rebased onto latest canary and resolved the Drizzle migration conflict.

Migration fix: upstream already had 0187_grant_terminal_permission_to_read_roles, so the compose registry migration was renumbered to 0188_sharp_arclight (SQL, snapshot, and journal updated; snapshot prevId chain fixed).

Branch is now merge-clean against canary. Please re-review when you have a chance — @Siumauricio

[designly1]

Follow-up to get this merge-ready per contributing guidelines:

• Issue: Closes feat(compose): remote build server and registry for prebuilt deploys #5224
• Docs: docs(compose): build server support for Compose website#178
• Greptile threads: all 4 resolved
• PR description: updated migration to 0188, test plan checked off

@Siumauricio — ready for review when you have a chance.

Still optional: a short screen recording of the Compose Advanced → Build Server flow would help reviewers (validated manually on gpc3, no recording attached yet).

[designly1]

Demo video (Compose build server + registry, split build/deploy on gpc3): https://cdn.designly.biz/video/dokploy-test-demo.mp4