Tiny Tiny RSS: Community

SELF_URL_PATH issue with docker-compose-based installation

I’m trying to install Tiny Tiny RSS from the docker-compose image, on a Linux system behind nginx with HTTPS. I’ve cloned the repo https://git.tt-rss.org/fox/ttrss-docker-compose.git , and am running docker-compose up in that repo, with - SELF_URL_PATH=https://my.website/tt-rss/ as the only edit to docker-compose.yaml. I cloned the repo yesterday and the latest commit is 05d341df8946b88eb89a4a4e4ac1125abfe3e55e .

When I run with docker, and access https://my.website, I get the Startup failed error page with the text Please set SELF_URL_PATH to the correct value detected for your server: https://my.website/tt-rss/. This is of course what my SELF_URL_PATH is already set to, so I’m not sure why I’m having problems with this configuration.

My nginx site configuration file looks like:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name my.website;

    root /srv/http;
    error_page 404 /custom_404.html;

    location /tt-rss/ {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;

    ssl_certificate /etc/letsencrypt/live/my.website/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/my.website/privkey.pem; # managed by Certbot


currently, config.php is only generated once, if it doesn’t exist.

if you ran into this error and then updated the compose file, you’ll need to either delete generated config.php on the persistent storage volume (or delete entire volume and start from scratch with correct environment) or update SELF_URL_PATH in config.php manually.

e: ideas welcome on how to deal with this better. regenerating config.php all the time seems like a bad idea.

Yeah I must’ve had some old state left in one of the volumes from before I edited the compose file. I deleted all the volumes and let docker-compose recreate them, and it seems to have worked. I’m not particularly experienced with docker-volumes so I didn’t think about state remaining in those. It might help just to have a README or FAQ entry suggesting to try blowing the volumes away and recreating in this sort of case.

yep, i’ll make a note to add this to README, since it’s not particularly obvious.