Tesla Vehicle Command on Unraid with evcc

Tesla’s Vehicle Command SDK includes an HTTPS proxy that signs vehicle commands. I deployed the official Docker image on Unraid for use with evcc and a Tesla Wall Connector Gen 3.

The difficult part was not starting Docker: it was connecting the application registration, account permissions, and vehicle key in the correct order.

Verification status: The proxy is running, its HTTPS certificate validates, Tesla’s API returns my vehicle, and the virtual key has been enrolled. The evcc certificate mapping and final charging-command test are follow-up steps below, not verified outcomes of this setup session.

What is needed

• Unraid with Docker and the Compose Manager plugin.
• evcc running on the same Unraid server using host networking.
• A Tesla developer application and access to the vehicle-owner account.
• A public HTTPS domain for hosting the application’s public key.
• The Tesla mobile app, signed in as the vehicle owner.

This setup uses Tesla’s Internet-based Fleet API, not Bluetooth. Self-hosting the proxy does not bypass Tesla’s API billing or quotas.

1. Create the Tesla developer application

Create an application in the Tesla developer dashboard. Save its Client ID and Client Secret privately.

For charging-only evcc use, enable:

The authorization request also includes openid and offline_access so the client can maintain access with refresh tokens. Broader Vehicle Commands and Vehicle Location permissions are not needed for this charging-only setup.

I used myTeslaMate’s OAuth callback to display the authorization code, while hosting my own command-signing key:

The callback and key-hosting domain serve different purposes. The blog does not implement an OAuth callback. If using a different OAuth client, use its actual registered callback instead.

2. Store configuration on Unraid’s appdata share

Run the following commands in the Unraid terminal. The official image runs as UID/GID 65532.

1
mkdir -p /mnt/user/appdata/tesla-vehicle-command/config
2
chown 65532:65532 /mnt/user/appdata/tesla-vehicle-command/config
3
chmod 700 /mnt/user/appdata/tesla-vehicle-command/config

Do not keep the keys in a relative ./config directory under the Compose Manager project on /boot. On this server, /boot is FAT with root-only permissions. The container failed with:

1
Error: open /config/fleet-key.pem: permission denied

An absolute appdata bind mount avoids that filesystem-permission problem.

3. Generate separate signing and HTTPS keys

The signing key authenticates commands to the vehicle. The TLS key secures the proxy connection. They must be different keys.

Run once, before any key has been enrolled. Do not overwrite existing keys when repeating the setup.

1
(
2
set -eu
3
umask 077
4
cd /mnt/user/appdata/tesla-vehicle-command/config
5
for file in fleet-key.pem public-key.pem tls-key.pem tls-cert.pem; do
6
  if [ -e "$file" ]; then
7
    echo "STOP: $file already exists; preserve the existing keys."
8
    exit 1
9
  fi
10
done
11

12
openssl ecparam -name prime256v1 -genkey -noout -out fleet-key.pem
13
openssl pkey -in fleet-key.pem -pubout -out public-key.pem
14

15
openssl req -x509 -nodes -newkey ec \
16
  -pkeyopt ec_paramgen_curve:secp384r1 \
17
  -subj '/CN=unraid' \
18
  -keyout tls-key.pem -out tls-cert.pem -sha256 -days 825 \
19
  -addext 'subjectAltName=DNS:unraid,DNS:localhost,IP:127.0.0.1' \
20
  -addext 'extendedKeyUsage=serverAuth' \
21
  -addext 'keyUsage=digitalSignature'
22

23
chown 65532:65532 fleet-key.pem public-key.pem tls-key.pem tls-cert.pem
24
chmod 600 fleet-key.pem tls-key.pem
25
chmod 644 public-key.pem tls-cert.pem
26
)

Back up the keys securely. Replacing the signing key requires enrolling the new public key in the vehicle.

4. Configure and start the Docker proxy

In Compose Manager, create a Tesla Vehicle Command project using:

1
services:
2
  tesla_http_proxy:
3
    image: tesla/vehicle-command:latest
4
    restart: unless-stopped
5
    ports:
6
      - "127.0.0.1:4443:4443"
7
    environment:
8
      TESLA_HTTP_PROXY_TLS_CERT: /config/tls-cert.pem
9
      TESLA_HTTP_PROXY_TLS_KEY: /config/tls-key.pem
10
      TESLA_HTTP_PROXY_HOST: 0.0.0.0
11
      TESLA_HTTP_PROXY_PORT: "4443"
12
      TESLA_HTTP_PROXY_TIMEOUT: 10s
13
      TESLA_KEY_FILE: /config/fleet-key.pem
14
      TESLA_VERBOSE: "false"
15
    security_opt:
16
      - no-new-privileges:true
17
    volumes:
18
      - /mnt/user/appdata/tesla-vehicle-command/config:/config:ro

Use Compose Up, then test from Unraid:

