GoogleHomeKodi is an Express broker that turns a voice sentence into a Kodi JSON-RPC call

The service is a relay, not a Kodi plugin

The architecture is three hops and the middle one is the point. A Google Home speaker receives a voice command, an IFTTT applet forwards it as a webhook to this server, and the server translates the sentence into a Kodi JSON-RPC request. The project description in the package manifest says it exactly that: a node express server for relaying google home commands from IFTTT to your Kodi installation. There is no Kodi addon, nothing is installed on the media centre, and Kodi's own web server does the work. The repository layout follows from that: `server.js` is the entry point, `broker/` and `broker.js` handle the incoming webhooks, `kodi-connection/` holds the code that talks to Kodi, `helpers.js` and `exceptions.js` carry the shared utilities, `views/` holds the small web pages, and `config.js` sits at the root next to `kodi-hosts.config.js.dist`, the distributed copy of the host configuration. The `apps/` directory holds the command handlers, which is how a project with dozens of distinct voice commands keeps them from all ending up in one file.

The command vocabulary is broad and the phrasing is fixed

The command surface is the substance of the project, and the documentation enumerates it with the exact sentence for each. Playback covers playing a named movie, resuming a movie from where it was left, playing a random movie, and playing a random movie filtered by genre and year, with a separate phrase for each combination. Television has its own set, including playing the next unwatched episode of a show, playing a specific episode by season and episode number, shuffling a random episode, playing the most recently added episode, and a binge watch phrase that adds all unwatched episodes to the playlist and plays them. YouTube is separate again, with a phrase that searches and plays the first video and another that searches and shows the results on the Kodi screen. Then there is the long tail. Volume supports mute and unmute, setting a volume to a number, and increasing or decreasing by a requested amount or by 20% if no amount was specified. Moving the selection supports up, down, left, right, back, select, open context menu and go home, each with an optional count. Windows cover favourites, movies by title or by genre, recently added movies, TV shows in the same variants, video and music addons, video and music files, the top 100 albums, system settings, file manager, and a set of YouTube windows including watch later, history, recommendations, subscriptions and settings, with a note that a full list of windows lives in the Kodi wiki.

Every amount is optional, and the default is documented per command

One design decision shows up across nearly every command and it is worth pulling out, because it is the difference between a voice interface that works and one that frustrates. Optional arguments have documented defaults. Moving up takes an optional count and moves once if no number was specified. Volume up increases by the requested amount or by 20% if none was given. Seek forward goes forward the requested number of minutes or just 1 minute if no number was specified, and seek backward behaves the same way. The list of sentences is a set of templates with an optional numeric slot, which is what makes the set finite while still feeling flexible to a speaker. There is a second kind of optionality in the media commands, where the target is described in words. Play the song, play the album, play songs by the artist, and play some music of a given genre, plus a party mode toggle. Playlist control looks for a playlist by name and plays it, with both smart and regular playlists supported.

System control and library maintenance are in the same vocabulary

The commands are not limited to watching things, which is what separates this from a simple remote. System control covers shutdown, hibernate, reboot and suspend, each as its own phrase. Library maintenance covers a full scan and a clean, which map to Kodi's own library operations. There is also a phrase for switching the TV to the Kodi input, which is the part that makes the setup usable from a sofa: the documentation says it will turn on the TV and switch to Kodi's HDMI input, so a voice request can wake the television and put the right source on it. PVR control lets you switch to a named channel or to a channel number, and there is a separate phrase for turning on the TV without touching Kodi's playback at all. Subtitle and audio stream control are present too, with a phrase to toggle subtitles on, off, previous or next, a phrase to change the subtitle to a specific track, and matching phrases for the audio stream, including selecting a specific track by number.

The container takes one port, one token and the Kodi connection details

The deployment is a single compose file, and the environment block is where the whole configuration lives. The image is `omertu/googlehomekodi`, it publishes one port, 8099, and it is set to restart always. The environment carries the Kodi connection details and the token, and the compose file ships with placeholders you have to replace:

    environment:
      - KODI_PROTOCOL=http
      - KODI_IP=YOUR_INTERNAL_KODI_IP_ADDRESS
      - KODI_PORT=YOUR_KODI_PORT
      - KODI_USER=YOUR_KODI_USER_NAME
      - KODI_PASSWORD=YOUR_KODI_PASSWORD
      - AUTH_TOKEN=YOUR_CONNECTION_PASSWORD

