Discourse Rebuild Fails During Bootstrap: Git HTTPS Timeout, Looking for a Clean SSH-Based Workaround

Support
1

Hello,

I am running a standard self-hosted Discourse installation on Ubuntu using the official discourse_docker setup.

Environment

  • Ubuntu Server
  • Docker
  • Official discourse_docker
  • Single-container installation (app.yml)
  • Rebuild performed using:
cd /var/discourse
./launcher rebuild app

Problem

The rebuild process fails during the bootstrap phase when Discourse attempts to update the application source from GitHub.

The failure occurs at:

git fetch --tags --prune-tags --prune --force origin

and produces:

fatal: unable to access 'https://github.com/discourse/discourse.git/': SSL connection timeout

followed by:

FAILED
bootstrap failed with exit code 128

Important Findings

GitHub is reachable via HTTPS

On the host:

curl -I https://github.com

works correctly.

Also:

curl -I https://raw.githubusercontent.com

works correctly.

Git over HTTPS is unreliable in my environment

Inside the Discourse environment:

git ls-remote https://github.com/discourse/discourse.git

fails with:

SSL connection timeout

From my investigation, this appears to be caused by issues with my Internet provider’s connectivity to GitHub over HTTPS. At the moment, I am not trying to solve that networking problem itself. Instead, I am looking for a way to perform Discourse rebuilds using SSH, since SSH connectivity to GitHub works correctly in my environment.

GitHub SSH authentication works

I generated a new SSH key, added it to GitHub, and verified authentication:

ssh -T git@github.com

returns:

Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.

Also:

git ls-remote git@github.com:discourse/discourse.git

works successfully from the host.

Repository URLs

On the host, I changed /var/discourse to use SSH:

origin git@github.com:discourse/discourse_docker.git

and Git operations work.

However, inside the Discourse application container:

cd /var/www/discourse
git remote -v

shows:

origin https://github.com/discourse/discourse.git

So during bootstrap, Discourse still attempts to use HTTPS.

What I Would Like To Achieve

My primary goal is to make Discourse rebuild reliably in an environment where GitHub HTTPS connections are unstable or frequently time out.

I would like to know:

  1. Is there an officially supported way to make Discourse bootstrap and rebuild use GitHub over SSH instead of HTTPS?
  2. If not, what is the recommended approach for environments where Git HTTPS is unreliable but SSH works correctly?
  3. Is there a supported method to inject SSH credentials into the bootstrap/build phase?
  4. Has anyone successfully configured discourse_docker to fetch Discourse source updates over SSH?

I would prefer a solution that survives future upgrades, but I am also interested in understanding whether SSH-based fetching during bootstrap is technically supported.

Any guidance would be greatly appreciated.

Thank you.

2

Is outbound https blocked somehow?

It won’t be easy to rewrite all of the stuff that expects to be able to use https. I’m afraid having reliable networking is what you need to solve.

3

Thanks for the clarification, Jay.

After additional diagnostics, it appears that outbound HTTPS is not blocked on the host itself — direct curl requests to GitHub and raw.githubusercontent.com succeed consistently. The issue only manifests inside the bootstrap container, where git ls-remote over HTTPS intermittently hits SSL timeouts. SSH-based access to GitHub remains fully reliable, which is why I initially explored whether a clean SSH path during bootstrap might be viable.

Your point about the difficulty of rewriting all components that assume HTTPS is well taken. Given that the HTTPS failures are tied to instability in my ISP’s route to GitHub rather than a local firewall or Docker networking issue, I’ll focus on stabilizing the upstream network path instead of trying to modify the bootstrap process.

Thanks again for the guidance and for clarifying the constraints around HTTPS usage in the build pipeline.

4

I think there’s a way to specify a proxy, so maybe you could point to a proxy that avoids using your isp network. It seems easier to find another isp, but life often isn’t as easy as we would like.