CircleCI Docker executor with setup_remote_docker: registry credential propagation and layer caching across daemon boundary

Interoperability gap between primary container and remote Docker daemon

CircleCI's Docker executor runs jobs inside a primary container while setup_remote_docker provisions a separate, ephemeral Docker daemon reachable over TCP. The two environments share a job lifecycle but maintain independent Docker contexts, creating uncertainty around credential propagation, layer caching, and filesystem visibility.

Constraints and uncertainty

• Registry authentication performed in the primary container does not automatically propagate to the remote daemon; private image pulls or builds inside the remote context may require separate credential configuration.
• Docker layer caching is a plan- and executor-dependent feature that may not be available for remote Docker builds, and its behavior differs between CircleCI cloud and self-hosted installations.
• Volume mounts and filesystem paths visible in the primary container are not automatically accessible to containers started inside the remote daemon.

These boundaries affect CI pipeline reliability when building and pushing images that depend on private base images, shared build caches, or workspace artifacts.

Questions

1. What is the recommended pattern for propagating registry credentials from the primary container into the remote Docker daemon without exposing secrets in plaintext run steps?
2. Under which CircleCI plans and executor types does Docker layer caching apply to builds executed inside the remote daemon, and how is it enabled?
3. How can workspace artifacts or build-time files be made available to containers started within the remote Docker daemon?