Two of those values deserve attention. `KODI_PROTOCOL` is a separate setting from the rest, so the transport is a choice rather than a fixed assumption, and `AUTH_TOKEN` is named as a connection password, which means it is the thing standing between your LAN and a service that can change the volume, play anything in the library and reboot the machine. The repository also ships `app.json`, which is the Heroku-style manifest that a one-click deploy would consume, and `cloudbuild.yaml` plus a `docker_build_and_push.sh` script for building and pushing the image yourself.

The Docker image runs tests and lint before it ships

The Dockerfile is written in three stages and the first one is a test stage, which is unusual and worth noting. The builder starts from `node:25-alpine` as a test target, copies the package files, runs `npm install`, copies the source and then runs both `npm test` and `npm run lint`. A second production-builder stage reinstalls the dependencies with `npm install --omit=dev`, which drops the test and lint tooling from the runtime image. The final stage sets the configuration path and the port, declares a volume for the config directory, installs tini as the init process, copies the production dependencies, runs as the `node` user rather than root, exposes port 8099, and starts the server with `node server.js` under tini. The config path is set as an environment variable, `GOOGLE_HOME_KODI_CONFIG`, pointing at `/config/kodi-hosts.config.js`, which is why the compose file's `kodi-hosts.config.js.dist` has to be mounted into that location and renamed. The npm scripts themselves are minimal: `start` runs the server, `lint` runs eslint over the JavaScript files while ignoring node_modules, and `test` runs mocha recursively with the should assertion library.

Multiple Kodi hosts are a config file, and the docs stop before the setup

The `kodi-hosts.config.js.dist` file at the repository root and the `GOOGLE_HOME_KODI_CONFIG` environment variable together imply a setup where more than one Kodi instance can be addressed, with the mapping from a name to a host held in a JavaScript config file rather than in the environment. The documentation also links an example environment file and an example IFTTT settings file under `examples/`, which are images rather than text, so the exact contents of the IFTTT applet configuration are not readable here. That is a real gap in what can be checked. The visible portion of the documentation stops after the command vocabulary, so the setup and update section that the table of contents promises, the section on testing language files, and the troubleshooting section are all named but not shown. The topic list on the repository includes a `test/` directory and a `Dockerfile` with a `.devcontainer/` directory, so development is set up for a container too. The repository has no tagged releases and the last push was on 2026-04-16, so the version in the package manifest, 0.0.2, is the only version reference available.

Where a voice bridge to Kodi is the wrong shape

The architecture has one obvious weakness and it is a security one. The server is a plain Express app that accepts webhook calls and maps them to Kodi commands, and the only thing standing in front of it is a token in the environment. The compose file publishes the port on the host, so the exposure depends on where you put it, and the documentation does not describe a reverse proxy, a TLS terminator or an allow-list of source addresses. A service that can reboot a machine, change the volume and pull anything from a media library is not something you want reachable from outside your network by accident, and an IFTTT webhook in particular is an inbound path from the internet that you do not fully control. The second limitation is the phrasing. The commands are a fixed template set, so a speaker who says something slightly different gets nothing, and the documentation's own set already shows how much surface that is. The alternative to weigh against is doing the same thing inside the Kodi process, with an addon that registers its own voice or remote service, which removes the network hop and the token but requires Kodi addon development and gives up the IFTTT path. The difference in approach is between a standalone relay that anyone with the token can drive, and a plugin that runs with the permissions Kodi already grants. If the token is the only thing between your LAN and a reboot command, an addon inside Kodi is the safer shape.

Editorial conclusion

GoogleHomeKodi is worth deploying if you already run Kodi and a Google Home speaker and want voice control without touching the Kodi box, because the command vocabulary is documented example by example and the container image ships with a single port and a token, so the whole deployment is one compose file. It is a poor fit if you need a supported product, since the repository records no recognised licence, has no tagged releases and the visible documentation stops before the setup section, so the IFTTT configuration steps are not in the file you can read here. Before deploying it, set the `AUTH_TOKEN` value to something you choose rather than the placeholder, point `KODI_IP` at a machine that is actually reachable, and confirm that the Kodi web server is enabled with the credentials you put in the compose file. The last push to the repository was on 2026-04-16.

Frequently asked questions

Official sources

1. Issues
2. OmerTu/GoogleHomeKodi on GitHub
3. README