I’m pretty sure they are actually hosting it. The tech is quite different (cofractal uses urls ending with {z}/{x}/{y}
, while their tile sever uses this stuff that works quite differently)
I’m pretty sure they are actually hosting it. The tech is quite different (cofractal uses urls ending with {z}/{x}/{y}
, while their tile sever uses this stuff that works quite differently)
They told me about hosting their own tile server earlier today. I’m really impressed by how fast they moved !
A pull request for a privacy page during the onboarding is in the works, and I’ve been working with them to update the settings page and documentation (with the goal of providing an easy way to switch map providers). They are also working on a privacy policy, and want to ship all of this in a few weeks as part of a single release.
Once again, I’m really impressed with how well they’re handling this
Is named
actually running as the bind
user inside the container ? Maybe a USER bind
line below the RUN
lines will help.
I’ll probably look into newer fancier options such as Caddy one day, but as far as I remember Nginx has never failed me : it’s stable, battle tested, and extremely mature. I can’t remember a single time when I’ve been affected by a breaking change (I could not even find one by searching changelogs) and the feature set makes it very versatile. Newer alternatives seem really interesting, but it seems to me they have quite frequent breaking changes and are not as feature rich.
That being said, I’d love to see side-by-side comparison of Nginx and Caddy configs (if anyone wants to translate to Caddy the Nginx caching proxy for OSM I shared earlier this week, that would make a good and useful example), as well as examples of features missing from Nginx. This may give me enough motivation to actually try Caddy :)
(edit : ad->and)
I don’t use nginx-proxy-manager, but if you want to share what you tried, I will try to help you figure what’s not working
It’s the clients (web/android app, probably iOS too) that are making these requests.
To the best of my knowledge, the Immich server inside the container is not making requests to the outside. It is merely sending a style.json
to the client displaying a map, which then fetches tiles from the Cofractal URL inside this JSON.
Or you can quite easily configure nginx as your personal caching proxy with an arbitrarily long TTL/retention duration (you can check out my follow-up post for instructions on doing that)
I used to wonder what kind of nerd notices this kind of thing, now I’m one of them
Edit : If you want to join us :
I don’t use Traefik myself, but this documentation page seems to suggest that Traefik only allows in-memory cache (which would eat RAM and not persist across reboots). You can probably run Nginx with this config inside a container for the caching, then use Traefik to handle requests to immich.your-domain.tld/map_proxy/*
with the caching proxy container.
What do you mean ? Can you give me the exact link that’s not working ?
At this point, I’ll just assume you are trolling and stop replying after this comment.
This post is trying to provide a generic solution to the fact that there are no reasonable way to get map tiles without relying on a third party provider.
I additionally included instructions on how to set it up with Immich, but I don’t see how a caching proxy in front of OSM should be part of Immich, a software focused on managing photo libraries.
How does an nginx config fit as a “diff” when the Immich repo and docker images do not include nginx (or any other reverse proxy) ?
Blocking the DNS was the first thing I did. This is intended to restore the map feature without having to trust a random company I’ve never heard of.
What do you mean by “a diff of a code fix” that would be simpler ?
You can, but you would not be able to display the map. Might as well disable the map server-wide
Not yet, but I will probably submit a PR to include this guide in the docs
I’ll try clarifying what I had in mind :
I tried running maptiler to generate tiles from OSM’s data, which required an insane amount of time and resources (not doable for most self-hosters including myself, even for a single country) to process the data and store the results. I was wondering if there would be a way to ask maptiler (or another equivalent tool) to only generate tiles that contain points from a given set (in this case, photos) and maybe the tiles adjacent to them. What about doing this for every zoom level ? This would require generating at most zoom_levels * n_photos
(* 9
) if we include adjacent) tiles, and a lot less for the typical person taking several photos at the same place.
Thanks for sharing your experience and for the links.
Do you think it would be doable to make/host a tileserver that only generates the first few zoom levels for the whole planet by default, and is able to generate tiles for more detailed zoom levels only for specific locations ? I’m thinking of a feature where Immich asks the tile server to generate the appropriate tiles based on the locations of photos. Since we only ever zoom on locations where photos have been taken, and we often take several photos at the same locations, could this decrease the requirements enough for self-hosting ?
No need to be rude…
Thanks for the detailed feedback. According to one Immich dev, they used to use OSM’s raster tile provider but switched away from it since they were causing too much load on OSM’s servers.
There does not seem to be any non-commercial vector-tile provider at the moment (though OSM seems to be currently working on it), and it seems really overkill to try and self-host a tile provider (at least with the default level of details). Maybe the way is to find a balanced level of details that makes it reasonable to self host
I can recommend some stuff I’ve been using myself :
I design, deploy and maintain such infrastructures for my own customers, so feel free to DM me with more details about your business if you need help with this