From Mycroft and Ansible to OpenVoiceOS: boring installs, easy updates

Gaëtan Trellu — Sun, 08 Feb 2026 19:24:27 +0000

A few years ago, I wrote an opensource.com post about deploying Mycroft on a Raspberry Pi using Ansible. The fun part was voice control; the useful part was making the whole thing reproducible—because voice assistants are a stack, and stacks don’t forgive “hand-installed on a good day” setups. (Opensource.com)

Since then, the Mycroft ecosystem went through a very public reality check. In February 2023, Mycroft’s CEO explained that without immediate new investment they would have to cease development. (Open Source Conversational AI Community)
By February 2024, community members were also confirming that servers associated with mycroft.ai were down—the kind of event that turns “my assistant is quirky” into “my assistant is suddenly unemployed.” (Open Source Conversational AI Community)

Open voice assistants didn’t disappear, though. The community kept building, and OpenVoiceOS (OVOS) matured into a platform you can run across devices—with a focus on privacy, security, and customization. (Open Voice OS)

I’m writing this one as the author of ovos-installer and ovos-docker. Those projects exist for a simple reason:

I wanted OVOS installs and upgrades to be boring.
Boring means repeatable, automatable, supportable—and much easier to enjoy.

What is OpenVoiceOS?

OVOS is a community-driven, open-source voice AI platform designed for building custom voice-controlled interfaces across devices. (Open Voice OS)
It also answers a question I get a lot: “Is this still related to Mycroft?” The OVOS FAQ explains that OVOS started as MycroftOS, was renamed to avoid trademark issues, and evolved toward maintaining its own enhanced reference fork while keeping compatibility goals in mind. (Open Voice OS)

A detail that matters operationally: OVOS is designed so that ovos-core does not require a backend internet server to operate by default, although your choice of STT/TTS plugins and skills can still require network connectivity. (Open Voice OS)

Pick your “deployment personality”

OVOS keeps the choice simple: Docker or Python. (Open Voice OS)

Python virtual environment is great if you want to develop, tweak, and stay closer to the system.
Containers are great if you want stability, isolation, and an update path that doesn’t involve solving dependency archaeology.

OVOS explicitly presents those as the two main install approaches. (Open Voice OS)

Install OVOS with ovos-installer

The OVOS downloads page points laptop/desktop users (and anyone installing “on top of an existing OS”) toward the installer, noting it supports major Linux distributions and Raspberry Pi 3/4/5. (Open Voice OS)

ovos-installer is an OVOS (and optionally HiveMind) installer for Linux. It supports interactive installs, scenario-based automation, and optional container deployment. (GitHub)

Quickstart

Prereqs are intentionally basic: curl, git, and sudo. (GitHub)

sudo sh -c "$(curl -fsSL https://raw.githubusercontent.com/OpenVoiceOS/ovos-installer/main/installer.sh)"

If you prefer to inspect before running (recommended when you’re wearing your “operator” hat), the README explicitly suggests downloading the script first, reviewing it, then executing it. (GitHub)

A small but important ops detail: the installer targets a supported Python runtime in its virtualenv (defaulting to Python 3.11) and uses uv to provision it when needed. (GitHub)

Automate installs with scenario.yaml

This is where the Ansible brain kicks in.

ovos-installer supports non-interactive installs via a scenario file:

~/.config/ovos-installer/scenario.yaml (GitHub)

A minimal example (container method, default skills, Pi tuning enabled) looks like this:

---
uninstall: false
method: containers
channel: testing
profile: ovos
features:
  skills: true
  extra_skills: false
raspberry_pi_tuning: true

The README documents the meaning of these keys (including the uninstall flag and the available install methods). (GitHub)

Fun footnote: yes, it’s YAML—but it’s YAML with purpose, and it’s the kind you can keep in git without waking up in a cold sweat later.

Run OVOS in containers with ovos-docker

For container deployments, ovos-docker provides container images and compose bundles for OVOS across x86_64 and aarch64. (GitHub)

If you’ve ever tried to explain to someone why “a voice assistant is actually a dozen services,” OVOS’ own blog makes the container case clearly: running OVOS micro-services in containers improves isolation, and makes the platform easier to manage and update. (OpenVoiceOS Blog)

The container docs walk through a standard flow (clone the repo, create directories, run the compose bundles). For example, the docs show cloning the sources and working from the compose/ directory. (Open Voice OS)

git clone https://github.com/OpenVoiceOS/ovos-docker.git ~/ovos-docker
cd ~/ovos-docker/compose

The easy way to update your current OVOS instance

This is the part I wanted to make delightfully uneventful.

Update a virtualenv/systemd install

ovos-installer documents a very straightforward update path:

Optionally back up your configuration (~/.config/mycroft/mycroft.conf or ~/ovos/config/mycroft.conf)
Re-run the installer
When prompted, answer “No” to: “Do you want to uninstall Open Voice OS?” (GitHub)

That’s it. No bespoke “upgrade script,” no guessing which dependency set is current—just re-run the tool that knows how to converge the system.

Update a container stack

The OVOS container documentation is equally blunt (and I mean that as a compliment):

To update the deployed stack, use the exact same command you used when you initially deployed it. (Open Voice OS)
Because each service is configured with pull_policy: always, when a new image is published with the same tag, docker compose (or podman-compose) will pull it and recreate the container. (Open Voice OS)

Example commands (from the docs) show typical bundles; the important part is the “same command” rule and using your bundle set consistently. (Open Voice OS)

If you want to change which image tag/version you deploy, update the .env file accordingly; the docs also note that the alpha tag images are rebuilt nightly from the dev branch. (Open Voice OS)

Closing: keep the fun, remove the pain

My 2021 Mycroft + Ansible post was basically an attempt to make an open voice assistant “liveable” as infrastructure. (Opensource.com)
OVOS is the continuation of that idea, and ovos-installer + ovos-docker are my contribution to the unglamorous part: installs, updates, and repeatability.

Because once installation stops being a boss fight, you can get back to the fun stuff—like making your house respond to voice commands without renting space in someone else’s cloud.

Resources

My earlier opensource.com post on Mycroft + Ansible (Opensource.com)
OVOS project overview + FAQ (Docker vs Python, offline notes, background) (Open Voice OS)
OVOS downloads page (installer recommendation and supported devices) (Open Voice OS)
ovos-installer README (install + update guidance) (GitHub)
OVOS container docs: Update Open Voice OS (Open Voice OS)
OVOS blog note on why containers help manage/update a micro-service stack (OpenVoiceOS Blog)

DEV Community: Gaëtan Trellu