Skip to content

Image.from_dockerfile ignores inherited ENTRYPOINT from base images #3853

@radisicc

Description

@radisicc

[Bug] Image.from_dockerfile ignores inherited ENTRYPOINT from base images

Description

The Image.from_dockerfile parser and Create Sandbox API currently fail to inherit the ENTRYPOINT defined in a base image when processing a child Dockerfile.

Problem

In standard Docker semantics, a child image automatically inherits the ENTRYPOINT (and CMD) from its FROM base image unless explicitly overridden in the child Dockerfile. Currently, Daytona's image parsing logic drops this inherited entrypoint entirely.

This causes significant DX friction:

  1. Broken Compatibility: Valid, standard Dockerfiles fail to start their intended processes when spun up as Daytona sandboxes.
  2. Boilerplate Workarounds: Developers are forced to manually inspect the upstream base image, find the original entrypoint, and explicitly hardcode it into their child Dockerfile just to get the sandbox running.

Proposal

Update the Dockerfile parsing and image resolution logic within the API to respect standard OCI/Docker inheritance rules. When generating a sandbox from a Dockerfile, Daytona must inspect the base image and apply its ENTRYPOINT if the child Dockerfile does not define one.

DX & UX Implementation:

  • Interface: No changes to the public API (Image.from_dockerfile should implicitly handle this).
  • Feedback: Sandbox initialization logs should seamlessly execute the inherited entrypoint. If the build pipeline outputs image metadata, it should accurately reflect the inherited instruction.
  • Configuration: "Zero-config" fix. This must be the default behavior to maintain Docker parity.

Acceptance Criteria

  • Child Dockerfiles processed via Image.from_dockerfile correctly inherit the ENTRYPOINT of their base image.
  • If a child Dockerfile explicitly sets an ENTRYPOINT, it successfully overrides the base image's configuration.
  • Sandboxes created from these images start the correct default process without manual user overrides.
  • DX validated: Users can bring standard Dockerfiles without needing to redefine base entrypoints.

Impact

Restores expected standard Docker behavior. This prevents silent sandbox startup failures and eliminates the frustration of debugging and modifying perfectly valid Dockerfiles just to make them compatible with Daytona.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions