# folotoy-server-self-hosting: running the FoloToy server yourself > This repository is the configuration set for a self-hosted FoloToy Community Server, with a Docker Compose file that wires the server to an EMQX broker and an nginx front end, and a config directory that selects the speech to text, language model and text to speech providers you want. **FoloToy/folotoy-server-self-hosting** — Config files for self-hosting the FoloToy Community Server. Documents: https://docs.folotoy.com - Repository: https://github.com/FoloToy/folotoy-server-self-hosting - Website: https://tool.folotoy.com - Stars: 608 · Forks: 103 - Language: Unknown - License: GPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/folotoy-folotoy-server-self-hosting ## A configuration repository, not a codebase The project description says it plainly: config files for self-hosting the FoloToy Community Server, with the documentation at docs.folotoy.com. The top level of the repository confirms the shape. There is a `config/` directory, an `audio/` directory, an `examples/` directory, a `docker-compose.yml`, a `folotoy-server-deploy.skill` file, a `.gitignore`, a `LICENSE`, and a README in English and Simplified Chinese. There is no source code to compile and no build system, which is the key point for anyone evaluating it. You are not adopting a library, you are adopting a deployment. The primary language of the repository is recorded as unknown, and the licence is GPL-3.0. The homepage is tool.folotoy.com, and the last push was on 2026-09-19, so the configuration is still being adjusted even though the most recent release tags are from late 2023. ## What the server does once it is running The feature list in the README describes a voice loop with several interchangeable back ends. Speech in and voice out is the headline. The LLM layer supports OpenAI, Azure OpenAI, Google Gemini, Baidu Qianfan, Dify and Moonshot. The sound to text layer, called SST in the documentation, supports OpenAI Whisper, the Azure Speech Service, Azure Whisper, Aliyun ASR and Dify. The text to sound layer, called TTS, supports OpenAI TTS, the Azure Speech Service, Elevenlabs, Edge TTS, Aliyun TTS, Netease EmotiVoice and OpenVoice. And the AI conversational data is published to an MQTT broker, which is the part that makes the server useful to other systems. A FoloToy is a physical toy that talks, and this server is the conversation engine behind it, with a different provider selected for each direction of the loop. ## Three containers, and the ports they open The compose file defines three services. EMQX is the MQTT broker, on the `emqx/emqx:latest` image, with `restart: always` and three published ports, 1883 for MQTT, 18083 for the dashboard and 8083 for the WebSocket listener, plus named volumes for its configuration, data and logs, and an environment variable setting the node name to `emqx@node1.emqx.io`. Nginx sits in front of the audio directory, mapping 8082 to port 80 and mounting `./audio` into `/usr/share/nginx/html`, so the recorded or generated audio is served over plain HTTP. The FoloToy server itself runs from the `lewangdev/folotoy-server:latest` image with a published UDP port 8085, which is the path the physical toy uses to talk to the server, and it mounts `./audio` to `/audio` and `./config` to `/config`. The timezone is set to Asia/Shanghai and the log level to DEBUG. The three-container split is a sensible design, since the broker, the file server and the conversation engine have genuinely different lifecycles and the toy only needs to reach one of them. ## The config file is where the providers get chosen The environment block of the compose file is long, and its structure is the documentation of how to pick a provider for each stage. The server reads its roles from a file pointed at by `ROLES_FILE_PATH`, set to `/config/roles.json`, which is why the `config` directory is mounted into the container. The `STT_TYPE` variable selects the sound to text implementation, with the options listed in the comment as openai-whisper, azure-whisper, azure-stt, dify-stt, aliyun-asr and volcengine-asr, and the default set to openai-whisper. Each provider then has its own variables, so an OpenAI Whisper setup needs an API base, a key and a model name of `whisper-1`, an Azure Whisper setup needs an API base, a key, a deployment name and an API version of `2023-09-01-preview`, and an Azure STT setup needs a key and a service region of `eastasia`. Dify, Aliyun ASR and the rest follow the same shape, one group of variables per provider, with the unused ones left commented out. ## The keys in the committed file are placeholders, and that is the security story This is the detail to look at before you deploy. The compose file in the repository contains values that look like real credentials, for example an OpenAI Whisper key beginning with `sk-` and a set of Azure keys, and they are placeholders, with the repeated characters making that clear. The pattern is that each provider's key is present but blank of real content, and the ones you do not use are commented out. That is a reasonable way to ship an example, but it means the file you copy still contains credential-shaped strings, and it is a template that people edit in place. The `.gitignore` in the repository and the presence of a `config/` directory rather than a single file suggest the intended shape is to edit the compose file locally and keep it out of version control, but the README's quick start only tells you to clone the repository, and it does not spell out a secret management approach. Treat every key in the compose file as something you have to replace, and treat the file as something you should not commit once it holds real keys. ## Two ways to deploy, and what the skill does There is a faster route than the quick start. The README describes a `folotoy-server-deploy` OpenClaw Skill for a streamlined deployment experience, and the skill automates the setup using Docker Compose and allows easy configuration of the STT, LLM and TTS API keys. To use it you need OpenClaw installed, and then you import the skill file `folotoy-server-deploy.skill` and follow its instructions to deploy the FoloToy Server. The manual route is the quick start, which the README presents as copy and paste: ```bash git clone https://github.com/FoloToy/folotoy-server-self-hosting.git folotoy-server ``` The skill is worth understanding as a design decision rather than as a convenience. The repository is configuration, so the hard part of self-hosting is not building anything, it is deciding which provider serves each stage and filling in the credentials for it, and that is exactly what the skill automates. There is also a language dimension. The README points to a multilingual role example under `examples/multilingual/`, and describes it as covering an opt-in language-following role and fixed-language voices, which is a different behaviour from the default and is documented separately. ## Where this is the wrong choice The limits are obvious once you accept what the repository is. First, there is no managed option here, so the tradeoff that self-hosting implies applies in full: you run the broker, the file server and the application, you keep them updated, and you supply API keys to third party model providers anyway, so the speech and language models still leave your machine even though the conversation history and the orchestration stay on it. Second, the release history and the commit history disagree. The most recent tags are from November and December 2023, while the last push was on 2026-09-19, so the configuration in the tree is nearly three years ahead of the last tagged release, and the images are pinned to `latest` tags rather than to a version, so a redeploy can pull different code from the one you tested. Third, the port exposure. The broker is published on 1883 and 8083 and the file server on 8082, and while these are container port mappings on the host, publishing an MQTT broker without authentication or a broker configuration is a decision you have to make rather than inherit, especially with the data flowing through it being conversation transcripts. Fourth, the README is short, and the real configuration guidance lives at docs.folotoy.com, so the repository alone is not enough to run the thing. ## Conclusion This repository fits a FoloToy owner who wants the conversation data and the API keys to stay on their own hardware, since the whole thing is a compose file and a config directory rather than a service you sign up for. It is the wrong choice if you want a plug and play product, because there is no installer, you assemble it yourself, and you supply the API keys for whichever speech and language providers you use. Before you deploy, read the compose file end to end because the keys for several providers are committed in it as placeholders that you must replace, and check the EMQX port exposure since the broker is reachable on 1883. The last push was on 2026-09-19, the newest release tag is from 2023, the licence is GPL-3.0, and the documentation lives at docs.folotoy.com. ## FAQ ### What does the folotoy-server-self-hosting repository contain? Configuration files for a self-hosted FoloToy Community Server: a docker-compose.yml, a config directory, an audio directory, an examples directory, a folotoy-server-deploy.skill file, and a bilingual README. There is no source code to build, so it is a deployment rather than a library. ### Which speech and language providers does the FoloToy server support? The LLM layer supports OpenAI, Azure OpenAI, Google Gemini, Baidu Qianfan, Dify and Moonshot. Sound to text supports OpenAI Whisper, the Azure Speech Service, Azure Whisper, Aliyun ASR and Dify, selected with the STT_TYPE variable. Text to sound supports OpenAI TTS, the Azure Speech Service, Elevenlabs, Edge TTS, Aliyun TTS, Netease EmotiVoice and OpenVoice. ### Which containers does the FoloToy docker-compose file run? Three. EMQX is the MQTT broker on ports 1883, 18083 and 8083, nginx serves the audio directory on 8082, and the FoloToy server runs from the lewangdev/folotoy-server:latest image with a UDP port 8085 and the config directory mounted at /config, where the roles file is read from. ## Sources - [FoloToy/folotoy-server-self-hosting on GitHub](https://github.com/FoloToy/folotoy-server-self-hosting) - [License: GPL-3.0](https://github.com/FoloToy/folotoy-server-self-hosting/blob/main/LICENSE) - [Project website](https://tool.folotoy.com) - [README](https://github.com/FoloToy/folotoy-server-self-hosting/blob/main/README.md) - [Releases](https://github.com/FoloToy/folotoy-server-self-hosting/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/folotoy-folotoy-server-self-hosting