[@astrojs/node] Image endpoint using default settings 404 in production after Astro v5

[lee-arnold]

Astro Info

Astro                    v5.1.0
Node                     v22.9.0
System                   macOS (arm64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             none

Describe the Bug

When using the Node adapter in standalone mode, upgrading from Astro v4 to v5 causes all image urls to 404. This only occurs in production.

Adding this config fixes the issue:

    image: {
        endpoint: { route: '/_image', entrypoint: 'astro/assets/endpoint/node' },
    },

I think the issue is that image.endpoint in astro v5 was changed to image.endpoint.route and image.endpoint.entrypoint, so I think that it needs to be updated here too.

Current:

'astro:config:setup': async ({ updateConfig, config }) => {
	updateConfig({
		image: {
			endpoint: config.image.endpoint ?? 'astro/assets/endpoint/node',
		},
                ...
	});
},

Should be:(?)

'astro:config:setup': async ({ updateConfig, config }) => {
	updateConfig({
		image: {
			endpoint: {
                                route: config.image.endpoint.route ?? '_image',
				entrypoint: config.image.endpoint.entrypoint ?? 'astro/assets/endpoint/node',
			},
		},
                ...
	});
},

What's the expected result?

Images shouldn't 404

Link to Minimal Reproducible Example

n/a

Participation

• I am willing to submit a pull request for this issue.

[ascorbic]

Please can you include a reproduction, using https://astro.new/repro

[lee-arnold]

I certainly can, but the issue only presents itself on production - any advice on how to use one of those repros to replicate a prod issue?

Edit: also I can't seem to get the <Image /> component from astro:assets working in any normal situation using those repros.

[ascorbic]

You can create a repro on StackBlitz on https://astro.new/repro. We can take it from there. You can run astro build and astro preview in StackBlitz to try a production build, but if we need to download it and run it locally, we can do that too. The important part if having a minimal reproduction.

[twodft]

Notice this issue too, in production build, image broken after upgrade to astro 5.2.0

[ascorbic]

@twodft can you share a reproduction

[BrettJackson1987]

@lee-arnold are you using a Docker container to deploy your project? I am having this same problem, when I updated to Astro 5 from 4. I'm not sure if the issue relates to how the _image endpoint is constructing the url or the node adapter. But I only get the issue with Docker deployed. If we are talking aboutthe same thing, then I've already created a minimal reproduction to share on confirmation (requires a Docker build).

[BrettJackson1987]

This is my minimum reproduction that I hope highlights the 404 issue.

Stackblitz

Works fine in dev and local build, BUT if you use a docker image and upload to a server you get images not displaying properly as described above.

docker build -t red-resonance .

Run on any port thats not 8080.

[twodft]

@lee-arnold are you using a Docker container to deploy your project? I am having this same problem, when I updated to Astro 5 from 4. I'm not sure if the issue relates to how the _image endpoint is constructing the url or the node adapter. But I only get the issue with Docker deployed. If we are talking aboutthe same thing, then I've already created a minimal reproduction to share on confirmation (requires a Docker build).

I use docker image too, after make a production build with astro build and preview on local, I got the issue and all images are broken,

While try the workaround by specifying the image entry point and then rebuild, it works.

I had try make a simple reproduction, but failed through...🥲

[florian-lefebvre]

I think updating https://github.com/withastro/astro/blob/main/packages/integrations/node/src/index.ts#L38-L40 (as you said) should do the job, do you want to submit a PR?

[lee-arnold]

@BrettJackson1987 thanks so much for nailing that down - it does indeed only appear in docker containers, and I've finally confirmed that for my project too.

@florian-lefebvre happy to!