What Are the 13 Installation Phases in ODS? Complete Guide to the I3 Pipeline

The ODS installer executes 13 sequential Bash phases located in ods/installers/phases/, ranging from pre-flight system checks (Phase 01) through final health validation and summary generation (Phase 13).

The Osmantic Data Stack (ODS) implements a deterministic, reproducible installation pipeline known as the I3 phases (Installation, Integration, Infrastructure). According to the Osmantic/ODS source code, these thirteen modular Bash scripts transform bare metal or virtual machines into fully operational AI development environments through a strictly ordered execution flow from 01-preflight.sh to 13-summary.sh.

Overview of the I3 Installation Architecture

The I3 phase system divides complex system provisioning into discrete, testable units. Each phase resides in ods/installers/phases/ and follows a documented contract specifying what it expects from previous phases and what it provides to subsequent ones.

This modular design enables selective execution for troubleshooting or CI/CD pipelines. Administrators can source individual phases independently using Bash's source command, and environment variables such as DRY_RUN=1 enable non-interactive deployments suitable for automated testing.

The 13 ODS Installation Phases Explained

Phase 01: Pre-flight Validation

File: ods/installers/phases/01-preflight.sh

The pipeline begins with root privilege verification, operating system compatibility checks, and detection of existing ODS installations. This phase aborts immediately if conflicting software or insufficient permissions are detected, preventing partial or corrupted deployments.

Phase 02: Hardware Detection and Tier Assignment

File: ods/installers/phases/02-detection.sh

This phase inventories system resources including GPU availability, RAM capacity, and disk space. Based on detected hardware, it assigns an appropriate performance tier and selects the corresponding Docker Compose configuration from the available stack definitions.

Phase 03: Feature Selection

File: ods/installers/phases/03-features.sh

An interactive menu presents optional capabilities including voice processing, workflow automation, and Retrieval-Augmented Generation (RAG) pipelines. Users toggle features that determine which services start in subsequent phases.

Phase 04: Requirements Validation

File: ods/installers/phases/04-requirements.sh

This phase enforces minimum system requirements against the selected tier. It validates sufficient RAM allocation, available disk space, GPU driver compatibility, and port availability before permitting installation to proceed.

Phase 05: Docker Runtime Installation

File: ods/installers/phases/05-docker.sh

The installer provisions the containerization layer by installing Docker Engine, Docker Compose, and the NVIDIA Container Toolkit when GPU support is required. This ensures the host can execute the ODS service stack.

Phase 06: Directory Structure and Environment Configuration

File: ods/installers/phases/06-directories.sh

This phase creates the required directory hierarchy, copies source configurations, and generates the .env file containing deployment variables. It performs schema validation on the generated environment file to prevent runtime misconfigurations.

Phase 07: Developer Tools Provisioning

File: ods/installers/phases/07-devtools.sh

Specialized AI development utilities including Claude Code, Codex CLI, and OpenCode are installed and configured. These tools provide command-line interfaces for interacting with the deployed large language models.

Phase 08: Docker Image Acquisition

File: ods/installers/phases/08-images.sh

The system builds a manifest of required container images based on selected features, then pulls them from registries to the local Docker daemon. This ensures all services are available before orchestration begins.

Phase 09: Offline Mode Configuration

File: ods/installers/phases/09-offline.sh

For air-gapped or Apple Silicon (M1) deployments, this phase configures offline operation parameters. It prepares the system to function without external internet connectivity during service runtime.

Phase 10: AMD-Specific System Tuning

File: ods/installers/phases/10-amd-tuning.sh

When AMD hardware is detected, this phase applies kernel parameter optimizations through sysctl, modprobe configurations, GRUB boot parameters, and tuned profiles to maximize inference performance.

Phase 11: Core Services Orchestration

File: ods/installers/phases/11-services.sh

The Docker Compose stack defined in earlier phases is instantiated. This phase brings up databases, inference engines, and API gateways in dependency order, establishing the operational service mesh.

Phase 12: Health Checks and Pre-warming

File: ods/installers/phases/12-health.sh

Comprehensive health checks verify all containers report healthy status. The phase pre-warms LLM caches to reduce initial latency and configures Perplexica search integration for the RAG pipeline.

Phase 13: Installation Summary and Validation

File: ods/installers/phases/13-summary.sh

The final phase displays service URLs, creates desktop shortcuts, writes a JSON installation summary to disk, and executes final validation tests to confirm successful deployment.

Executing Individual ODS Installation Phases

The modular architecture allows selective phase execution for debugging or partial upgrades. Each script can be sourced directly using Bash.

# Execute only the pre-flight checks (useful for CI validation)

source "./ods/installers/phases/01-preflight.sh"

# Skip Docker installation and generate final summary only

export SKIP_DOCKER=true
source "./ods/installers/phases/13-summary.sh"

Setting DRY_RUN=1 enables non-interactive execution suitable for automated pipelines, while feature flags like SKIP_DOCKER bypass specific installation steps without breaking the dependency chain.

Phase Contracts and Dependencies

Each phase maintains explicit Expects/Provides contracts documented in script headers. For example, Phase 06 expects Docker to be installed (provided by Phase 05), while Phase 11 requires the directory structure and .env file created in Phase 06.

This contract system ensures phases fail fast with descriptive errors when prerequisites are missing, rather than propagating configuration errors into running services.

Summary

• The ODS I3 pipeline consists of 13 sequential Bash phases housed in ods/installers/phases/
• Phases 01-04 handle detection and validation, ensuring hardware compatibility and feature selection
• Phases 05-10 manage infrastructure provisioning, including Docker, directories, images, and platform-specific tuning for NVIDIA and AMD hardware
• Phases 11-13 execute deployment and verification, bringing services online, pre-warming caches, and confirming health
• Individual phases can be executed independently using source commands for debugging or CI/CD workflows
• The system supports both interactive installations and automated DRY_RUN=1 deployments

Frequently Asked Questions

Can I run specific ODS installation phases independently?

Yes. Each phase is a standalone Bash script that can be sourced directly from the repository root using source "./ods/installers/phases/XX-scriptname.sh". Ensure prerequisite phases have completed successfully, as each script validates its "Expects" contract against the system state before executing.

What happens if my hardware fails the requirements check in Phase 04?

Phase 04 (04-requirements.sh) performs strict validation against tier-specific minimums. If your system lacks sufficient RAM, GPU memory, or available ports, the script exits with a non-zero status and displays the specific deficiency. You must upgrade hardware or select a lower performance tier in Phase 02 to proceed past this gate.

Does ODS support offline or air-gapped installations?

Yes. Phase 09 (09-offline.sh) specifically configures offline mode, particularly for Apple Silicon (M1) Macs and air-gapped environments. This phase prepares the system to operate without continuous internet connectivity, though you must complete Phase 08 (image acquisition) while connected to ensure all container images are cached locally.

How does the installer handle different hardware vendors like AMD versus NVIDIA?

Hardware-specific optimizations occur in targeted phases. Phase 05 installs the NVIDIA Container Toolkit when CUDA GPUs are detected, while Phase 10 (10-amd-tuning.sh) applies AMD-specific kernel optimizations including sysctl parameters and tuned profiles. The detection logic in Phase 02 determines which vendor-specific paths execute during the pipeline.

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