Migrating a Zapier or Make automation to a new geocoding host
No-code automations built on a geocoding step need a different migration approach than custom code does. Here is how to handle that switch.
Self-hosting Nominatim vs using a hosted drop-in
Self-hosting Nominatim is a legitimate, well-documented path, and plenty of organizations run it successfully, particularly ones with strong reasons to keep geocoding infrastructure entirely within their own network. But the tradeoff is real and worth stating plainly rather than glossing over: you take on downloading and importing an OpenStreetMap data extract, provisioning enough disk space and memory to serve queries at acceptable speed, keeping that data reasonably current as OpenStreetMap itself updates, and operating the server with whatever uptime guarantees your application needs.
None of that is difficult in the sense of being obscure or undocumented. It is difficult in the sense of being ongoing. A self-hosted Nominatim instance that worked well on the day it launched can degrade in relevance a year later if nobody has scheduled the update process, and diagnosing why a specific address stopped matching correctly means understanding both the Nominatim software and the underlying OpenStreetMap data conventions.
A hosted drop-in replacement removes that operational layer entirely, at the cost of putting your geocoding traffic through a third party's infrastructure instead of your own, which is the actual decision being made here, not a question of one option being simply better.
My Geocode's Nominatim compatibility host reproduces the exact response structure a self-hosted or public Nominatim instance returns, display_name, lat and lon as strings, and an address object using OpenStreetMap's own field naming like suburb and postcode, with only the copyright, terms, and privacy text differing. Reference details are at /compatibility/nominatim/. Code written against a self-hosted instance should need only a host and authentication change, since the field structure carries over.
Some questions worth answering honestly before choosing either path:
- Does your organization have a specific compliance or data residency reason that self-hosting satisfies and a hosted service would not
- How much engineering time is currently spent maintaining the self-hosted instance, and what would that time be worth spent elsewhere
- Is your traffic volume high and steady enough that infrastructure costs are already justified, or does it fluctuate in a way that a predictable per-request or subscription cost handles more cleanly
If the answer points toward moving off self-hosted infrastructure, authentication on the hosted side uses a key sent as X-API-Key, Authorization: Bearer, HTTP Basic auth, or a query parameter, replacing the User-Agent-based usage policy a public Nominatim instance expects. Pricing includes 2,500 free requests a day with no key, 2,500 more free per key per day counted per network, then prepaid credit at €0.0001 per request or an Unlimited key at €50 a month, the same rate as every other endpoint on the platform. For many teams, running the numbers on server costs, engineering maintenance time, and request volume against this pricing is the fastest way to settle the question either way.