Telize serves IP geolocation from a RAM-cached MaxMind database

Two endpoints and a RAM-cached MaxMind reader

Telize answers two kinds of question: what is my IP address, and where is this IP address. The implementation is deliberately small. It is a Go program built on chi, described in the README as a lightweight, idiomatic and composable router, and on the MaxMind DB Reader for Go, with the go.mod pinning chi v5.3.1 and maxminddb-golang v2.4.1. The reason the service responds quickly is stated plainly in the description: the reader caches the geolocation database in RAM, so a lookup does not hit the filesystem. The repository layout matches that shape, with country-code3.go, endpoints.go, payload.go, structs.go and utils.go sitting next to the main telize.go entry point, and no database code of its own. The audience is anyone who needs a lookup endpoint for their own infrastructure or a small web property, rather than a full analytics platform with dashboards and retention.

The GeoLite2 City and ASN files have to be supplied by you

Telize does not bundle geolocation data. It requires the free GeoLite2 databases from MaxMind, and it looks for the `GeoLite2 City` and `GeoLite2 ASN` databases in /var/db/GeoIP by default. That is a hard dependency on an external download that is not in the repository, so a fresh install has a gap between running the binary and answering correct answers. It is worth being blunt about what that means: a lookup against a missing or stale database does not return a better answer, it returns whatever the reader has, and the accuracy of the whole service is the accuracy of the files you placed in that directory. The README also mentions that since version 3.0.0 the service dynamically calculates timezone offsets and adds them to the payload, so the response carries a computed UTC offset rather than a stored one.

Building and running it is two go commands and two flags

Installation is handled by the standard Go toolchain, and the README states that all dependencies are fetched and compiled automatically.

	go build
	go install telize

The service binds on localhost, port 8080 by default, and the documented flags are minimal.

	USAGE:
	  -host string
	    	Set the server host (default "127.0.0.1")
	  -port string
	    	Set the server port (default "8080")
	  -version
	    	Display version

So the host flag defaults to 127.0.0.1 and the port to 8080, and there is no configuration file, no environment variable and no database path flag. That narrow flag set is worth noticing. If you want the databases somewhere other than /var/db/GeoIP, or you want TLS, or you want a request log path, the repository does not document a way to set it, and you would be reading the source to find out. In practice most deployments put the binary behind a reverse proxy that terminates TLS and passes the client address on.

JSON and JSONP on the same path, with X-Forwarded-For trust

Each endpoint comes in a plain text flavour and a JSON flavour, and the JSON flavour also supports JSONP callbacks. `/ip` returns the address as plain text. `/jsonip` returns it as JSON, or as JSONP with a callback parameter. `/location` returns the visitor address as JSON, and `/location/46.19.37.108` returns the data for the address in the path rather than the caller. The JSONP form is there for callers on older browsers, and it is a dated choice that is worth noting before you expose it publicly. The proxy handling is the security-relevant part: Telize reads the `X-Forwarded-For` header when it is present and returns data for the first address in the list. That means the result depends entirely on your reverse proxy overwriting or stripping that header, since a client that can inject its own X-Forwarded-For decides what address gets geolocated.

Wildcard CORS, HTTP 400 on bad input, and no authentication

CORS is enabled by default with the policy `Access-Control-Allow-Origin: *`, so any page in any browser can call the endpoint. That is convenient for a public lookup page and wrong for anything internal, since it means the service is callable from arbitrary origins. There is no authentication described for any endpoint, and no rate limiting in the documented behaviour, so the service should sit behind your own proxy rather than be exposed directly. Input handling is simple: incorrect user input returns an HTTP 400 Bad Request with a JSON-encoded error message, and the README lists code 401 for an input string that is not a valid IP address, which is a body code rather than an HTTP status. The client errors are therefore predictable, but the surface for abuse by anyone who can reach the port is wide open by default.

A systemd unit ships in the repository for boot time startup

Running the service at boot is handled with a systemd unit file that is bundled with the source rather than left to the operator. The README points to `systemd/telize.service` and says to copy it into /etc/systemd/system along with the binary in /usr/local/sbin.

	systemctl enable telize

That single command is the documented way to launch the daemon at startup, and it means the packaging problem is already solved for the common Linux case. What the README does not cover is a container workflow: there is no Dockerfile in the repository, unlike a service that treats containers as a first class deployment target. The rest of the documentation points outward, with the project site holding the complete API documentation and usage examples, and the ChangeLog and TODO files in the repository root carrying the history. The site, not the readme, is the reference for the full set of endpoints.

A slow release trail against a recent commit

The maintenance picture for Telize is mixed and worth reading carefully. The last push was on 2026-07-09, which shows work is still landing on the default branch. The tagged releases are much older: 3.1.1 from 2022-04-27, 3.1.0 from 2021-03-29 and 3.0.1 from 2021-01-01. So the code is being changed while the release tags have not moved in a long time, and the README even points at a tarball for 3.1.1 as the latest one. Anyone pinning a version should note that a tagged release is likely older than the working tree, and anyone building from source will not get a version tag that matches the checkout. The licence is BSD 2-Clause, a permissive licence with no copyleft obligation, and the project is developed by Frederic Cambus.

Editorial conclusion

Telize fits operators who want a tiny self-hosted endpoint for their own visitor IP and geolocation lookups, without paying a per-request fee to a hosted geolocation service, and it suits anyone already running the MaxMind GeoLite2 databases. It does not fit a product that needs city-level accuracy on paid traffic, because Telize depends on the free GeoLite2 databases and their coverage limits, and it is a poor fit for a multi-tenant analytics platform since the CORS policy is a wildcard and there is no authentication in the documented endpoints. Before deploying it, place the GeoLite2 City and GeoLite2 ASN files in /var/db/GeoIP, run it behind a reverse proxy so the client address arrives in X-Forwarded-For, and check the systemd/telize.service unit shipped in the repository. The last push was on 2026-07-09, and the latest tagged release is 3.1.1 from 2022.

Frequently asked questions

Official sources

1. fcambus/telize on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases