Update, December 2025: This article has been revised to reflect the recent changes to the Tesla Fleet API and current Teslamate versions.

Modern vehicles now offer API interfaces that let you pull all kinds of data. Tesla was one of the first manufacturers to expose this comprehensively, and software like Teslamate grew out of that. Teslamate is a self-hosted, open-source data logger that continuously captures your Tesla’s data, stores it, and visualizes it with Grafana.

What changed in 2025?

The key updates at a glance:

Tesla Fleet API: Tesla replaced the unofficial “Owner API” with the official Fleet API. Since February 2025, a pay-per-use model applies, with a $10/month free allowance. For private users with 1-2 vehicles, that allowance is usually enough; heavier usage adds roughly $2-5/month.

PostgreSQL 17: Teslamate now requires at least PostgreSQL 16.7 or 17.3. The developers recommend PostgreSQL 17.

Fleet Telemetry: New is the option for the vehicle to stream data directly. This is more precise and cheaper than classic polling, but more complex to set up. Fleet Telemetry requires your own server endpoint and TLS certificates — the vehicle then streams data via WebSocket whenever values change. That saves on API costs since you no longer have to poll actively, and you get high-frequency data with minimal latency, especially while driving. For most users, though, the tried-and-tested polling approach still works fine and is considerably easier to set up.

Teslamate – Install It Yourself, or Pay for a Service?

Teslamate isn’t a software-as-a-service — you install and run it yourself. Whether that’s on your home homelab or on a VPS in the cloud, e.g. withNetcup (external link) , both work fine. I host it on my own server on my home network.

Installation is straightforward withDocker . You need a database (PostgreSQL) and the application container. For visualization, Teslamate relies on Grafana with pre-configured dashboards.

Prerequisites

Hardware & software:

• A server with at least 2 GB RAM (Raspberry Pi 4/5, NAS, VPS)
• Docker and Docker Compose installed
• A permanently active internet connection

Tesla account:

• Tesla account with two-factor authentication
• A Tesla Developer account (free atdeveloper.tesla.com (external link) )

Setting Up a Tesla Developer Account

Since the switch to the Fleet API, you’ll need a developer account:

1. Sign in atdeveloper.tesla.com (external link) with your Tesla account
2. Create a new application (e.g. “Teslamate Homelab”)
3. Provide a short description
4. For local use, you can use localhost as the domain

Review takes a few days; for private use, approval is usually straightforward. The monthly $10 allowance is real credit — you don’t need to add a credit card as long as you stay under it.

Creating Tokens

Authentication used to work with your username and password. Today you need a “Refresh Token” and an “Access Token.” The easiest way to generate these is with dedicated apps:

• iOS: “Auth for Tesla” (Apple App Store)
• Android: “Tesla Tokens” or “Auth for Tesla”
• Windows/Mac: “Tesla Auth” or web-based tools

Steps:

1. Install the app and sign in with your Tesla username
2. Enter your password
3. At the second prompt, enter your 2FA code (not your password again!)
4. The app shows a Refresh Token and Access Token — keep both somewhere safe

The tokens stay valid for several months. Teslamate refreshes the access token automatically.

Installation with Docker Compose

The easiest way to install Teslamate is via Docker Compose. If you don’t already have Docker Compose installed:

# On Ubuntu/Debiansudo apt install docker-compose-plugindocker compose version

Create a working directory:

mkdir ~/teslamate&& cd ~/teslamate

I’ll point you to theofficial documentation (external link) here, since the configuration changes fairly regularly.

Important adjustments for 2025:

version:"3"services:teslamate:image:teslamate/teslamate:latestrestart:alwaysenvironment:-ENCRYPTION_KEY=your_secure_key-DATABASE_USER=teslamate-DATABASE_PASS=secure_password-DATABASE_NAME=teslamate-DATABASE_HOST=database-TZ=Europe/Berlin# Your timezone!-MQTT_DISABLE=true# If you don't need MQTTports:-4000:4000cap_drop:-alldatabase:image:postgres:17# At least 16.7 or 17.3!restart:alwaysenvironment:-POSTGRES_USER=teslamate-POSTGRES_PASSWORD=secure_password-POSTGRES_DB=teslamatevolumes:-teslamate-db:/var/lib/postgresql/datagrafana:image:teslamate/grafana:latestrestart:alwaysenvironment:-DATABASE_USER=teslamate-DATABASE_PASS=secure_password-DATABASE_NAME=teslamate-DATABASE_HOST=databaseports:-3000:3000volumes:-teslamate-grafana-data:/var/lib/grafanavolumes:teslamate-db:teslamate-grafana-data:

