Use relative paths rather than absolute / Support mulitple base URLs or domains #1099

New Issue

OVERLORD · 2026-02-04T23:45:19+03:00

OVERLORD commented

2026-02-04 23:45:19 +03:00

Originally created by @Amolith on GitHub (Mar 20, 2019).

Describe the bug
It would be better to use relative paths than absolute. This issue is different from #1137 because I'm saying that everything should be relative rather than hardcoded. I'm trying to serve my BookStack instance over Tor and, even though it's served fine over the initial onion URL, every single link on the first page is to the clearnet site. I can manually enter the path to the onion URL and it works fine so it's simply an issue of hardcoded URLs vs relative.

Steps To Reproduce

Open Tor
Paste wiki.l4qlywnpwqsluw65ts7md3khrivpirse744un3x7mlskqauz5pyuzgqd.onion
Mouse over some of the links and see the target URL
Paste wiki.l4qlywnpwqsluw65ts7md3khrivpirse744un3x7mlskqauz5pyuzgqd.onion/books/masto-tweaks/
See that it works fine but all the links on that page are hardcoded as well

Expected behavior

Links from the onion URL go to an onion URL
Links from a clearnet URL go to a clearnet URL

Screenshots

Your Configuration (please complete the following information):

Exact BookStack Version (Found in settings): v0.25.1
PHP Version: 7.3.3
NGINX

Originally created by @Amolith on GitHub (Mar 20, 2019). **Describe the bug** It would be better to use relative paths than absolute. This issue is different from #1137 because I'm saying that *everything* should be relative rather than hardcoded. I'm trying to serve my BookStack instance over Tor and, even though it's served fine over the initial onion URL, every single link on the first page is to the clearnet site. I can manually enter the path to the onion URL and it works fine so it's simply an issue of hardcoded URLs vs relative. **Steps To Reproduce** 1. Open Tor 2. Paste [wiki.l4qlywnpwqsluw65ts7md3khrivpirse744un3x7mlskqauz5pyuzgqd.onion](http://wiki.l4qlywnpwqsluw65ts7md3khrivpirse744un3x7mlskqauz5pyuzgqd.onion) 3. Mouse over some of the links and see the target URL 4. Paste [wiki.l4qlywnpwqsluw65ts7md3khrivpirse744un3x7mlskqauz5pyuzgqd.onion/books/masto-tweaks/](http://wiki.l4qlywnpwqsluw65ts7md3khrivpirse744un3x7mlskqauz5pyuzgqd.onion/books/masto-tweaks/) 5. See that it works fine but all the links on *that* page are hardcoded as well **Expected behavior** - Links from the onion URL go to an onion URL - Links from a clearnet URL go to a clearnet URL **Screenshots** ![image](https://user-images.githubusercontent.com/29460675/54650603-bd630600-4a85-11e9-9bd9-bbc3fa1213d8.png) **Your Configuration (please complete the following information):** - Exact BookStack Version (Found in settings): v0.25.1 - PHP Version: 7.3.3 - NGINX

OVERLORD added the 🔨 Feature Request 🏭 Back-End 💻 Front-End labels 2026-02-04 23:45:19 +03:00

OVERLORD commented

2026-02-04 23:45:26 +03:00

@ssddanbrown commented on GitHub (Mar 20, 2019):

Thanks for the request.

This is related to #1310 and #1275 and #1137

@ssddanbrown commented on GitHub (Mar 20, 2019): Thanks for the request. This is related to #1310 and #1275 and #1137

OVERLORD commented

2026-02-04 23:45:36 +03:00

@recklessnl commented on GitHub (Aug 28, 2019):

@ssddanbrown Has there been any progress on this issue yet? Still really annoying not being able to access local data on a local server if your internet goes out, without restarting the whole bookstack instance and messing with the local config files.

