How to Enable or Disable Specific Features Like Voice or RAG in ODS Installation

You can enable or disable specific ODS features such as voice recognition and RAG (Retrieval-Augmented Generation) by using the ods enable <service-id> and ods disable <service-id> CLI commands, or by setting the COMPOSE_PROFILES environment variable before installation.

The Osmantic Data Stack (ODS) treats optional capabilities—including voice processing, RAG workflows, and AI model serving—as modular extensions that you can toggle based on your infrastructure needs. Whether you need to activate speech-to-text for voice interactions or configure a vector database for semantic search, ODS provides both runtime CLI controls and installation-time environment configuration to manage these features.

Understanding ODS Feature Architecture

ODS organizes functionality into service-specific extensions defined in individual manifest.yaml files. Each extension belongs to a profile category (such as voice, rag, or workflows) and can declare dependencies on other services.

When you enable or disable specific features, the system manipulates Docker Compose configurations by renaming compose.yaml.disabled files to compose.yaml (and vice versa) in the extension directories. This architecture ensures that only active services consume system resources while maintaining the ability to quickly re-enable capabilities without reinstallation.

According to the ODS source code, the default active profiles are controlled via the COMPOSE_PROFILES environment variable, which typically includes voice,rag,workflows,openclaw as documented in ods/memory-shepherd/baselines/ods-agent-MEMORY.md.

Method 1: Using the CLI to Enable or Disable Features

The ods CLI provides the most direct method to toggle features after installation. This command is a thin wrapper around the PowerShell script ods/ods.ps1, which implements the Invoke-Enable and Invoke-Disable functions.

Enabling a Service

To activate a specific feature, use the ods enable command followed by the service ID:

ods enable whisper
ods enable xtts
ods enable qdrant

The Invoke-Enable function in ods.ps1 performs the following actions:

1. Checks if the target extension is already active
2. If active, runs a repair path to re-add missing compose fragments
3. Resolves dependencies from the extension's manifest.yaml and recursively enables required services first
4. Renames compose.yaml.disabled to compose.yaml
5. Regenerates Docker Compose flags and starts the container (if Docker is available)

Disabling a Service

To deactivate a feature, use ods disable:

ods disable whisper
ods disable qdrant

The Invoke-Disable function includes guard clauses that prevent disabling a service while enabled dependents exist. As tested in ods/tests/test-windows-cli-enable-disable.sh, the system will reject the operation if other active extensions depend on the service you are trying to disable, displaying an "enabled extensions depend on" message.

Dependency Management

The CLI automatically handles service dependencies. For example, enabling a voice cloning service might first enable its underlying TTS dependency. The test suite in ods/tests/test-windows-cli-enable-disable.sh validates this recursive dependency resolution (lines 480-485) and the protection against breaking dependent services (lines 492-497).

Method 2: Using COMPOSE_PROFILES for Installation-Time Configuration

To persist feature selections across reinstallations or to set defaults during initial setup, use the COMPOSE_PROFILES environment variable. This comma-separated list tells the installer which extension categories to activate by default.

Set the variable before running the installation script:

export COMPOSE_PROFILES=voice,rag,workflows
./install.sh

The installer reads this variable and only adds extensions whose profiles match the listed categories. This approach is documented in ods/memory-shepherd/baselines/ods-agent-MEMORY.md (lines 52-53) and demonstrated in ods/.env.example, which contains the default environment variable templates.

To modify profiles after installation, update your .env file and restart the stack, or use the CLI methods described above for granular control of individual services.

Voice and RAG Service Identifiers

To enable or disable specific features correctly, you must know the service IDs that provide those capabilities.

Voice-Related Services

Voice functionality in ODS is provided by several specialized services, each defined in their respective manifest.yaml files:

• whisper — Speech-to-text processing (defined in ods/extensions/services/whisper/manifest.yaml)
• tts — Base text-to-speech service
• piper-audio — Lightweight TTS optimized for local deployment
• xtts — Advanced TTS with voice cloning capabilities
• rvc — Real-time voice conversion for altering speaker characteristics

RAG-Related Services

Retrieval-Augmented Generation requires vector database backends for semantic search:

