Summary
astro deploy (hosted) and astro remote deploy (Remote Execution) expect structurally different images — a normal Astro Runtime image vs. a Remote Execution agent image built FROM astro-remote-execution-agent. There's currently no signal to a user if they've pointed the wrong Dockerfile flavor at the wrong command, e.g. if a project's Dockerfile accidentally ends up FROM'd on the agent base image instead of a Runtime image (easy mistake if Dockerfile/Dockerfile.client get mixed up while iterating on a Remote Execution setup).
Concretely, this can result in an agent-flavored image getting deployed via plain astro deploy and scheduled as a Deployment's scheduler/webserver/worker — which will crash-loop, since the agent's entrypoint only supports worker/dag-processor/triggerer, not scheduler (or vice versa: a plain runtime image built via Dockerfile.client() won't behave as a working Remote Execution agent).
Proposal
Add a best-effort, naive check that warns (and for the post-build check specifically, cancels the deploy — mirroring the existing ValidRuntimeVersion cancel-on-mismatch convention in buildImage()) when the image being deployed looks like the wrong flavor for the path being used:
- Pre-build: inspect the Dockerfile's (or
Dockerfile.client's) FROM image directly, before running docker build, so an obvious mismatch is caught before wasting time on a build. Best-effort only — skips silently on ARG-templated or otherwise unresolvable FROM lines, falling through to the post-build check as the real backstop.
- Post-build: inspect the actual built image. Since this is the real image about to be pushed and run, with no ARG/multi-stage ambiguity, this check is authoritative for the CLI's own build flow and should cancel the deploy on a clear mismatch rather than just warn.
This doesn't need to do full image content verification, layer digest matching, or anything heavyweight — just a quick, best-effort sanity check to catch this specific, easy-to-make mistake earlier and with a clearer error message than "scheduler is crash-looping in production."
🤖 Filed with the help of Claude Sonnet 5 (Claude Code)
Summary
astro deploy(hosted) andastro remote deploy(Remote Execution) expect structurally different images — a normal Astro Runtime image vs. a Remote Execution agent image built FROMastro-remote-execution-agent. There's currently no signal to a user if they've pointed the wrong Dockerfile flavor at the wrong command, e.g. if a project'sDockerfileaccidentally ends up FROM'd on the agent base image instead of a Runtime image (easy mistake ifDockerfile/Dockerfile.clientget mixed up while iterating on a Remote Execution setup).Concretely, this can result in an agent-flavored image getting deployed via plain
astro deployand scheduled as a Deployment's scheduler/webserver/worker — which will crash-loop, since the agent's entrypoint only supportsworker/dag-processor/triggerer, notscheduler(or vice versa: a plain runtime image built viaDockerfile.client()won't behave as a working Remote Execution agent).Proposal
Add a best-effort, naive check that warns (and for the post-build check specifically, cancels the deploy — mirroring the existing
ValidRuntimeVersioncancel-on-mismatch convention inbuildImage()) when the image being deployed looks like the wrong flavor for the path being used:Dockerfile.client's)FROMimage directly, before runningdocker build, so an obvious mismatch is caught before wasting time on a build. Best-effort only — skips silently on ARG-templated or otherwise unresolvableFROMlines, falling through to the post-build check as the real backstop.This doesn't need to do full image content verification, layer digest matching, or anything heavyweight — just a quick, best-effort sanity check to catch this specific, easy-to-make mistake earlier and with a clearer error message than "scheduler is crash-looping in production."
🤖 Filed with the help of Claude Sonnet 5 (Claude Code)