@recklessnl commented on GitHub (Aug 28, 2019): @ssddanbrown Has there been any progress on this issue yet? Still really annoying not being able to access local data on a local server if your internet goes out, without restarting the whole bookstack instance and messing with the local config files.

OVERLORD commented

2026-02-04 23:45:41 +03:00

@AlphaJack commented on GitHub (Sep 10, 2019):

So far BookStack is the only app in my selfhosted server that I can't access from my LAN IP. To access I'm forced to:

use the public IP with Tor Browser, because APP_URL=https://example.com/wiki
modify the .env file setting APP_URL=http:/192.168.1.13/wiki, making the app inaccessible from the outside
It would be great to set APP_URL=/wiki/ to get it working on both the external and the internal IPs, but if I set so it redirects me to http:/192.168.1.13/wiki/wiki/wiki or https://example.com/wiki/wiki/wiki

@AlphaJack commented on GitHub (Sep 10, 2019): So far BookStack is the only app in my selfhosted server that I can't access from my LAN IP. To access I'm forced to: - use the public IP with Tor Browser, because APP_URL=https://example.com/wiki - modify the .env file setting APP_URL=http:/192.168.1.13/wiki, making the app inaccessible from the outside It would be great to set APP_URL=/wiki/ to get it working on both the external and the internal IPs, but if I set so it redirects me to http:/192.168.1.13/wiki/wiki/wiki or https://example.com/wiki/wiki/wiki

OVERLORD commented

2026-02-04 23:45:46 +03:00

@recklessnl commented on GitHub (Sep 10, 2019):

Same here - Bookstack is only app that is not modern enough to be able to handle this.
Ideally you could just reverse proxy it without messing with APP_URL settings and just let it live locally in order to work with a reverse proxy. Every other app I have tested work fine with a reverse proxy, except this one.

@recklessnl commented on GitHub (Sep 10, 2019): Same here - Bookstack is only app that is not modern enough to be able to handle this. Ideally you could just reverse proxy it without messing with APP_URL settings and just let it live locally in order to work with a reverse proxy. Every other app I have tested work fine with a reverse proxy, except this one.

OVERLORD commented

2026-02-04 23:45:50 +03:00

@AlphaJack commented on GitHub (Sep 21, 2019):

I thought I got it working by setting

APP_URL=.

in the .env file.
URL would look like

href="./dist/styles.css?version=v0.27.4"
src="./logo.png"
action="./search"

and will resolve for every host, being it a LAN IP or a registered domain.
The point is, it only works for
/wiki/ (my location)
/wiki/shelves
/wiki/books
/wiki/register
/wiki/login (it works)

Going to /wiki/books/bookname or /wiki/user/n° will result in errors regarding the javascript files

I decided to try this after seeing that all the URLs in the "relative-urls" branch of IrosTheBeggar/mStream were starting with a dot (only this branch makes mStream also work in /locations/ and not only subdomains. )

