Bug Report: Public Mode Images Not Downloading on Custom Domains

[tristdrum]

Summary:

There appears to be a bug in Retool’s public mode when using custom domains. Specifically, images fail to download when accessed via a custom domain public link, while they work as expected when using the standard Retool public link.

Reproduce the Issue:

Here are two links to demonstrate the problem:

1. Link 1 (Retool Public Link):

https://workweek.retool.com/embedded/public/b7671054-d4b4-48ad-bbe0-8710d5ec98db

If you click this link and then click the download button (“Click Here to Download the Big Container”), the download works as expected, including the image.

2. Link 2 (Custom Domain Link):

https://admin.workweek.africa/embedded/public/b7671054-d4b4-48ad-bbe0-8710d5ec98db

This is the exact same app, just using a custom domain. When you click the download button, the download fails to include the image.

This app setup, with the JSON export provided, allows anyone to replicate and test the issue themselves.

Environment Details:

• Retool Cloud is being used.

• The plan includes support for public mode and custom domains.

• Custom domain DNS records are no longer proxied by Cloudflare, ruling out that as a potential cause.

Impact:

This bug has disrupted multiple customer workflows, particularly for processes requiring image downloads. It needs urgent resolution to restore critical functionality.

Attachments:

• Exported JSON file of the app for testing and reproduction.

Request:

Please investigate and resolve this issue as a priority. It significantly affects the usability of public apps on custom domains. If more information or further testing is required, I’m happy to assist.

Thank you for your help!

BUG: Public Mode Images not downloading.json (18.1 KB)

[Derek_Watts]

@tristdrum I see and download the image on both apps.

[tristdrum]

@Derek_Watts thanks so much for commenting!

Maybe you're misunderstanding what's expected. This is the two different downloaded PDFs side by side.

Can you post an equivalent screenshot?

[Derek_Watts]

[tristdrum]

@Derek_Watts so that's a screenshot of the web pages (the images show fine there)

Click on the blue button to download a file from each link to see what I'm talking about.

[tristdrum]

Under the hood it's using a JS query like this:

const options = {
  componentsToInclude: ["containerBig"],
}
let fileName = `containerBig`;
utils.downloadPage(fileName, options)

Which doesn't render the image onto the PDF which get's downloaded.

Can you recreate?

[tristdrum]

@AbbeyHernandez @Paulo does this make sense to you?

[Derek_Watts]

ok I see @tristdrum so the PDF is the problem, I don't see the image on either downloaded PDF, both domains produce the same result.

[Derek_Watts]

New recording by Derek Watts

[tristdrum]

Wow thanks for the diligent recreation @Derek_Watts !

Super strange that you've gotten an even worse result than me!

Do you have an account with a Custom Domain set-up?

Anyway you could import that JSON app file I attached onto your organisation and see if it's a problem with your Retool sub-domain & custom domain too?

[Derek_Watts]

@tristdrum I do have a custom domain, I downloaded and used the app on a public link. The PDF generates without a problem with the image, chrome and safari. Very strange

[tristdrum]

@Derek_Watts can you send me your custom domain link to that app? (even private DM if you don't want to share in the forum)

[tristdrum]

Hey @Derek_Watts !

Thanks for the DM! The same thing happened to me on your Custom Domain link!

No image again. Even though your download includes it.

@AbbeyHernandez @Paulo will hopefully get to chat to you both at Office Hours later

[Darren]

Hey @tristdrum! Thanks for reaching out.

When using the links you provided, I am seeing the same behavior as @Derek_Watts - neither PDF includes the nested image.

[Derek_Watts]

Hey @Darren,

Its pretty strange. When I downloaded it and ran it through my cloud account with the custom domain, the PDF downloaded just fine with the image included.

However, when @tristdrum tried, the image didn’t show up for him. Definitely odd—it feels like it might be client-side.

I tested it using both Chrome and Safari on my end, and everything worked as expected, but it still didn’t work for @tristdrum.

Just some context for you.

[tristdrum]

Hey @Darren !

Thanks for getting back to me. Sadly I couldn’t join office hours earlier.

Do you agree that this is a bug/issue and that Retool will try to understand and solve it now that you are experiencing it first hand?

As I said, this is a demo of a live issue that’s affecting our customers - as a result of what I’m thinking might be a Retool regression over the last few weeks/months.

Thanks for responding again!

[Darren]

There's definitely something going on - I think I've figured it out, though.

Invoking utils.downloadPage on any app with image content results in a call to /api/imageProxy, which is designed to bypass potential CORS issues. The problem is that this is an authenticated endpoint, meaning it throws a 401 error when the request lacks the necessary access token. Because public apps aren't authenticated, that request fails and we don't get an image in the resulting PDF.

What made this difficult to diagnose was the fact that editing the app caches the necessary authentication cookies, which were then being accessed by the public app on the same domain. If I'm right, this is an issue across all public apps, not just those with custom domains.

I'll reach out to the team to start talking about a fix and keep you updated here as that conversation moves forward!

[tristdrum]

Hi @Darren,

Thank you so much for looking into this and explaining what’s going on! That makes a lot of sense now. I really appreciate the detailed breakdown—it’s incredibly helpful in understanding the root cause.

Would you be able to share when this change was implemented? It would be useful for us to know how long this issue has been affecting our users so we can document it for our records.

Also, I’d love to understand whether this counts as a high-priority fix for the team or if there’s a broader shift in how Retool supports unauthenticated public apps. Knowing this would help us plan accordingly and manage our customer expectations.

Looking forward to hearing from you, and thanks again for all your help with this!

[Darren]

@tristdrum

Knowing this would help us plan accordingly and manage our customer expectations.

Understandable! I'm not sure what might have changed on our end but will talk to the team. Similarly, it feels like there needs to be a decision made about public apps and authenticated endpoints. I'll provide an update here as soon as I can!

UPDATE: I must have missed the announcement, but this was an intentional decision made in response to an internal security audit. It looks like the breaking change went into effect November 19, so it's been about two weeks now. I've included a blurb below about potential workarounds, but you can also make a post in the original thread!

Public app users will no longer be able to export PDFs with images hosted on separate domains. All other components will be included in the PDF export. We recommend moving your publicly hosted images to be hosted on the same domain as your Retool instance. For example, you could use images that are natively uploaded to the Image component, stored in Retool Storage, stored in Retool DB, Base64-encoded, or stored in an S3 bucket.