When I deploy, there’s a period of time where new/old servers are existing with each other. During this time, requests for static assets (served from the server) will not be available because the asset paths mismatch based on the file’s hash.
I have solved this in the past with CDNs and fairly annoying setups involving S3. This works like a charm, but is a lot of moving pieces for a small app right now. So, I’m attempting to find an easier solution.
I was pointed to statics and it seems like the idea is supposed to solve this exact issue. I have setup statics in my fly.toml like so:
guest_path = "/app/lib/super-0.1.0/priv/static"
url_prefix = "/"
When I deploy, I noticed that it’s possible for Fly to miss (in response header). When the request makes it to my app, it doesn’t retrieve the asset for some reason (I haven’t debugged this deeper).
Am I misunderstanding how statics work? I assumed that Fly would pull the files out of my image and deploy them to prod. So new/old live in harmony for some time and everything works without error.
You’ll need to make sure that the dockerfile includes the files you need in its image layer. Check that the dockerfile has COPY or ADD directive that includes the image files you’ll need. Here’s an example of what that looks like:
COPY ./public/ /srv/http/
The Dockerfile has
/app/lib/super-0.1.0/priv/static properly defined with the image files. I verified this by checking the Docker image that’s in fly. For example:
$ ls /app/lib/super-0.1.0/priv/static/assets/app-4be850fefdc915d594a321f237d82d0b.js
There might be an issue with how you’re mapping assets, the url prefix shouldn’t overlap with other static mappings, so it doesn’t support more than one mapping to the same path. In your case, try changing
Also as an aside, each app can only have 10 mappings, if that factors into how you’re using statics
Ah, thanks for this! This kills it for me because I have images, fonts, and other assets that I want to cache.
No worries, sorry it didn’t fit your use case