"Discover Revolt" section's iframe won't load, and points to local.revolt.chat:3000 #30

New Issue

2026-02-16T12:51:11-05:00

yindo commented

2026-02-16 12:51:11 -05:00

Originally created by @Drakenasa on GitHub (May 7, 2022).

Hey everyone,

I've successfully deployed Revolt (via Docker-Compose) behind a reverse proxy with SSL. Each public subdomain points to the reverse proxy that uses the corresponding SSL certificate. From there, internally, the reverse proxy points to insecure http Revolt endpoints. To achieve this, I used the following environment variables in my .env file:

# URL to where the Revolt app is publicly accessible
REVOLT_APP_URL=https://revolt.mydomain.com:443

# URL to where the API is publicly accessible
REVOLT_PUBLIC_URL=https://revolt-vite.mydomain.com:443
VITE_API_URL=https://revolt-vite.mydomain.com:443

# URL to where the WebSocket server is publicly accessible
REVOLT_EXTERNAL_WS_URL=wss://revolt-socket.mydomain.com:443

# URL to where Autumn is publicly available
AUTUMN_PUBLIC_URL=https://revolt-autumn.mydomain.com:443

# URL to where January is publicly available
JANUARY_PUBLIC_URL=https://revolt-january.mydomain.com:443

# URL to where Vortex is publicly available
#VOSO_PUBLIC_URL=https://voso.revolt.chat     **I left Vortex commented out**

All seems to work perfectly. However, whenever I click on the "Discover Revolt" section, the iframe will not load and it will spit out the following error in the console: Refused to frame 'https://rvlt.gg/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self' https://*.revolt.chat http://local.revolt.chat:3000"

Why is it pointing to local.revolt.chat when I have already set the .env to point to https://revolt-autumn.mydomain.com:443? Is this rvlt.gg's content-security-policy blocking my domain from accessing their content, or my own content-security-policy that's misconfigured? I can't tell.

If revolt is blocking other revolt instances from accessing https://rvlt.gg/, is there a way to hide the "Discover Revolt" section entirely? Will there be a local implementation offered instead in the future?

Thank you!

Originally created by @Drakenasa on GitHub (May 7, 2022). Hey everyone, I've successfully deployed Revolt (via Docker-Compose) behind a reverse proxy with SSL. Each public subdomain points to the reverse proxy that uses the corresponding SSL certificate. From there, internally, the reverse proxy points to insecure http Revolt endpoints. To achieve this, I used the following environment variables in my .env file: ``` # URL to where the Revolt app is publicly accessible REVOLT_APP_URL=https://revolt.mydomain.com:443 # URL to where the API is publicly accessible REVOLT_PUBLIC_URL=https://revolt-vite.mydomain.com:443 VITE_API_URL=https://revolt-vite.mydomain.com:443 # URL to where the WebSocket server is publicly accessible REVOLT_EXTERNAL_WS_URL=wss://revolt-socket.mydomain.com:443 # URL to where Autumn is publicly available AUTUMN_PUBLIC_URL=https://revolt-autumn.mydomain.com:443 # URL to where January is publicly available JANUARY_PUBLIC_URL=https://revolt-january.mydomain.com:443 # URL to where Vortex is publicly available #VOSO_PUBLIC_URL=https://voso.revolt.chat **I left Vortex commented out** ``` All seems to work perfectly. However, whenever I click on the "Discover Revolt" section, the iframe will not load and it will spit out the following error in the console: `Refused to frame 'https://rvlt.gg/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self' https://*.revolt.chat http://local.revolt.chat:3000"` Why is it pointing to local.revolt.chat when I have already set the .env to point to `https://revolt-autumn.mydomain.com:443`? Is this *rvlt.gg's* content-security-policy blocking my domain from accessing their content, or my own content-security-policy that's misconfigured? I can't tell. If revolt is blocking other revolt instances from accessing `https://rvlt.gg/`, is there a way to hide the "Discover Revolt" section entirely? Will there be a local implementation offered instead in the future? Thank you!

yindo closed this issue

2026-02-16 12:51:11 -05:00

yindo commented

2026-02-16 12:51:11 -05:00

@Rexogamer commented on GitHub (May 7, 2022):

Going off the response to #31, I think making Discover visibility toggleable/not visible by default for self hosted instances would be the best solution

@Rexogamer commented on GitHub (May 7, 2022): Going off the response to #31, I think making Discover visibility toggleable/not visible by default for self hosted instances would be the best solution

yindo commented

2026-02-16 12:51:11 -05:00

@Drakenasa commented on GitHub (May 7, 2022):

Yeah, that'd be a helpful quick fix in the meantime. However, are there any plans to implement a self-hosted version of the discover servers / bots / themes section?

@Drakenasa commented on GitHub (May 7, 2022): Yeah, that'd be a helpful quick fix in the meantime. However, are there any plans to implement a self-hosted version of the discover servers / bots / themes section?

yindo commented

2026-02-16 12:51:11 -05:00

@Rexogamer commented on GitHub (May 7, 2022):

Whilst I'm not sure as to the specifics of why, there are no current plans to open source Discover.

@Rexogamer commented on GitHub (May 7, 2022): Whilst I'm not sure as to the specifics of why, there are no current plans to open source Discover.

yindo commented

2026-02-16 12:51:11 -05:00

@Drakenasa commented on GitHub (May 7, 2022):

That's a real shame. i wonder if people could create an simple alternative to it, as it's definitely a useful feature to build a sense of community within your network rather than a collection of isolated servers.

@Drakenasa commented on GitHub (May 7, 2022): That's a real shame. i wonder if people could create an simple alternative to it, as it's definitely a useful feature to build a sense of community within your network rather than a collection of isolated servers.

yindo commented

2026-02-16 12:51:11 -05:00

@insertish commented on GitHub (May 7, 2022):

Opened an issue, https://github.com/revoltchat/revite/issues/602.
Closing this one.

For context on Discover, it's quite tightly integrated with custom tools I built, so it'd take a fair amount of time to decouple to make it public if we were to go that route. In general, I'm not sure if we want to make it public, it's main intent is to help grow the platform and I personally wouldn't see much benefit in maintaining it for use with other instances.
We'll probably revisit this when we have the time to.

@insertish commented on GitHub (May 7, 2022): Opened an issue, https://github.com/revoltchat/revite/issues/602. Closing this one. For context on Discover, it's quite tightly integrated with custom tools I built, so it'd take a fair amount of time to decouple to make it public if we were to go that route. In general, I'm not sure if we want to make it public, it's main intent is to help grow the platform and I personally wouldn't see much benefit in maintaining it for use with other instances. We'll probably revisit this when we have the time to.

yindo referenced this issue

2026-02-16 12:51:39 -05:00

[PR #30] [CLOSED] Mac Compatibility - Fixes port already in use error #150

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: stoatchat/self-hosted#30