MQTT for Home Assistant:

If you want to forward the data to an MQTT server (e.g. forHome Assistant ), replaceMQTT_DISABLE=true withMQTT_HOST=mosquitto and add a Mosquitto container.

Start the containers:

docker compose up -d

Teslamate is then reachable athttp://{your-server-ip}:4000. On first launch, enter the tokens you generated earlier. After 1-2 minutes (waking the vehicle via the app may help), you should start seeing data.

Analysis with Grafana

A big advantage of the pre-built Docker Compose file: Grafana is included out of the box, reachable by default athttp://{your-server-ip}:3000.

Default login (change immediately!):

• Username:admin
• Password:admin

Grafana already has the PostgreSQL database configured as a data source, and all dashboards are pre-imported. If you’re running your own separate Grafana instance, you’ll need to import the JSON files manually from theGitHub (external link) repository.

Key dashboards:

• Overview: an overall summary of all metrics — the perfect starting point
• Drives: trip analysis with interactive maps, showing route, speed, and consumption
• Charges: detailed charging history with cost analysis per charge, and comparisons between charging stations
• Battery Health: long-term battery capacity trends, showing degradation over time and mileage
• Efficiency: consumption analysis by speed, temperature, and elevation — see what’s actually affecting your range
• Vampire Drain: standby consumption while parked, useful for spotting phantom drain
• Locations: frequently visited places, with automatic geofencing detection
• Updates: a history of every software update, with timestamps

Long-term Use and Insights

The real value shows up after several months. Here are some concrete examples from my own usage:

Battery degradation: my Model Y showed about 4% capacity loss after 50,000 km. 3-5% in the first 50,000 km is typical, and degradation slows noticeably afterward. With Teslamate you can see the exact trend and spot outliers (e.g. from BMS calibration).

Seasonal differences: in winter (around 0°C), my consumption sits at roughly 20-22 kWh/100km; in summer it’s 15-17 kWh/100km — about 30% more due to heating and a cold battery. That data is genuinely useful for route planning.

Cost optimization: home charging (€0.30/kWh) vs. Supercharger (€0.52/kWh) — the difference adds up. At 15,000 km a year, I save roughly €400 annually by charging at home. Even better:charging with solar surplus brings the cost down to about €0.08/kWh.

Efficiency: surprisingly, my optimal speed range turned out to be 90-110 km/h, not 70 km/h as I expected. Below 70 km/h, relative consumption creeps back up slightly due to auxiliary systems.

Troubleshooting

Teslamate shows “offline” instead of “asleep”: That’s expected behavior since Tesla firmware 2024.8+ — Tesla changed the API response, it’s not a Teslamate bug.

Token isn’t accepted: Use the Refresh Token (the longer of the two strings), not the Access Token.

No data: Check the Docker logs withdocker compose logs teslamate. Common causes: the vehicle is in deep sleep, wrong timezone, or network issues.

High API costs: Reduce the polling frequency, switch to Fleet Telemetry, or check for unnecessary wake commands.

Security and Backup

Network:

• Don’t expose it directly to the internet
• Use a reverse proxy with HTTPS (Nginx, Caddy, Traefik)
• Enable firewall rules

Backup:

docker compose exec database pg_dump -U teslamate teslamate > backup.sql

Updates:

docker compose pulldocker compose up -d

Frequently Asked Questions

Does Teslamate cost money? The software itself is free. Tesla API costs apply, but are usually covered by the $10 free allowance. Only heavy usage adds roughly $2-5/month.

Does it work with the new Fleet API? Yes, fully compatible and kept up to date.

Does it drain the battery? No, the additional consumption is negligible.

Can I track multiple vehicles? Yes, each one is logged separately.

Conclusion

For me, Teslamate is the best solution for in-depth vehicle data analysis. The upsides:

• Full data ownership through self-hosting
• Detailed analysis with Grafana
• Low cost thanks to the free API allowance
• An active community
• Great fit for Home Assistant integration

The downsides: it requires technical know-how, your own server, and there’s no official support.

For Tesla owners with a smart-home or homelab streak, Teslamate is an excellent piece of software. After a few months of use, the analytics get genuinely interesting, once trends and long-term patterns start to show. Even while driving, the Grafana dashboards surface plenty of interesting data.

Tips for Advanced Users

