Remove local-only assumptions before publishing a Compose OCI artifact

Bottom line: Review local filesystem and build assumptions before approving a Compose model for OCI publication. Treat the registry artifact as a distribution decision, with an explicit account of the inputs its consumer will need.

Source fact: documented behavior

The Package and deploy Docker Compose applications as OCI artifacts documentation is the primary reference.

The Compose OCI artifact guide specifies Docker Compose 2.34.0 or later. The documented publication limits reject service bind mounts and services that have only a build section. Local included Compose files are not published automatically; the guide calls for publishing them separately and referencing them remotely.

What the source does not establish

This article reviews documented OCI publication limits. It does not promise that packaging a model also packages application data, approves included content or establishes compatibility on a consumer host. Keep environment-value disclosure, service credentials and ordinary Compose path resolution under their separate reviews.

Applicability questions

• Which services depend on local host paths?
• Does any service have a build definition without an image reference?
• Which included files remain local to the publisher?
• What exact inputs should the intended consumer receive or obtain separately?

DSE recommendation: build a consumer-input inventory

DSE recommends a pre-publication inventory organized by service and included component. Mark host bind mounts, image references, build definitions and local includes as distinct input categories. Have the application owner identify what is essential to run the intended deployment rather than assuming a successfully parsed model is portable.

Resolve a local dependency through the application’s approved packaging design. Do not replace a path mechanically or publish a convenient unreviewed image merely to clear a limitation. Keep writable application data and environment-specific configuration under their own ownership and acceptance procedures.

For included components, record the separately published artifact and its approved remote reference when that arrangement is intended. Preserve component ownership and source revisions in the review. A reference that can be fetched should still receive the normal trust and configuration assessment before use.

Have a second operator review the inventory from the consumer’s perspective. Ask what that operator can obtain from the approved registry and what additional input remains necessary. Keep the consumer host free of accidental copies of the publisher’s working directories so a local convenience cannot conceal an incomplete distribution plan.

Verification and evidence

Proposed verification: prepare a harmless model on a disposable publisher host and a separate clean consumer environment. Include one labeled local bind-mount case, one build-only service case and a separately reviewed remote-include case. Predict which configurations meet the documented publication requirements before running the approved workflow.

Retain the model revision, publication outcome, included references and consumer input inventory. Test the intended published configuration without copying the publisher’s local tree as an undocumented repair. Inspect the actual resolved application before any execution, then perform only its approved harmless acceptance task. Record missing inputs as distribution findings rather than describing a partially reconstructed deployment as portable.

Official references

• Package and deploy Docker Compose applications as OCI artifacts — Docker Docs.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.