TeslaMate: a self-hosted Tesla logger that keeps your car data in your own Postgres

What TeslaMate logs that the Tesla app forgets

The Tesla mobile app shows current state. It does not keep a decade of drive records you can query. TeslaMate exists to fill that gap: it is a self-hosted data logger that records high precision drive data, charge sessions, battery health and vehicle states, and stores them in a Postgres database you control. The README lists the intended outputs: drive stats, charge cost tracking, projected range as a proxy for battery degradation, vampire drain, and a lifetime driving map built from OpenStreetMap data and SRTM elevation tiles.

The audience is narrow but specific. You need a Tesla account, a machine that stays on, and enough patience to run Postgres and Grafana. In exchange you get raw rows rather than a vendor's summary screen, plus MQTT publishing so Home Assistant, Node-RED or Telegram can react to events. The README also notes import from TeslaFi and tesla-apiscraper, which matters if you are migrating an existing history rather than starting from zero.

Elixir, Postgres and Grafana: how the pieces fit

The stack is visible in the repository layout. The application is Elixir, built with mix and released as an OTP release inside a Docker image. The Dockerfile is a two stage build: an elixir:1.20.2-otp-29 builder compiles dependencies, runs npm ci in assets/ and mix assets.deploy for the Phoenix front end, then copies the compiled release into a debian:trixie-slim runtime image that installs libodbc2, libsctp1, libssl3t64, libstdc++6, netcat-openbsd, tini and tzdata.

The data flow is one directional. A background process polls the Tesla API, normalizes positions, states and charge readings, and writes them to Postgres. Grafana reads that same database and renders the dashboards shipped in grafana/dashboards, which the Dockerfile copies into the image. Vehicle data is also published to a local MQTT broker, so the database is not the only consumer. The README states the design goal of no additional vampire drain: the car should fall asleep as soon as possible, which means polling is deliberately conservative rather than continuous.

That architecture has a consequence worth naming. Grafana is not optional in practice. The bundled dashboards are how you actually read the data, so a broken Grafana datasource looks like a broken TeslaMate even when logging continues normally.

Installing TeslaMate with Docker and a first drive

The README points to https://docs.teslamate.org for the documentation, and the repository ships a Dockerfile plus a Makefile with a teslamate target that builds the image. The canonical path is the documented Docker Compose setup, which the README does not reproduce. What the Makefile does show is how a local image is tagged:

make teslamate

That target runs docker build with the pull flag and tags the result as teslamate:<version>-<short sha> and also as teslamate. The version comes from the VERSION file and the build identifier from git rev-parse --short HEAD. If you would rather pull a published image, the README links to the Docker Hub repository teslamate/teslamate.

Grafana is built separately, from its own directory:

make grafana

This runs docker build inside grafana/ and tags the image teslamate-grafana. Two images, two containers, one Postgres database behind them.

Configuration is environment driven. The runtime image sets SRTM_CACHE=/opt/app/.srtm_cache and HOME=/opt/app, and the repository carries a .envrc and an entrypoint.sh, so credentials and database settings are expected to arrive as environment variables rather than in a checked-in config file. The documentation at docs.teslamate.org is where the required variables and the Compose file live; the README itself does not enumerate them. After the containers start, the first real use is letting the car sit, then opening the web interface and the Overview dashboard to confirm that states and a first drive appear. If nothing appears, the API token is the first thing to check, not the dashboards.

Where TeslaMate is the wrong tool

TeslaMate is not a hosted service and does not pretend to be one. There is no official mobile app: the README explicitly warns that unofficial apps, including ones on the App Store, have used the TeslaMate name to distribute modified or harmful versions, and that using them puts your Tesla account credentials and vehicle data at risk. If you want an app you install from a store and never think about again, this project is the wrong shape.

The second limitation is operational. You are running Postgres, a Phoenix application and Grafana. Upgrades move the database schema forward, and the README does not document a rollback procedure for migrations. A home server that loses power mid-upgrade is your problem, not the maintainers'. The repository does provide a flake.nix, so Nix users have a reproducible path, but that does not remove the need for backups.

The third is scope. TeslaMate logs what the Tesla API exposes. It is not a diagnostic tool for the vehicle's internal bus, and it is not a fleet management platform. If you need raw CAN data or multi-driver billing, look elsewhere.

TeslaMate compared with TeslaFi and Tessie

The obvious alternatives are the hosted loggers. TeslaFi and Tessie both keep your data on their servers and give you a browser or app interface without any infrastructure. The difference is not features, it is custody. With TeslaMate the Postgres database sits on your hardware, the dashboards run in your Grafana, and MQTT events go to your broker. The README's import feature for TeslaFi and tesla-apiscraper exists precisely because people move between these models in both directions.

The trade is real in both directions. Hosted services handle token refresh, uptime and upgrades for you, and they can push a fix without you redeploying. TeslaMate gives you the schema, so you can write SQL against your own trips, join charge data with your electricity tariff, or feed Home Assistant over MQTT. It also means you own the failure. A crashed Postgres container is not a support ticket, it is your evening.

A fair summary: choose TeslaMate if you want the raw data and already run a server. Choose a hosted logger if you want the answer without the plumbing.

Licence, upgrades and what AGPL-3.0 means here

TeslaMate is licensed under the GNU Affero General Public License v3.0. The README spells out the practical consequences rather than leaving them to the LICENSE file: if you modify the project and distribute it, or offer its functionality over a network as a service, you must release your modified source under the same licence. Closed-source commercial products built on TeslaMate or its components are not permitted, and the README states that software interacting with or relying on TeslaMate must be open source. Attribution requires keeping the original copyright notices.

The name is governed separately. A TRADEMARK.md file sets out the trademark policy, and CONTRIBUTING references a Contributor License Agreement handled through cla-assistant.io on a first pull request. If you plan to fork and ship something, read both files before you pick a name.

On maintenance: the last push to the default branch was on 2026-09-09, and the most recent release listed is v4.2.0 from 2026-08-23. The repository is not archived. Upgrade cost is mostly yours: you rebuild or pull new images, restart the containers, and let the migrations run against your Postgres. Nothing in the README describes a downgrade path, so a database snapshot before an upgrade is the only rollback you actually have.

Editorial conclusion

Adopt TeslaMate if you already run Docker or a Nix flake on a home server, want your trip history in Postgres, and are comfortable with the AGPL-3.0 copyleft terms. Do not adopt it if you want a hosted mobile app or are unwilling to keep a server patched, since the README warns that unofficial apps and forks have been used to distribute modified versions. Before committing, verify that your Tesla account can still issue API tokens for third-party clients, that your host has enough disk for Postgres plus the SRTM cache under SRTM_CACHE, and that you have a backup path for the database, because the README does not document a rollback for schema migrations.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. teslamate-org/teslamate on GitHub