Reverse proxy setup: For secure access on the go, I’d recommend a reverse proxy with a Let’s Encrypt SSL certificate. Traefik or Caddy fully automate the process.

Database optimization: On very old installations, a manual vacuum of the database can help:

docker compose exec database vacuumdb -U teslamate -d teslamate -z -v

Custom dashboards: Grafana offers endless possibilities. You could, for example, build comparisons with other Tesla drivers, or visualize correlations between weather and consumption.

Further reading:

• Teslamate Documentation (external link)
• GitHub Repository (external link)
• Community Forum (external link)

If you’ve read myprevious post on my 2025 homelab setup , you know I’ve been usingKomodo (external link) as my GitOps tool for Docker Compose stacks. The concept is solid: Git as a single source of truth, Renovate for automated version updates, and Komodo deploying changes to the target system on every new commit. It mostly works – but Komodo has been driving me up the wall with one thing: file permissions. It simply doesn’t work consistently. Either the permissions on the host are off, or Komodo complains during deployment, or something in between. After the nth time dealing with it, I’d had enough and wanted something leaner.

The requirement is straightforward: when Renovate pushes a new commit to the repo (after I merge the pull request), the compose file on the server should be updated and the affected containers restarted. No Kubernetes, no additional framework. Just git pull and docker compose up.

The Basic Concept

The setup relies on three components working together:

1. Gitea (external link) – my self-hosted Git server where the compose files live
2. Renovate (external link) – checks the image tags in the compose files against the respective container registries every four hours via cronjob, and automatically opens pull requests when newer versions are available. I merge the PR, the commit lands onmain.
3. webhook (external link) – a single Go binary that exposes an HTTP endpoint on the target server. Gitea fires a webhook on every push, which triggers the deploy script.

The data flow looks like this:

Renovate detects new image tag
→ PR in Gitea
→ Merge
→ Gitea fires webhook
→ webhook binary calls deploy.sh
→ git pull + docker compose up -d

No polling, no daemon watching container registries, no framework with its own opinions about file permissions.

Why Not Just Watchtower or a Cron Script?

Before reaching for webhook, I briefly considered two other approaches.

Watchtower (external link) monitors running containers and pulls new images automatically. The problem: Watchtower reacts to new images in the registry, not to Git commits. When Renovate opens a PR and I merge it, Watchtower has no idea – it just pulls whenever it decides to check. That doesn’t fit a setup where Git is supposed to be the single source of truth. I also want to control the merge timing, not Watchtower.

A cron script withgit fetch would be the other option – check for changes every few minutes and deploy if there are any. It works, but has a conceptual drawback: it’s polling. I already have Gitea infrastructure that can deliver push events, so I should use it. A webhook reacts within seconds; a cron job with a 5-minute interval adds unnecessary delay.

webhook is the cleanest approach: event-driven, no extra daemon, a single binary with no dependencies.

Repo Structure

I have one repository per server:

• apps-stack fordocker01 – running tools likePaperless-ngx (external link) ,Immich (external link) ,Vaultwarden (external link) , and similar
• media-stack formedia01 – all the*arr containers and everything else in the media stack

Each repo just contains thecompose.yaml and any additional config files individual applications need. Nothing special.

Renovate in the Repos

Renovate runs self-hosted and checks the image tags in the compose files every four hours via cronjob. A minimalrenovate.json in the repo root is all it takes:

{"$schema":"https://docs.renovatebot.com/renovate-schema.json","extends": ["config:base"],"docker-compose": {"enabled":true }}

Renovate automatically detects image tags in the compose file and opens PRs when a newer version is available. For software that uses semantic versioning (major.minor.patch), this can be fine-tuned – for example, automatically merging patch updates while reviewing minor updates manually.

I exclude Postgres containers from Renovate. Major upgrades between Postgres versions require a manual database dump and restore – not something I want a bot to trigger automatically.

Installing and Configuring webhook

webhook is available as a single binary, or as a package:

apt install webhook

The configuration lives at/etc/webhook/webhook.conf:

-id:deployexecute-command:/opt/scripts/deploy.shcommand-working-directory:/opt/media-stacktrigger-rule:match:type:payload-hmac-sha256secret:"{{getenv \"WEBHOOK_SECRET\"}}"parameter:source:headername:X-Gitea-Signature

A few notes on this:

Header name: Gitea sends the signature asX-Gitea-Signature – without a-256 suffix and without asha256= prefix in the value. Sounds trivial, but it cost me a debugging session on the first try.