• qdrant — High-performance vector database (documented in ods/extensions/services/qdrant/README.md as providing RAG capabilities)
• milvus — Distributed vector database for large-scale deployments
• chromadb — Lightweight embedding database for local RAG workflows

You can enable these individually or together to build a complete RAG pipeline:

# Enable complete voice pipeline

ods enable whisper
ods enable xtts

# Enable RAG infrastructure

ods enable qdrant
ods enable llama-server

How the Enable/Disable Mechanism Works Under the Hood

The ODS feature toggle system operates through file-system level manipulation of Docker Compose configurations, orchestrated by the PowerShell core.

File Path Operations

When you run ods enable <service-id>, the Invoke-Enable function in ods/ods.ps1 locates the extension directory and renames compose.yaml.disabled to compose.yaml. Conversely, ods disable renames it back to compose.yaml.disabled. This physical toggling prevents Docker Compose from loading inactive service definitions.

Manifest Resolution

Each extension declares its metadata and dependencies in manifest.yaml. For example, ods/extensions/services/whisper/manifest.yaml (lines 9-29) defines the service category and configuration schema. The CLI parses these manifests to build the dependency graph before enabling services.

Repair and Validation

The enable command supports a repair mode that re-adds missing compose fragments without disrupting running services. The disable command validates that no enabled extensions depend on the target service, referencing the dependency checks implemented in ods/tests/test-windows-cli-enable-disable.sh.

Verification and Status Checking

After enabling or disabling features, verify the system state using built-in status commands and health endpoints.

CLI Status Command

Run ods status to list all extensions and their current state (enabled or disabled):

ods status | grep voice

HTTP Health Endpoints

Individual services expose health endpoints once enabled:

# Check Qdrant vector database (RAG)

curl -s http://localhost:6333/health

# Check Llama Server (LLM for RAG)

curl -s http://localhost:8080/health

Dashboard API

The Dashboard API provides programmatic access to extension status via ods/extensions/services/dashboard-api/. Query /api/extensions/{service_id}/status to check specific feature states from external applications or monitoring systems.

Summary

• ODS uses extension profiles to organize optional features like voice and RAG, controlled via the COMPOSE_PROFILES environment variable or CLI commands.
• Enable features using ods enable <service-id> (e.g., ods enable whisper for voice, ods enable qdrant for RAG), which activates Docker Compose configurations located in ods/extensions/services/.
• Disable features using ods disable <service-id>; the system prevents disabling services that have active dependents to preserve system integrity.
• Service IDs for voice include whisper, xtts, and rvc; RAG capabilities require vector databases like qdrant or milvus.
• Underlying implementation resides in ods/ods.ps1, where Invoke-Enable and Invoke-Disable manage file renaming operations and dependency resolution based on manifest.yaml declarations.

Frequently Asked Questions

What happens if I try to disable a service that other features depend on?

The CLI will block the operation and display a dependency error message. As implemented in ods/ods.ps1 and tested in ods/tests/test-windows-cli-enable-disable.sh, the Invoke-Disable function checks for dependent services before renaming the compose.yaml file, ensuring you cannot accidentally break active voice pipelines or RAG workflows that rely on underlying databases.

Can I enable multiple features at once without typing multiple commands?

While the ods enable command accepts single service IDs, you can batch-enable features by setting the COMPOSE_PROFILES environment variable to include multiple categories (such as voice,rag) before running the installer or restarting the stack. This approach activates all services within those profiles simultaneously.

Where does ODS store the configuration for enabled features?

ODS stores configuration state through filesystem markers—specifically, whether a service's compose.yaml file exists versus compose.yaml.disabled in the extension directory (e.g., ods/extensions/services/qdrant/). The CLI also maintains state through the COMPOSE_PROFILES variable defined in your .env file, which the installer references during startup.

How do I check which voice and RAG services are currently running?

Use the command ods status to view all enabled and disabled extensions. For programmatic monitoring, query the Dashboard API endpoint /api/extensions/{service_id}/status documented in ods/extensions/services/dashboard-api/README.md, or check individual service health endpoints such as http://localhost:6333/health for Qdrant or the specific ports assigned to voice services like Whisper.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}