Configure remote_images for dev vs. prod

Support
,
1
  • We use Convex, a hosted DB, which gives each dev their own hosted dev DB.
  • Uploaded images are served from our DB instances, like https://foo-instances.convex.cloud/images/1234

I want to add a different remote_path for the Netlify Image CDN in local dev vs. in production but cannot figure out how.

  • I wrote a build plugin with both onPreDev and onPreBuild that writes .netlify/deploy/v1/config.json based on the “CDN Integration” doc, but that file does not seem to be read in local development?
  • The remote URL is an environment variable configured in Netlify’s UI and in .env.local for local development
  • Doesn’t appear possible to reference an environment variable inside netlify.toml

How can I change the image CDN in dev vs. prod and have it be based off a environment variable?

2

Why not simply add all the remote URLs that you’d end up using? You can add the dev as well as prod values in there. Not sure why it needs to be per environment. Could you clarify if I’m missing something?

3

Thank you for the response.

Each developer gets their own remote DB instance. It would be cumbersome to add/remove remote URLs as engineers work on the project and at a large enough team size it would be untenable. It’s also not 100% correct because we don’t want our prod app to be loading images from dev DB instances.

4

Sections like [[headers]] and [[redirects]] are able to replace values at build time with sed, but the images config has already been read at that point. I am hoping to do a similar replacement in the [images] block.

5

Yes, but unless you use your dev URLs in the prod instance, that won’t happen. As long as you don’t end up adding dev URLs in your prod instance, simply having the extra URLs in the netlify.toml won’t make a difference.

I don’t believe this would be an issue unless each dev is getting absolutely random URLs. As long as they have a pattern, you can use a RegEx, for example:

https:\/\/[a-z]*-instances\.convex\.cloud\/images\/.*

Even if everyone gets a random URL, like I mentioned, it would be a one-time add (or remove) and won’t have to be done repeatedly.

It’s currently not supported, but we can add a feature request. Though, based on the above workarounds, I believe the priority for this would be very low.

6

I ended up adding all convex.cloud URLs, which is not ideal but works. What happens to our bandwidth usage if someone else uses our production Netlify instance to point to URLs on Convex instances we don’t own? That was my concern with allowing all subdomains.

7

I’m sorry, I’m not sure if I understand this question. Could you try rephrasing it?

8

Because I added all *.convex.cloud URLs to the allowlist you can presumably use our Netlify app to point to any public Convex instance - even ones we don’t own or control.

What happens to our Netlify usage if someone uses our production Netlify Image CDN URLs to point to Convex instances that aren’t ours? Is Image CDN usage a billable feature of Netlify?

# our fake website
https://foo.com 

# our fake Convex instance
https://good.convex.cloud

# bad actor's fake Convex instance
https://bad.convex.cloud

# bad actor's use of our Netlify
https://foo.com/.netlify/images?url=https://bad.convex.cloud/abc
9

Oh, when you said all convex.cloud instances, I thought you meant all instances specific to you. But since you mentioned, you added a wildcard, you’re right, that’s a potential exploit pattern.

In that case, I think what I said before would be relevant:

You can still hardcode your specific instances as a one-time thing. If a new instance gets added, you can add it in the config. Same goes for removal. I’m not completely familiar with your workflow, so I don’t know how frequently you have to add or remove, but in most cases I think the above should work.

But even in the case where you add a wildcard, the scope of problem is limited to your site somehow leaking your confidential information to public. Unless someone finds out about you using Netlify Image CDN and having a wildcard config for the exact same service that they wish to use, this won’t be exploited. I’m not denying the existence of this loophole, just that the possibility of exploit is low. It’s almost the same level of risk as with some webhook URLs like Netlify Build Hooks or some Slack webhooks, etc. where there’s no authentication involved and the only thing keeping it from the public is the uniqueness in the URL. The only benefit with webhooks is that, you can delete the old one and create a new URL. With Image CDN, that won’t be possible.

If you want an additional layer of security, you could do the following;

  • Create a separate Netlify site where you’d setup the Image CDN.
  • Use Netlify Rewrites to rewrite the image requests from your current site to that site.
  • If by chance your second site’s original URL gets exposed, you could rename the site and change the rewrites in the original site.