# Public assets gets weird paths when Zola app is used in Docker container (Fly.io)

**URL:** <https://zola.discourse.group/t/public-assets-gets-weird-paths-when-zola-app-is-used-in-docker-container-fly-io/2283>\
**Category:** Support\
**Created:** [September 8, 2024, 6:56pm UTC](https://zola.discourse.group/t/public-assets-gets-weird-paths-when-zola-app-is-used-in-docker-container-fly-io/2283 "2024-09-08T18:56:26Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![helibom](https://yyz2.discourse-cdn.com/free1/user_avatar/zola.discourse.group/helibom/32/1301_2.png) [@helibom](https://zola.discourse.group/u/helibom)\
**Post date:** [September 8, 2024, 6:56pm UTC](https://zola.discourse.group/t/public-assets-gets-weird-paths-when-zola-app-is-used-in-docker-container-fly-io/2283/1 "2024-09-08T18:56:26Z")

</div>

Hi,

I’ve been getting frustrated all day over an issue I was facing, where the stylesheet I used from the ‘tranquil’ theme was applied correctly when serving the site on the local dev server, but not applied at all when deployed in a container in the cloud ([Fly.io](http://Fly.io)).

I read this forum looking for answers, built the image in my local Docker environment and started to try and debug from there. Confusing thing was that I noticed that the compiled tailwind .css file seemed to be in the correct path inside the container, but still the HTTP request wouldn’t resolve on that path.

After trying a bunch of things, I eventually got the styling to work in my Fly app without really knowing what did it. But then I noticed in the network tab in the browser dev tools that the link to the stylesheets resolved to this adress: `https://helibom-net.fly.dev//styles/styles.css` and the page sources looked like this,  
 ![image](https://global.discourse-cdn.com/free1/uploads/zola1/original/2X/a/a24c1b9b36b34242c9328c6e6e9a15fed6b5fd90.png)

However, upon each refresh of the page I get, seemingly randomly, a different directory structure in the source tab, where the `js` or `img` directory might also be within the nameless directory another level down.

What had happened was that I had accidently gotten things to work when I changed the `base_url` variable in `config_toml` to `https://helibom-net.fly.dev/` instead of `https://helibom-net.fly.dev`.

My current solution is to either set the `base_url` to `https://helibom-net.fly.dev/` or hardcode double forward slashes in the href, like so `<link href="{{ config.base_url }}//styles/styles.css" rel="stylesheet">`. I don’t like neither solution.

So what might be going on here?  
I’m starting to believe it’s the [webserver](https://static-web-server.net/) that is showing some bug, because when I inspect the container on Docker Desktop, the directory structure in `/public` looks rather flat, just like it does on my local machine, without that nameless directory creating an extra in the tree.

Any ideas would be appreciated, thanks!

---

<div class="post-metadata">

**Author:** ![welpo](https://yyz2.discourse-cdn.com/free1/user_avatar/zola.discourse.group/welpo/32/1087_2.png) [@welpo](https://zola.discourse.group/u/welpo)\
**Post date:** [September 13, 2024, 8:52pm UTC](https://zola.discourse.group/t/public-assets-gets-weird-paths-when-zola-app-is-used-in-docker-container-fly-io/2283/2 "2024-09-13T20:52:32Z")

</div>

My guess is it’s an issue with the theme.

This is [how it loads the CSS file](https://github.com/TeaDrinkingProgrammer/tranquil/blob/160b3765c1b1d346e80e857ad4663193f01fc01d/templates/_base.html#L20):

```auto
<link href="{{ config.base_url }}/styles/styles.css" rel="stylesheet">

```

If `base_url` ends with a slash, you’ll get the double slash.

A much more reliable way to get the path to files in Zola is:

```tera
{{ get_url(path="filename.css", cachebust=true) }}

```

(The `cachebust` is not required, but a good idea)

Try updating the theme to remove the line I linked above, and add this instead:

```tera
<link rel="stylesheet" href="{{ get_url(path="styles/styles.css" , cachebust=true) }}">

```

Hope that helps!

---

<div class="post-metadata">

**Author:** ![helibom](https://yyz2.discourse-cdn.com/free1/user_avatar/zola.discourse.group/helibom/32/1301_2.png) [@helibom](https://zola.discourse.group/u/helibom)\
**Post date:** [October 28, 2024, 6:12am UTC](https://zola.discourse.group/t/public-assets-gets-weird-paths-when-zola-app-is-used-in-docker-container-fly-io/2283/3 "2024-10-28T06:12:53Z")

</div>

@welpo I apologize for the late response, life has been busy, took me a while to revisit this. But I really appreciate your reply and attempt at helping me.

I tried your suggestion to load the file path the with that utility function, but unfortunately that didn’t seem to be my solution.

What I discovered was that I must’ve been inconsistent after all when providing the `base_url` property to Zola and `static-web-server`.

A note to any other person trying to troubleshoot a similar thing is this:  
If the `base_url` returned by `{{ config.base_url }}` or `{{ get_url(path) }}` does not have an initial “http://”, then `static-web-server` will interpret any `<link/>` tag with that reference as a relative address and proceed to prepend it with the `base_url` that `static-web-server` uses.  
And watch out, because `sws` looks for a `config.toml` as its config by default, just like Zola.  
You can use the `-w` flag to specify another config file for `sws`.