Voxta Modules
What a Voxta module is and how it fits into the server.
A Voxta module is a .NET class library that runs inside the Voxta server process. Every AI service Voxta orchestrates in-process — OpenAI text generation, ElevenLabs TTS, Vosk transcription, vision providers, the Elite Dangerous COVAS — is implemented as a module. Your own modules sit alongside them.
Modules vs. integrations
A module runs in-process, as a .NET DLL loaded by Voxta at startup. Modules are for services that benefit from running inside the server: providers that wrap an AI API, services that need fast access to chat state, integrations that can be expressed in pure .NET (file watchers, HTTP calls, Win32 input).
An integration runs in its own process and connects to Voxta over the WebSocket / SignalR API. Voxta Minecraft Companion (Electron + Node.js + Mineflayer), the Virt-A-Mate plugin (in-game C# script), and Voxy (desktop avatar app) are all integrations, not modules — they live where their host runtime lives, not inside the Voxta server.
Rule of thumb: if your code needs to live in another runtime (Node.js, a game's scripting engine, a browser), write an integration. If it can run as in-process .NET code, write a module.
Anatomy of a module
A module is a single project that exposes a class implementing IVoxtaModule. Voxta discovers it by reflection at startup, calls Configure(IVoxtaModuleBuilder) once, and from then on the module is wired into the server.
public class VoxtaModule : IVoxtaModule
{
public void Configure(IVoxtaModuleBuilder builder)
{
builder.Register(new ServiceDefinition { /* who I am */ });
builder.AddChatAugmentationsService<MyService>(/* what I do */);
builder.Services.AddSingleton<MyHelper>();
}
}Three things happen in Configure:
builder.Register(...)— declares the service to the system: name, label, what kinds of services it provides, hosting model, logo, pricing tier.builder.AddXxxService<T>(...)— registers your service implementation.Xxxmatches the service type (TextGen, SpeechToText, ChatAugmentations, etc.).builder.Services— the sameIServiceCollectionVoxta uses internally. Add helpers, singletons, hosted services. Standard ASP.NET Core DI.
Lifecycle
| Phase | What happens |
|---|---|
| Discovery | Voxta scans the Modules/ folder at startup and loads every Voxta.Modules.*.dll. |
| Configuration | Each module's VoxtaModule.Configure(...) is called once. Registrations are collected. |
| Service init | When the user enables your service in the UI, Voxta instantiates it via DI and calls InitializeAsync. This is process-lifetime — one instance per Voxta run. |
| Instance creation | When a chat session opens, Voxta calls CreateInstanceAsync on the service. The returned instance is per-chat — it has its own state and is disposed when the chat ends. |
| Configuration change | If the user changes a setting flagged in ModuleConfigurationFieldsRequiringReload, the service is torn down and re-initialized. Other field changes are picked up on the next instance. |
Distribution
Modules ship as plain DLLs. There is no installer, no signing requirement, no package format. To use a module:
- Build the project.
- Drop the output DLL (and any dependencies that aren't already in Voxta's
Modules/folder) into Voxta'sModules/directory. - Restart Voxta.
See Installing a module for the exact paths and dependency handling.
Next steps
Quickstart
From `dotnet new classlib` to a working module in five steps.
Service types
The full catalog of service types and when to pick which.
Configuration UI
Declare the settings page users see, mapped to your typed Settings record.
Installing a module
Where Voxta loads modules from and how dependencies resolve.