Assets served by nginx and "static_path(@conn, "/images/something.jpg")"

When assets are served by Phoenix, I can resolve their paths by “static_path(@conn, “/images/something.jpg”)”
What if I switch to nginx and make it serve those assets? They’ll be placed in a folder external to my Phoenix app.

How then will I be able to resolve their paths from my app using “static_path(@conn, “/images/something.jpg”)” function?

You can match requests to the /images/ folder with the specific folder on the file system http://nginx.org/en/docs/http/ngx_http_core_module.html#location

How then will I be able to resolve their paths from my app using “static_path(@conn, “/images/something.jpg”)” function? In my phoenix app

My nginx is already setup to serve them.

I use it just like that: <%= static_path(@conn, "/images/Logo_crushed.png") %>

My Nginx is pointed to serve assets in the project’s priv/static folder, but it could be any folder really.

If you have a very custom setup, you may need to configure :static_url for your endpoint with some value. Can’t help with that though, never tried it.

1 Like

But after deploy the folder “priv/static” is gone. On localhost – yes, but on production, after compilation… How does it work in your case?

How do you deploy? AFAIK even releases have a priv/static folder in them. Personally I don’t use releases yet, I just compile (code and frontend assets) on the target system and then mix phx.digest. My priv/static folder doesn’t disappear anywhere.

It’ll be in lib/myapp-1.0.0/priv/static for releases.

1 Like

Ok. Then I’ll have to reconfigure nginx each time I make a new release with a new version?

I’d rather look into distillery tasks, which could create an symlink to an folder which doesn’t have the version in it.

1 Like

I usually have a symlink called current pointing to the latest release, which is updated as part of the deploy process. This way you can configure your nginx to use the symlink to traverse to the priv folder.

2 Likes

is there such a task?

It also seems possible to reconfigure where Plug.Static looks for content:

diff --git a/lib/hello_static_web/endpoint.ex b/lib/hello_static_web/endpoint.ex
index 2b13357..f034319 100644
--- a/lib/hello_static_web/endpoint.ex
+++ b/lib/hello_static_web/endpoint.ex
@@ -8,7 +8,7 @@ defmodule HelloStaticWeb.Endpoint do
   # You should set gzip to true if you are running phoenix.digest
   # when deploying your static files in production.
   plug Plug.Static,
-    at: "/", from: :hello_static, gzip: false,
+    at: "/", from: "/tmp/hello_static", gzip: false,
     only: ~w(css fonts images js favicon.ico robots.txt)
 
   # Code reloading can be explicitly enabled under the

However, you’ll still need to deploy any changes to static assets to the required location of course… In my simple test case, it was just:

cp -rp priv/static /tmp/hello_static

But it’ll naturally be more involved for a proper deployment process. You get that “for free” if you rely on the priv/static directory inside the release, at the cost (as you noticed) of configuring eg. NGINX properly. I’m also not sure at what scale you’ll really benefit from having NGINX serve the content, as opposed to Phoenix.

really???