We’re moving to a new DigitalOcean droplet and tried using the marketplace image. When running the setup script, it fails early on because our domain name is still pointing to our current instance in production.
I need to get this new installation up and running so I can restore its backup and then update the DNS records after that.
Checking your domain name . . .
WARNING: Port 443 of computer does not appear to be accessible using hostname: x
WARNING: Connection to x (port 80) also fails.
This suggests that x resolves to some IP address that does not reach this
machine where you are installing discourse.
The first thing to do is confirm that x resolves to the IP address of this server.
You usually do this at the same place you purchased the domain.
If you are sure that the IP address resolves correctly, it could be a firewall issue.
A web search for "open ports YOUR CLOUD SERVICE" might help.
The domain name does in fact respond on ports 80 and 443, so this error message appears to be in error as well.
We (the Discourse team) don’t manage the DO marketplace image, so I’m afraid we’re going to be of limited help resolving that specific issue.
But you do manage this, yes?
Even the manual install instructions have this step.
Surely I can’t be the first person to do this. How are people doing it?
Yes, we do manage that. I did not look at the code, I assumed the check was coming from the marketplace image.
./discourse-setup is intended as a simple way of setting up Discourse - avoiding the need to manually edit a text file when spinning up a new Discourse site. Your use case isn’t a “typical” one that the setup script handles.
In your case, your best bet would likely be to copy
containers/app.yml file from your current server to the new one. Alternatively you can manually edit the file yourself as suggested on lines 75/76:
Where can I find the default app.yml? I want to start with a fresh default installation.
Also, how do I get the server up and running without the setup script? Accessing the IP address is still unresponsive since I can’t run the setup script.
Default can be found at
Also on GitHub.
Assuming you’re following the official install guide, after the commands in “Install Discourse”, you’ll want to do the following:
Copy the default yaml file from samples to containers:
cp samples/standalone.yml containers/app.yml
Edit the file by hand:
Bootstrap and start Discourse:
./launcher rebuild app
Thank you, that gets me closer.
But now I cannot import the backup because I cannot activate my temporary admin account:
(6) Refused to load the script ‘’ because it violates the following Content Security Policy directive: "script-src ". Note that ‘script-src-elem’ was not explicitly set, so ‘script-src’ is used as a fallback.
Is there a direct way to restore from a backup or disable the CSP until then?
Here’s how to restore a Discourse backup from the command line, without ever booting the Discourse web UI. This is handy when you’re moving servers.
Download the latest backup file from source Discourse instance.
The destination discourse needs to be bootstrapped (run ./discourse-setup or copy your existing app.yml)
Make sure that the destination Discourse instance is on the latest version. Update it if necessary.
SSH into the destination server, or otherwise c…
SSH to your server, then:
sudo ./launcher enter app
SiteSetting.content_security_policy = false
Note that I’d try the backup restore from CLI first - it solves the actual issue you have (restore a backup) vs the current roadblock (CSP).
Thanks for the pointers.
Running restore, I get:
ERROR: could not create unique index "index_incoming_referers_on_path_and_incoming_domain_id"
DETAIL: Key (path, incoming_domain_id)=(/s/free+proxy+hideip.me, 1009) is duplicated.
EXCEPTION: psql failed: DETAIL: Key (path, incoming_domain_id)=(/s/free+proxy+hideip.me, 1009) is duplicated.
script/discourse:284:in `<top (required)>'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/exe/bundle:49:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/exe/bundle:37:in `<top (required)>'
Trying to rollback...
Cleaning stuff up...
Dropping functions from the discourse_functions schema...
Removing tmp '/var/www/discourse/tmp/restores/default/2020-12-29-214249' directory...
Marking restore as finished...
Notifying 'system' of the end of the restore...
Looks like you have a corrupt index. Have you run an upgrade on the existing instance? There’s a chance that help.
There is a topic somewhere with instructions for copying over the raw database (and let’s encrypt) files from the old instance. That’s probably what I would do.
What’s rub run?
Upgrades on the existing instance keep having errors (different errors than this one) so that’s why I’m moving to a new instance.
Do you have a link to this?