wire-pod gives Anki Vector robots free voice commands again

What chipper opened and wire-pod took further

wire-pod is described as fully-featured server software for the Anki robot, now made by Digital Dream Labs. The origin story is in the README: the project was created thanks to Digital Dream Labs open-sourced code, chipper.

What that open sourcing made possible is stated plainly in the README. wire-pod allows voice commands to work with any Vector 1.0 or 2.0 for no fee, including regular production robots. That sentence contains the whole motivation. The robot hardware is not restricted to development units, and the voice feature is not held behind a subscription.

The repository layout shows how the work is divided. There is a chipper directory, which is the upstream base, and a vector-cloud directory beside it. There is also a compose.yaml, a dockerfile, a docker directory, an images directory, a setup.sh and an update.sh.

The credits section tells you where the individual pieces came from. Digital Dream Labs gets the credit for open sourcing chipper and creating escape pod, which the README says made this possible. bliteknight made wire-pod more accessible with easy-to-use pre-setup Linux boxes. dietb rewrote chipper and gave tips. fforchino added many features such as localization and multilanguage, and xanathon handled the publicity and the web interface.

The language is Go, the licence is MIT, and the last push to the repository was on 2026-10-15, so the code is still moving even though the tagged releases are old.

The compose stack and the four ports it opens

The deployable artefact in this repository is the compose file, and it is more informative than the README.

The service is named wire-pod with the container name wire-pod and the hostname escapepod, a name that echoes the escape pod credit in the README. The build section points at the local dockerfile in the repository root with the context set to the repository root, while the image field names the published image ghcr.io/kercre123/wire-pod:main. The restart policy is unless-stopped, so the container comes back after a reboot.

  wire-pod:
    container_name: wire-pod
    hostname: escapepod
    build:
      context: .
      dockerfile: dockerfile
    image: ghcr.io/kercre123/wire-pod:main
    restart: unless-stopped
    environment:
      WIREPOD_DATA_DIR: /data

The port mapping is where you learn what this thing listens on.

    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
      - "8084:8084"

Four ports, of which the first two are the standard web pair and the second pair are the ones the health check and the robot talk to. The README does not document what each individual port serves, so the port list is the only statement about the network surface, and it is worth reading as such before you expose the container.

The environment section defines a single variable, WIREPOD_DATA_DIR, set to /data, which is where the server keeps its state.

Two named volumes and a health check that actually probes the server

State lives in named Docker volumes rather than in a bind mount. The compose file declares wire-pod-data mounted at /data and wire-pod-images mounted at /images, and both are local driver volumes.

    volumes:
      - wire-pod-data:/data
      - wire-pod-images:/images

volumes:
  wire-pod-data:
    driver: local
  wire-pod-images:
    driver: local

The images volume exists because the robot has a visual system and the server evidently needs somewhere to keep image assets, which is consistent with the images directory at the repository root and with the web interface work credited to xanathon.

The health check is the part worth copying. It runs curl against an ok endpoint on the running service, and it is not a superficial check.

    healthcheck:
      test: [ "CMD", "curl", "-fsS", "http://localhost:8080/ok" ]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 30s

That tells you several things at once. The service exposes a health endpoint at /ok on port 8080, which is the same port the compose file publishes. The image includes curl, since the health check shells out to it. And the timings are realistic rather than aggressive: a 30 second start period gives the server time to come up before failures count, then checks every 30 seconds with a 5 second timeout and up to 5 retries.

For an operation where the robot depends on the server being reachable, that combination of a real endpoint and a patient retry policy is what keeps a restart from turning into a visible outage.

Installation lives on the wiki, not in the README

This is the most notable gap in the documentation, and it is worth naming rather than glossing over.

The README has an Installation section, and it contains one sentence: the installation guide exists on the wiki, with a link to the Installation guide page. The Wiki section repeats the point, listing what the wiki covers, which is an explanation of what wire-pod is, a guide on how to install wire-pod, troubleshooting, how to develop for it, and some generally helpful tips.

So the practical steps are not in the repository you are reading. Everything from flashing or pairing the robot through to the first successful voice command lives in the wiki. That is a reasonable place for it, since a wiki can carry screenshots and platform specific notes, but it does mean the repository alone cannot get you a working robot, and it means the setup instructions have a different maintenance lifetime than the code they describe.