Secret as environment variable: The HMAC secret doesn’t belong in the config file in plaintext, especially if the file is versioned in the repo. So it’s read from the environment viagetenv.

Generate the secret:

openssl rand -hex32

Write it to a secrets file that only root can read:

# /etc/webhook/secrets.envWEBHOOK_SECRET=your-generated-string

chmod600 /etc/webhook/secrets.env

Systemd Unit

# /etc/systemd/system/webhook.service[Unit]Description=Webhook ReceiverAfter=network.target[Service]User=teqqy # Replace with your own usernameEnvironmentFile=/etc/webhook/secrets.envExecStart=/usr/bin/webhook -hooks /etc/webhook/webhook.conf -port 9000Restart=on-failure[Install]WantedBy=multi-user.target

User=teqqy ensures the webhook daemon and the deploy script don’t run as root. That’s important to me – processes that only need to run git pull and docker compose up have no business running as root. Replace the username with your own; the user needs access to the repo directory and must be a member of thedocker group.

EnvironmentFile loadssecrets.env and makesWEBHOOK_SECRET available as an environment variable before the process starts – so the secret flows cleanly into thegetenv call in the config.Restart=on-failure ensures the daemon automatically restarts after an unexpected crash without manual intervention.

systemctl enable --now webhook

Setting Up the Gitea Webhook

In Gitea underRepository → Settings → Webhooks → Add Webhook → Gitea:

• Target URL:http://media01.example.com:9000/hooks/deploy
• Secret: the same string you generated above
• Trigger: OnlyPush events are needed

On every push, Gitea automatically computes an HMAC-SHA256 signature over the request body and sends it as theX-Gitea-Signature header. The webhook binary verifies the signature before executing the script – a simple Authorization header would be significantly less secure since it doesn’t protect the payload against tampering.

Port 9000 shouldn’t be exposed directly to the internet. In my setup, Gitea and the webhook daemon are on the same internal network and the port isn’t reachable from outside. Anyone who needs to expose the endpoint for an external Gitea instance or GitHub should at minimum put it behind a reverse proxy with IP restrictions.

The Deploy Script

#!/bin/bashset -euo pipefailREPO=/opt/media-stackLOG=/opt/deploy-logs/deploy-$(date +%Y%m%d-%H%M%S).logexec >>"$LOG" 2>&1echo"=== Deploy$(date) ==="cd"$REPO"git pull origin maindocker compose up -d --remove-orphansdocker compose psecho"=== Done ==="

set -euo pipefail ensures the script immediately aborts on any error and returns a non-zero exit code. webhook logs that as well, sojournalctl -u webhook is the first place to look when something goes wrong.

The log directory needs to be owned by the executing user:

mkdir -p /opt/deploy-logschown teqqy:teqqy /opt/deploy-logs

Pitfalls I Hit Along the Way

.git directory ownership: If the repo was ever cloned or pulled as a different user, Git refuses access with a warning about “dubious ownership”. Fix:

chown -R teqqy:teqqy /opt/media-stack/.git

safe.directory: In some setups this helps additionally:

git config --global --add safe.directory /opt/media-stack

/var/log permissions: The executing user doesn’t have write access there. Put the log directory somewhere the user owns – I use/opt/deploy-logs.

*arr containers and UID/GID: My*arr containers run as99:100 (Unraid-compatible for NFS reasons). On the very first deployment, Docker creates bind mount directories with1000:1000 if they don’t exist yet. One-time fix before the first start:

chown -R 99:100 /mnt/data/arr/

After that it’s a non-issue since the directories already exist.

Monitoring

I useUptime Kuma (external link) to check whether containers are still running cleanly after a deployment. That’s enough for my use case: if a container stops responding after a failed update, Uptime Kuma alerts me. The deploy log andjournalctl -u webhook then provide the details on what went wrong.

A dead man’s switch (e.g. via Healthchecks.io) would be the next sensible step if you also want to be notified when a deploy simplydoesn’t happen – but for a media stack that’s not critical enough for me to add the overhead.

Conclusion

The setup has been running for a little while now and does exactly what it’s supposed to – without me having to debug anything in Komodo. The webhook binary is stable, the deployment flow is deterministic, and the total overhead is a handful of config files and a shell script.

For anyone with similar requirements who doesn’t want to run Kubernetes: this is, in my opinion, the most pragmatic approach. No magic, no frameworks, no overengineering. Just git pull and docker compose up.

If you have questions or feedback, reach me through the links in the menu bar.