feat(cloudflare/container): support image-only containers without a main entrypoint

[agcty]

Motivation

Cloudflare.ContainerApplication currently fails with Container requires a \main` entrypoint.even when thedockerfileprop fully describes the image. That blocks containers backed by prebuilt service images — e.g.cloudflare/sandboxorghcr.io/drizzle-team/gatewayattached to a Durable Object namespace — where there is no JS program to bundle and the image's ownENTRYPOINT/CMD` should run.

Change

• main is now optional when dockerfile is provided; omitting both still fails with a clear error (Container requires a \main` entrypoint or a `dockerfile`.`).
• Image-only path: the user Dockerfile is used verbatim — no WORKDIR/COPY/ENTRYPOINT statements are appended, so the image's own entrypoint runs. The build-and-push flow is unchanged otherwise (the context just contains only the Dockerfile).
• The image hash covers the final Dockerfile alone when there is no bundle (sha256Object drops the undefined bundleHash key).
• The existing entrypoint/command configuration overrides keep working for both paths.
• Cloudflare.Container (the platform/layer form) is unaffected — its props still require main.

Example:

const sandbox = Cloudflare.ContainerApplication("sandbox", {
  dockerfile: "FROM docker.io/cloudflare/sandbox:0.7.18-python",
  instanceType: "lite",
  maxInstances: 5,
})

Validation

• bun tsc -b clean.
• No Container test harness exists under packages/alchemy/test/Cloudflare yet; happy to add one if you can point me at the preferred seam for docker-dependent paths.

🤖 Generated with Claude Code

[sam-goodwin]

Solving same problem as #583 ?

Made a comment on how i think the DX should look here #583 (comment)