1
curl --cacert /mnt/user/appdata/tesla-vehicle-command/config/tls-cert.pem \
2
  https://127.0.0.1:4443/api/1/vehicles

Without an OAuth token, the expected result is HTTP 403 with client did not provide an OAuth token. This verifies the HTTPS listener, not vehicle access.

Only loopback is published. Do not expose port 4443 through a router or Cloudflare Tunnel. evcc can reach it because it uses host networking on the same server. A bridge-networked or remote evcc instance needs a different, secured network arrangement.

5. Publish only the public key

Display or copy this file:

1
cat /mnt/user/appdata/tesla-vehicle-command/config/public-key.pem

Host its raw PEM contents at this exact path on your domain:

1
https://YOUR_DOMAIN/.well-known/appspecific/com.tesla.3p.public-key.pem

For my Astro blog, the source file is public/.well-known/appspecific/com.tesla.3p.public-key.pem, published at:

1
https://dvkwong.com/.well-known/appspecific/com.tesla.3p.public-key.pem

Cloudflare or any HTTPS static host can serve it. The response must be the public key, not HTML, a login page, or a bot challenge. Keep the URL available after enrollment.

Never publish fleet-key.pem, tls-key.pem, OAuth tokens, or the client secret.

6. Store OAuth application credentials privately

These credentials are used for token requests, not placed in the proxy’s environment.

1
umask 077
2
mkdir -p /mnt/user/appdata/tesla-vehicle-command/oauth
3
chmod 700 /mnt/user/appdata/tesla-vehicle-command/oauth
4
nano /mnt/user/appdata/tesla-vehicle-command/oauth/client.json

Enter your own values:

1
{
2
  "client_id": "YOUR_CLIENT_ID",
3
  "client_secret": "YOUR_CLIENT_SECRET"
4
}

This directory is outside the proxy’s mounted configuration. Do not commit it to Git or share its contents.

7. Register the public-key domain with Tesla

Publishing the key and adding Allowed Origins do not perform Fleet API partner registration.

The following requests a temporary partner token and registers the domain directly with Tesla. It uses the NA Fleet API endpoint, which was confirmed as the correct region for my New Zealand account. Other accounts should use the appropriate regional endpoint.

Change domain before running this on another installation:

1
(
2
set -eu
3
umask 077
4
cd /mnt/user/appdata/tesla-vehicle-command/oauth
5
domain=dvkwong.com
6
api=https://fleet-api.prd.na.vn.cloud.tesla.com
7
work=$(mktemp -d)
8
trap 'rm -rf "$work"' EXIT
9

10
jq -rj --arg audience "$api" \
11
  '{grant_type:"client_credentials",client_id,client_secret,
12
    scope:"openid vehicle_device_data vehicle_charging_cmds",
13
    audience:$audience}
14
   | to_entries | map((.key|@uri)+"="+(.value|@uri)) | join("&")' \
15
  client.json > "$work/request"
16

17
curl --fail-with-body --silent --show-error --max-time 45 \
18
  -H 'Content-Type: application/x-www-form-urlencoded' \
19
  --data-binary @"$work/request" \
20
  https://fleet-auth.prd.vn.cloud.tesla.com/oauth2/v3/token \
21
  -o "$work/token"
22

23
jq -er '"Authorization: Bearer " + (.access_token | select(length > 0))' \
24
  "$work/token" > "$work/header"
25
jq -n --arg domain "$domain" '{domain:$domain}' > "$work/registration"
26

27
curl --fail-with-body --silent --show-error --max-time 45 \
28
  -H @"$work/header" -H 'Content-Type: application/json' \
29
  --data-binary @"$work/registration" \
30
  "$api/api/1/partner_accounts" -o "$work/result"
31
jq '{response,error,error_description}' "$work/result"
32
)

Successful registration returned HTTP 200 with domain: dvkwong.com. The published public key was also checked against the proxy’s private key.

Use jq -rj, not just jq -r, when creating the form body: a trailing newline in the final audience value caused an invalid_audience error during setup.

Do not rerun myTeslaMate’s full registration script for this self-hosted domain. Its registration step targets a myTeslaMate hostname, which produced a root-domain/Allowed Origin mismatch in this setup.

8. Authorize the vehicle-owner account

A partner token registers the application; it is not a user access token. The vehicle owner must separately grant access.

Generate a login URL on Unraid:

1
(
2
set -eu
3
umask 077
4
cd /mnt/user/appdata/tesla-vehicle-command/oauth
5
state=$(openssl rand -hex 32)
6
printf '%s' "$state" > authorization-state
7
jq -r --arg state "$state" \
8
  '"https://fleet-auth.prd.vn.cloud.tesla.com/oauth2/v3/authorize?" +
9
   ({client_id,redirect_uri:"https://app.myteslamate.com/auth/tesla/user/callback",
10
     response_type:"code",
11
     scope:"openid offline_access vehicle_device_data vehicle_charging_cmds",
12
     state:$state,prompt:"consent"}
13
    | to_entries | map((.key|@uri)+"="+(.value|@uri)) | join("&"))' \
14
  client.json
15
)