The repository root does contain setup.sh and update.sh, so scripted setup and scripted updating exist as files in the tree. The README does not describe what those scripts do, what they expect, or how they differ from the wiki steps, and the update script in particular raises a question the documentation leaves open: how a self-hosted installation upgrades when there are no recent tagged releases to upgrade to.

For a project with this split, the wiki and the compose file are the two things to read before anything else.

The release history does not match the commit history

The maintenance picture needs two different facts to be read together.

The release list shows v1.1.0, v1.1.1 and v1.1.2, all dated in November 2023, with the tags for the two earlier ones pointing at windows/v1.1.0 and windows/v1.1.1 rather than at the main branch. The newest entry carries the note that releases are elsewhere. So the tag namespace is a historical Windows build series, and the note tells you the current artefacts are not published from this repository's tag list.

Against that, the last push was on 2026-10-15, and the compose file pulls the image tagged main from the GitHub Container Registry. Those two facts together describe the actual distribution model: the container image on ghcr.io is the moving artefact, and the git tags in this repository are not how you get the current build.

That has practical consequences. Pinning by version tag is not available from this repository, so pinning means pinning a git commit or a digest of the container image. And if you are running a version from the 2023 tag series, you are several years behind whatever is in the main branch image today, and the compose file does not tell you which one is in front of you.

The licence is MIT with a LICENSE file at the root, which is straightforward for a project of this kind.

Where wire-pod is the wrong choice

The first wrong case is a robot you do not own or cannot modify. wire-pod is server software that a Vector talks to, and it changes what the robot does by changing the server it contacts. Nothing in the README suggests a path for a robot provisioned by someone else who keeps pointing it at the vendor service.

The second is a Vector 3.0 or newer. The README names Vector 1.0 and 2.0 explicitly, and the repository layout, with chipper as the base and a vector-cloud directory, belongs to that generation of hardware. A Vector from the newer line has different internals and is not covered by anything documented here.

The third is a need for a supported product. The project is a community effort built on open sourced code, funded by donations through the Buy Me a Coffee link in the README, and the release story is a container image on a moving tag rather than a versioned, supported distribution. That is a perfectly good arrangement for a hobby robot and a poor one for a robot you depend on for anything.

The fourth is a locked-down network. The compose file publishes four ports including 80 and 443, and the health check implies an HTTP service on 8080 with a web interface. Putting that on an untrusted network is a decision you have to make deliberately, and the README does not discuss authentication, so you should not assume the web interface is safe to expose as it comes.

How it compares with the official Vector experience

The alternative is the vendor service the robot normally talks to. The difference is ownership and cost, and the README is explicit that wire-pod exists to make voice commands work for no fee on any Vector 1.0 or 2.0 including production units.

In practice, running wire-pod means you become the operator of a server that your robot depends on. You run the container, you keep it reachable from your local network, and you own the failure modes that come with that. The compose file helps: the restart policy handles a crash, the health check tells Docker whether the service is actually working, and the named volumes keep your data and images across recreations.

What you get in exchange for that operational work is the voice feature without a subscription, and a server you can read and change. The Go source, the chipper base and the dockerfile are all in the repository, and the wiki points at development guidance for people who want to extend it. That is a different proposition from a consumer product, and for a tinkerer with a spare robot on a shelf it is the better one.

There is also the intermediate option of the pre-setup Linux boxes credited to bliteknight, which the README mentions as making wire-pod more accessible. That path removes the container assembly step for people who do not want to deal with compose files at all, and it is the fastest route for a first successful voice command.

Editorial conclusion

wire-pod fits an owner of a Vector 1.0 or 2.0 robot, including a production unit, who wants voice commands without a paid subscription and is prepared to run the server themselves. It does not fit someone who wants a turnkey appliance, since the README delegates installation to a wiki and the repository ships a container stack rather than an installer, and it does not fit a project that needs ongoing vendor support, since the tagged releases date from 2023 even though the code is still being pushed. Before deploying, read the installation guide on the wiki, decide whether you want the published ghcr.io/kercre123/wire-pod:main image or a local build from the dockerfile in the repository, and confirm that the four published ports and the WIREPOD_DATA_DIR volume layout match what your network allows.

Frequently asked questions

Official sources

1. Issues
2. kercre123/wire-pod on GitHub
3. License: MIT
4. README
5. Releases