@AlphaJack commented on GitHub (Sep 21, 2019): I thought I got it working by setting ``` APP_URL=. ``` in the `.env` file. URL would look like ``` href="./dist/styles.css?version=v0.27.4" src="./logo.png" action="./search" ``` and will resolve for every host, being it a LAN IP or a registered domain. The point is, it only works for /wiki/ (my location) /wiki/shelves /wiki/books /wiki/register /wiki/login (it works) Going to /wiki/books/bookname or /wiki/user/n° will result in errors regarding the javascript files --- I decided to try this after seeing that all the URLs in the ["relative-urls" branch of IrosTheBeggar/mStream](https://github.com/IrosTheBeggar/mStream/tree/relative-urls) were starting with a dot (only this branch makes mStream also work in /locations/ and not only subdomains. )

OVERLORD commented

2026-02-04 23:45:52 +03:00

@recklessnl commented on GitHub (Jan 31, 2020):

So is the above workaround by @AlphaJack suffice or is an actual fix coming for this @ssddanbrown? It's odd that bookstack still doesn't support both local IPs and domain names, I can't think of another selfhosted app that doesn't support it other than bookstack.

@recklessnl commented on GitHub (Jan 31, 2020): So is the above workaround by @AlphaJack suffice or is an actual fix coming for this @ssddanbrown? It's odd that bookstack still doesn't support both local IPs and domain names, I can't think of another selfhosted app that doesn't support it other than bookstack.

OVERLORD commented

2026-02-04 23:45:57 +03:00

@recklessnl commented on GitHub (Feb 28, 2020):

pinging @ssddanbrown - major feature request that hopefully is already in the works.

@recklessnl commented on GitHub (Feb 28, 2020): pinging @ssddanbrown - major feature request that hopefully is already in the works.

OVERLORD commented

2026-02-04 23:46:01 +03:00

@ssddanbrown commented on GitHub (Feb 29, 2020):

The way I see it: The actual goal/feature being request here is "Have the ability to host a single BookStack instance at multiple base URLs". Relative paths is just an implementation idea for that feature/goal.

I've found myself grow further against the idea of having relative or dynamic URLs due to the edge-cases or complexities they'd introduce. I'd be happy to explore other potential avenues depending on their level of interruption relative to the rest of the codebase & their maintenance cost.

I've just spent a few hours seeing if this can be done via nginx. You can achieve almost fully-functional support by setting up a proxy for the secondary base URL, leading to the primary, which uses sub_filter and proxy_redirect to rewrite the urls for the most part. Unfortunately there are content issues when updating page content, since the POST body won't be re-written. Probably possible but quickly gets complicated due to body encoding and regex, tried but gave up on that route. Here's an example config I used, might be useful if your secondary base domain can be a read-only setup:

(My primary domain was http://bookstack.local and the secondary was http://bookstack.local:88 )

server {
	listen 88;
	server_name bookstack.local;

	location / {
     	  sub_filter_once off;
	  sub_filter_types *;
	  sub_filter "http://bookstack.local" "http://bookstack.local:88";
	  proxy_redirect http://bookstack.local http://bookstack.local:88;
	  proxy_pass http://bookstack.local;
	}

}

@recklessnl For your specific setup, if you're intending to access that local instance from a single computer, you could just fix the DNS record to point locally. Alternatively, if you self-host/manage the DNS for local network you could add a rule there.

@ssddanbrown commented on GitHub (Feb 29, 2020): The way I see it: The actual goal/feature being request here is "Have the ability to host a single BookStack instance at multiple base URLs". Relative paths is just an implementation idea for that feature/goal. I've found myself grow further against the idea of having relative or dynamic URLs due to the edge-cases or complexities they'd introduce. I'd be happy to explore other potential avenues depending on their level of interruption relative to the rest of the codebase & their maintenance cost. I've just spent a few hours seeing if this can be done via nginx. You can achieve almost fully-functional support by setting up a proxy for the secondary base URL, leading to the primary, which uses `sub_filter` and `proxy_redirect` to rewrite the urls for the most part. Unfortunately there are content issues when updating page content, since the POST body won't be re-written. Probably possible but quickly gets complicated due to body encoding and regex, tried but gave up on that route. Here's an example config I used, might be useful if your secondary base domain can be a read-only setup: (My primary domain was `http://bookstack.local` and the secondary was `http://bookstack.local:88` ) ```nginx server { listen 88; server_name bookstack.local; location / { sub_filter_once off; sub_filter_types *; sub_filter "http://bookstack.local" "http://bookstack.local:88"; proxy_redirect http://bookstack.local http://bookstack.local:88; proxy_pass http://bookstack.local; } } ``` --- @recklessnl For your specific setup, if you're intending to access that local instance from a single computer, you could just fix the DNS record to point locally. Alternatively, if you self-host/manage the DNS for local network you could add a rule there.

OVERLORD commented

2026-02-04 23:46:04 +03:00

@disconsented commented on GitHub (Jun 22, 2020):

I've found myself grow further against the idea of having relative or dynamic URLs due to the edge-cases or complexities they'd introduce.

Would you be able to give some examples of this? I was under the impression that relative URLs are generally safe and are considered best practice.

@disconsented commented on GitHub (Jun 22, 2020): > I've found myself grow further against the idea of having relative or dynamic URLs due to the edge-cases or complexities they'd introduce. Would you be able to give some examples of this? I was under the impression that relative URLs are generally safe and are considered best practice.

OVERLORD commented

2026-02-04 23:46:07 +03:00

@Deicid commented on GitHub (Sep 22, 2021):

I have the exact same problem. I'm surprised the developer couldn't fix it in two years.
It's the best product I've seen, but it's very hard to use without local access.

@Deicid commented on GitHub (Sep 22, 2021): I have the exact same problem. I'm surprised the developer couldn't fix it in two years. It's the best product I've seen, but it's very hard to use without local access.

OVERLORD commented

2026-02-04 23:46:09 +03:00

@gagnieremaxime commented on GitHub (Sep 29, 2021):

Hi, i had the same problem but i fixed it by running the bookstack container 2 times while connecting to the same db and the same config directory. Here is my docker-compose.yml file:

---
version: "2"
services:
  bookstack:
    image: ghcr.io/linuxserver/bookstack
    container_name: bookstack
    environment:
      - PUID=1000
      - PGID=1000
      - APP_URL=http://192.168.2.99:6876
      - DB_HOST=bookstack_db
      - DB_USER=bookstack
      - DB_PASS=<dbPassword>
      - DB_DATABASE=bookstackapp
    volumes:
      - /home/<username>/docker/apps/bookstack/config:/config
    ports:
      - 6876:80
    restart: unless-stopped
    depends_on:
      - bookstack_db
  bookstack_remote:
    image: ghcr.io/linuxserver/bookstack
    container_name: bookstack_remote
    environment:
      - PUID=1000
      - PGID=1000
      - APP_URL=https://bookstack.mydomain.com
      - DB_HOST=bookstack_db
      - DB_USER=bookstack
      - DB_PASS=<dbPassword>
      - DB_DATABASE=bookstackapp
    volumes:
      - /home/<username>/docker/apps/bookstack/config:/config
    ports:
      - 6875:80
    restart: unless-stopped
    depends_on:
      - bookstack_db

  bookstack_db:
    image: ghcr.io/linuxserver/mariadb
    container_name: bookstack_db
    environment:
      - PUID=1000
      - PGID=1000
      - MYSQL_ROOT_PASSWORD=<dbPassword>
      - TZ=America/Toronto
      - MYSQL_DATABASE=bookstackapp
      - MYSQL_USER=bookstack
      - MYSQL_PASSWORD=<dbPassword>
    volumes:
      - /home/<username>/docker/apps/bookstack/db/config:/config
    restart: unless-stopped

@gagnieremaxime commented on GitHub (Sep 29, 2021): Hi, i had the same problem but i fixed it by running the bookstack container 2 times while connecting to the same db and the same config directory. Here is my docker-compose.yml file: ``` --- version: "2" services: bookstack: image: ghcr.io/linuxserver/bookstack container_name: bookstack environment: - PUID=1000 - PGID=1000 - APP_URL=http://192.168.2.99:6876 - DB_HOST=bookstack_db - DB_USER=bookstack - DB_PASS=<dbPassword> - DB_DATABASE=bookstackapp volumes: - /home/<username>/docker/apps/bookstack/config:/config ports: - 6876:80 restart: unless-stopped depends_on: - bookstack_db bookstack_remote: image: ghcr.io/linuxserver/bookstack container_name: bookstack_remote environment: - PUID=1000 - PGID=1000 - APP_URL=https://bookstack.mydomain.com - DB_HOST=bookstack_db - DB_USER=bookstack - DB_PASS=<dbPassword> - DB_DATABASE=bookstackapp volumes: - /home/<username>/docker/apps/bookstack/config:/config ports: - 6875:80 restart: unless-stopped depends_on: - bookstack_db bookstack_db: image: ghcr.io/linuxserver/mariadb container_name: bookstack_db environment: - PUID=1000 - PGID=1000 - MYSQL_ROOT_PASSWORD=<dbPassword> - TZ=America/Toronto - MYSQL_DATABASE=bookstackapp - MYSQL_USER=bookstack - MYSQL_PASSWORD=<dbPassword> volumes: - /home/<username>/docker/apps/bookstack/db/config:/config restart: unless-stopped ```

OVERLORD commented

2026-02-04 23:46:13 +03:00

@Deicid commented on GitHub (Sep 29, 2021):

@gagnieremaxime Thank you for your message!
I set up a connection of two instances to the same database and I had problems with the pictures, their paths are broken. And the images downloaded from the local copy of Bookstack were not displayed in the external access (public version).
I don't know how this can be overcome

@Deicid commented on GitHub (Sep 29, 2021): @gagnieremaxime Thank you for your message! I set up a connection of two instances to the same database and I had problems with the pictures, their paths are broken. And the images downloaded from the local copy of Bookstack were not displayed in the external access (public version). I don't know how this can be overcome

OVERLORD commented

2026-02-04 23:46:16 +03:00

@gagnieremaxime commented on GitHub (Sep 29, 2021):

@Deicid it seems to work for me, could you show me your docker-compose.yml file?

@gagnieremaxime commented on GitHub (Sep 29, 2021): @Deicid it seems to work for me, could you show me your docker-compose.yml file?

OVERLORD commented

2026-02-04 23:46:19 +03:00

@ssddanbrown commented on GitHub (Sep 29, 2021):

Just to confirm @gagnieremaxime, @Deicid is correct that there will be issues with content; At least where one URL cannot be accessed when using the other. It could work for some cases (Where one host is used read-only and has access to the other) but for most cases you'll end up with a mix of URLs used in content.

@ssddanbrown commented on GitHub (Sep 29, 2021): Just to confirm @gagnieremaxime, @Deicid is correct that there will be issues with content; At least where one URL cannot be accessed when using the other. It could work for some cases (Where one host is used read-only and has access to the other) but for most cases you'll end up with a mix of URLs used in content.

OVERLORD commented

2026-02-04 23:46:26 +03:00

@gagnieremaxime commented on GitHub (Sep 29, 2021):

@ssddanbrown I had that happen on my first try, but right now I can access bookstack both at my domain and the local IP. Both can connect and upload images.

@gagnieremaxime commented on GitHub (Sep 29, 2021): @ssddanbrown I had that happen on my first try, but right now I can access bookstack both at my domain and the local IP. Both can connect and upload images.

OVERLORD commented

2026-02-04 23:46:29 +03:00

@ssddanbrown commented on GitHub (Sep 29, 2021):

@gagnieremaxime Sure, but it's not a matter of container configuration; It's a matter of networking. It's not a solution for everyone (An image upload & use via local only IP address will likely break upon page view from outside the local network).

@ssddanbrown commented on GitHub (Sep 29, 2021): @gagnieremaxime Sure, but it's not a matter of container configuration; It's a matter of networking. It's not a solution for everyone (An image upload & use via local only IP address will likely break upon page view from outside the local network).

OVERLORD commented

2026-02-04 23:46:32 +03:00

@gagnieremaxime commented on GitHub (Sep 29, 2021):

@ssddanbrown You are right, I was looking at the books background to verify if upload was working, but in the page itself uploading an image kind of break it... Thank you for explaining

@gagnieremaxime commented on GitHub (Sep 29, 2021): @ssddanbrown You are right, I was looking at the books background to verify if upload was working, but in the page itself uploading an image kind of break it... Thank you for explaining

OVERLORD commented

2026-02-04 23:46:34 +03:00

@jorfigfl commented on GitHub (May 13, 2022):

Hi! any update about this? We have the same issue, We have an internal domain for internal users (bookstack.domain1.com), and we are looking for an external url(bookname.domain2.net or domain2.net/doc/) to display the public documents only. Exist any solution or workaround?

@jorfigfl commented on GitHub (May 13, 2022): Hi! any update about this? We have the same issue, We have an internal domain for internal users (bookstack.domain1.com), and we are looking for an external url(bookname.domain2.net or domain2.net/doc/<bookname>) to display the public documents only. Exist any solution or workaround?

OVERLORD commented

2026-02-04 23:46:38 +03:00

@ssddanbrown commented on GitHub (May 13, 2022):

@jorfigfl No update, BookStack still only supports a being hosted on a single domain. You could look to use the export functions and/or API to create an external site from your public content.

@ssddanbrown commented on GitHub (May 13, 2022): @jorfigfl No update, BookStack still only supports a being hosted on a single domain. You could look to use the export functions and/or API to create an external site from your public content.

OVERLORD commented

2026-02-04 23:46:46 +03:00

@disconsented commented on GitHub (May 16, 2022):

For anyone who's handy with SQL, you can work around this by rewriting the URLs in the database to remove the domain.

@disconsented commented on GitHub (May 16, 2022): For anyone who's handy with SQL, you can work around this by rewriting the URLs in the database to remove the domain.

OVERLORD commented

2026-02-04 23:46:53 +03:00

@reytechsam commented on GitHub (Jun 8, 2022):

anyone who's handy with SQL, you can work around this by rewriting the URLs in the database to remove the domain.

Would this work if we rewrite all the database url's? Has someone tried this before?
We have the same issue unfortunately.

@reytechsam commented on GitHub (Jun 8, 2022): > anyone who's handy with SQL, you can work around this by rewriting the URLs in the database to remove the domain. Would this work if we rewrite all the database url's? Has someone tried this before? We have the same issue unfortunately.

OVERLORD commented

2026-02-04 23:46:56 +03:00

@reytechsam commented on GitHub (Jun 8, 2022):

Okay, I think we got it working for our case:
Just edited nano /var/www/wiki/app/Config/app.php

and replaced this line :
'url' => env('APP_URL', '') === 'http://bookstack.dev' ? '' : env('APP_URL', ''),

with this one:
'url' => "https://" . $_SERVER['SERVER_NAME'] . "/wiki",

Note, it will brake with the next update, so keep a wiki with all your changes you made

@reytechsam commented on GitHub (Jun 8, 2022): > Okay, I think we got it working for our case: Just edited nano /var/www/wiki/app/Config/app.php and replaced this line : 'url' => env('APP_URL', '') === 'http://bookstack.dev' ? '' : env('APP_URL', ''), with this one: 'url' => "https://" . $_SERVER['SERVER_NAME'] . "/wiki", Note, it will brake with the next update, so keep a wiki with all your changes you made

OVERLORD commented

2026-02-04 23:47:01 +03:00

@ssddanbrown commented on GitHub (Jun 8, 2022):

Just to confirm, the above methods are not supported and can cause issues during updates.
My comment here applies to the above, in that this will falter in scenarios where the URLs have different availability/access conditions.
In addition, the APP_URL is used in more locations than just one file.

@ssddanbrown commented on GitHub (Jun 8, 2022): Just to confirm, the above methods are not supported and can cause issues during updates. My [comment here](https://github.com/BookStackApp/BookStack/issues/1342#issuecomment-930162217) applies to the above, in that this will falter in scenarios where the URLs have different availability/access conditions. In addition, the `APP_URL` is used in more locations than just one file.

OVERLORD commented

2026-02-04 23:47:06 +03:00

@ani-6 commented on GitHub (Feb 13, 2024):

Any update on this issue?

@ani-6 commented on GitHub (Feb 13, 2024): Any update on this issue?

OVERLORD commented

2026-02-04 23:47:09 +03:00

@sunnyzhong812 commented on GitHub (May 28, 2024):

If used Apache, can refer to the following information.

https://www.liquidweb.com/kb/configure-apache-virtual-hosts-ubuntu-18-04/

@sunnyzhong812 commented on GitHub (May 28, 2024): If used Apache, can refer to the following information. https://www.liquidweb.com/kb/configure-apache-virtual-hosts-ubuntu-18-04/

OVERLORD commented

2026-02-04 23:47:11 +03:00

@Stefansen commented on GitHub (Jun 28, 2024):

Any update on this issue?

@Stefansen commented on GitHub (Jun 28, 2024): Any update on this issue?

OVERLORD commented

2026-02-04 23:47:16 +03:00

@jdrusso commented on GitHub (Dec 11, 2024):

checking in 5 years later, still relevant and would still be great to get this

I need to expose services both on a local domain and a public-facing domain

@jdrusso commented on GitHub (Dec 11, 2024): checking in 5 years later, still relevant and would still be great to get this I need to expose services both on a local domain and a public-facing domain

OVERLORD commented

2026-02-04 23:47:18 +03:00

@LordWiseRus commented on GitHub (Jan 26, 2025):

Hi! We need this feature. Please add it.

@LordWiseRus commented on GitHub (Jan 26, 2025): Hi! We need this feature. Please add it.

OVERLORD commented

2026-02-04 23:47:21 +03:00

@alexisfrjp commented on GitHub (Mar 20, 2025):

It's just crazy how this was decided per design from the beginning. It goes against all the best practices of any website.
First report was in 2017, 8years later, changing the domain name or IP still breaks the whole database.

@alexisfrjp commented on GitHub (Mar 20, 2025): It's just crazy how this was decided per design from the beginning. It goes against all the best practices of any website. First report was in 2017, 8years later, changing the domain name or IP still breaks the whole database.

OVERLORD commented

2026-02-04 23:47:23 +03:00

@ssddanbrown commented on GitHub (Mar 20, 2025):

@alexisfrjp To confirm, for changes (non-simultaneous use/switching) there's a helper command which will update all relevant URL references in the database: https://www.bookstackapp.com/docs/admin/commands/#update-system-url

@ssddanbrown commented on GitHub (Mar 20, 2025): @alexisfrjp To confirm, for changes (non-simultaneous use/switching) there's a helper command which will update all relevant URL references in the database: https://www.bookstackapp.com/docs/admin/commands/#update-system-url

OVERLORD commented

2026-02-04 23:47:25 +03:00

@alexisfrjp commented on GitHub (Mar 20, 2025):

@alexisfrjp To confirm, for changes (non-simultaneous use/switching) there's a helper command which will update all relevant URL references in the database: https://www.bookstackapp.com/docs/admin/commands/#update-system-url

Thanks, doesn't solve the public/private accesses but I'm reassured I can still access my data if I change.

@alexisfrjp commented on GitHub (Mar 20, 2025): > [@alexisfrjp](https://github.com/alexisfrjp) To confirm, for changes (non-simultaneous use/switching) there's a helper command which will update all relevant URL references in the database: https://www.bookstackapp.com/docs/admin/commands/#update-system-url Thanks, doesn't solve the public/private accesses but I'm reassured I can still access my data if I change.

OVERLORD commented

2026-02-04 23:47:28 +03:00

@scvnc commented on GitHub (Mar 21, 2025):

Firstly, thank you for maintaining this software. The design decision to bake in APP_URL isn't terribly odd, but does get tricky for managing more than one valid access url. Tor is certainly one use case.

"Have the ability to host a single BookStack instance at multiple base URLs," seems to be the core of it, I agree. In my testing, it seems like the APP_URL is written to the database for media content which is largely one of the issues. At a glance there may be some cookie/security things to address as well.

Perhaps there is nginx lua script that will do a string replace on the body of responses, replacing APP_URL with the accepted Tor host APP_URL equivalent. Either that or somewhere else in the stack. If that seems possible, I'm interested in hacking at it sometime.

@scvnc commented on GitHub (Mar 21, 2025): Firstly, thank you for maintaining this software. The design decision to bake in APP_URL isn't terribly odd, but does get tricky for managing more than one valid access url. Tor is certainly one use case. "Have the ability to host a single BookStack instance at multiple base URLs," seems to be the core of it, I agree. In my testing, it seems like the APP_URL is written to the database for media content which is largely one of the issues. At a glance there may be some cookie/security things to address as well. Perhaps there is nginx lua script that will do a string replace on the body of responses, replacing APP_URL with the accepted Tor host APP_URL equivalent. Either that or somewhere else in the stack. If that seems possible, I'm interested in hacking at it sometime.

OVERLORD commented

2026-02-04 23:47:31 +03:00

@OptimusGREEN commented on GitHub (Dec 15, 2025):

Im suddenly in need of a second url, Is this being worked on?

@OptimusGREEN commented on GitHub (Dec 15, 2025): Im suddenly in need of a second url, Is this being worked on?

OVERLORD commented

2026-02-04 23:47:33 +03:00

@ssddanbrown commented on GitHub (Jan 20, 2026):

Just to confirm, this is not something being worked on at all.

A Reddit comment made me realise I've never really expanded upon my thoughts in this main thread, like I have elsewhere at times. So reposting here to provide a little context:

Originally this was a decision made very early to ease implementation with the editor. Using absolute URLs help completely avoid a bunch of more complex scenarios, especially around proxy and sub-path-hosting environments.

Since then, it's actually become quite useful, since it provides a base string to search upon. This allows a range of things like accurately mass updating of the URL (and/or sub-path), or easily identification of internal links for tracking internal references, and for transforming content in exports/imports. It also means the links are technically valid when pulled out to different contexts (exports, API usage etc...).

I appreciate that from a developer point of view that it might seem non-optimal, especially if wanting to host via multiple origin names, but when I weigh up the trade-offs that's quite a minor use-case/benefit relative to the advantages I've come to appreciate from absolute URLs.

@ssddanbrown commented on GitHub (Jan 20, 2026): Just to confirm, this is not something being worked on at all. A [Reddit comment](https://www.reddit.com/r/selfhosted/comments/1qhintk/comment/o0lt1u1/) made me realise I've never really expanded upon my thoughts in this main thread, like I have elsewhere at times. So reposting here to provide a little context: --- Originally this was a decision made very early to ease implementation with the editor. Using absolute URLs help completely avoid a bunch of more complex scenarios, especially around proxy and sub-path-hosting environments. Since then, it's actually become quite useful, since it provides a base string to search upon. This allows a range of things like accurately mass updating of the URL (and/or sub-path), or easily identification of internal links for tracking internal references, and for transforming content in exports/imports. It also means the links are technically valid when pulled out to different contexts (exports, API usage etc...). I appreciate that from a developer point of view that it might seem non-optimal, especially if wanting to host via multiple origin names, but when I weigh up the trade-offs that's quite a minor use-case/benefit relative to the advantages I've come to appreciate from absolute URLs.

OVERLORD commented

2026-02-04 23:47:35 +03:00

@disconsented commented on GitHub (Jan 20, 2026):

~~Look ma I'm on the telly~~

Appreciate the response, glad that it's just a simple oversight.

That said, it may be prudent to mark this as not planned and close the issue.

@disconsented commented on GitHub (Jan 20, 2026): ~~Look ma I'm on the telly~~ Appreciate the response, glad that it's just a simple oversight. That said, it may be prudent to mark this as not planned and close the issue.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#1099