Open that URL, sign in with the same owner account used in the Tesla app, select the vehicle, and grant Vehicle Information and Vehicle Charging Management. For a self-hosted callback, validate the returned state against the stored value; this walkthrough uses myTeslaMate’s callback/code-display flow.

If no consent screen appears and the required permissions remain missing, revoke only this application under the Tesla account’s Security → Third-Party Apps, then start a fresh authorization flow. Revocation invalidates existing tokens for that application.

Exchange the authorization code immediately

Codes expire quickly and work only once. Run this on Unraid and paste only the newly issued code at the hidden prompt:

1
(
2
set -eu
3
umask 077
4
cd /mnt/user/appdata/tesla-vehicle-command/oauth
5
work=$(mktemp -d)
6
trap 'rm -rf "$work"' EXIT
7
read -r -s -p 'New authorization code: ' code
8
printf '\n'
9
printf '%s' "$code" > "$work/code"
10
unset code
11

12
jq -rj --rawfile code "$work/code" \
13
  '{grant_type:"authorization_code",client_id,client_secret,
14
    code:$code,redirect_uri:"https://app.myteslamate.com/auth/tesla/user/callback"}
15
   | to_entries | map((.key|@uri)+"="+(.value|@uri)) | join("&")' \
16
  client.json > "$work/request"
17

18
curl --silent --show-error --max-time 45 \
19
  -H 'Content-Type: application/x-www-form-urlencoded' \
20
  --data-binary @"$work/request" \
21
  https://fleet-auth.prd.vn.cloud.tesla.com/oauth2/v3/token \
22
  -o "$work/response"
23

24
if jq -e '(.access_token|type=="string" and length>0)
25
          and (.refresh_token|type=="string" and length>0)' \
26
  "$work/response" >/dev/null; then
27
  install -m 600 "$work/response" tokens.json
28
  rm -f authorization-state
29
  echo 'SUCCESS: OAuth tokens saved privately.'
30
else
31
  jq '{error,error_description}' "$work/response"
32
  exit 1
33
fi
34
)

A successful exchange does not prove that all requested permissions were granted. Initially, my token contained charging permission only; listing vehicles returned 403 Unauthorized missing scopes. Reauthorizing with Vehicle Information fixed vehicle access.

9. Enroll the virtual key in the Tesla app

Do this after account consent, not before.

1. Wake the vehicle and select it in the Tesla app.
2. On the phone, open https://tesla.com/_ak/dvkwong.com (replace the domain for another installation).
3. Approve the virtual-key request.
4. Check Controls → Locks in the vehicle for the new key.

Before account consent was complete, the app reported:

1
Adding a virtual key for "dvkwong.com" is forbidden because you have not
2
 granted "dvkwong.com" access to your account.

The key was successfully enrolled after correcting the OAuth consent flow. No new signing key was needed.

10. Let evcc trust the proxy certificate

In Unraid, choose evcc → Edit → Add another Path, Port, Variable, Label or Device, then add a Path:

Apply the change and restart evcc. This mount is intended to make the self-signed certificate available in the Alpine-based container’s certificate directory; verify actual trust with a charging request before considering integration complete. Do not disable TLS verification or mount either private key into evcc.

Persist the mapping in the Unraid template, not with a one-off docker cp, so container recreation retains it.

11. Configure the vehicle and loadpoint in evcc

Open Configuration → Vehicles → Add → Tesla, not Tesla BLE.

To display the saved tokens only in your own Unraid terminal:

1
jq '{access_token, refresh_token}' \
2
  /mnt/user/appdata/tesla-vehicle-command/oauth/tokens.json

Copy them into evcc; do not share screenshots or paste them into chat. evcc should manage subsequent token refreshes. The manually saved file is a bootstrap snapshot, not an automatically synchronized copy of evcc’s current tokens.

Then open Configuration → Loadpoints → Tesla Charger → Edit, select the newly added vehicle, and save. Keep charging mode Off until testing is ready.

12. Verify before enabling automation

• Confirm the container stays running without a restart loop.
• Confirm HTTPS works with certificate verification enabled.
• Confirm evcc can read the correct vehicle’s battery level.
• With the car plugged in and ready, deliberately test charging start/stop and current adjustment.
• Check evcc and proxy logs for TLS, OAuth, or key-pairing errors.

Reading battery data verifies OAuth access, but does not verify signed commands. Only a successful charging command completes the end-to-end check. At the time of writing, virtual-key enrollment and Fleet API vehicle access had succeeded; this final evcc charging test was still outstanding.

References

• Tesla Vehicle Command SDK and Docker configuration
• Tesla Fleet API documentation
• evcc Tesla vehicle configuration