Deploy

Deployment brings your AI services to production through a streamlined infrastructure layer built on Kubernetes. The InteractiveAI Deployment CLI abstracts away the complexity of container orchestration, allowing you to deploy services without requiring Kubernetes expertise. You define what you want to run, and the platform handles the underlying infrastructure.

Each deployment represents an independent service within your project. You might deploy a news summarization agent that processes daily headlines, a vector store for semantic search, or an MCP server that exposes tools to your AI applications. These services operate independently and can be managed, scaled, and monitored separately through the platform. When your architecture requires coordination, services communicate with each other through dedicated endpoints, enabling you to compose complex systems from discrete, maintainable components.

Why Deployment Matters

AI systems only generate value when they reach production. Traditional deployment workflows require teams to manage Kubernetes manifests, configure networking, and handle scaling policies manually, work that consumes engineering hours without advancing business outcomes. InteractiveAI eliminates this overhead as a managed service, allowing engineers to focus on building AI that delivers results rather than wrestling with infrastructure that adds no value.

You configure your service through simple parameters such as number of CPU cores, RAM allocation, autoscaling behavior, and whether the service needs an external endpoint. Then, the platform provisions everything automatically.

Getting started requires only two things: a Dockerfile that defines your service and the InteractiveAI Deployment CLI. Package your application, run the deployment command, and your service goes live.

The InteractiveAI Deployment CLI

The InteractiveAI CLI (iai) provides terminal-based control over deployments, secrets, and runtime operations. Build images, push them to the platform registry, deploy services, and inspect running workloads without leaving the command line.

The CLI handles the operational surface area of the platform. For tracing, prompt management, and evaluation infrastructure, use the web interface. For deployment automation and CI/CD integration, use the CLI.

What the CLI Does

Command Group	Purpose
iai images	Build and push container images to the project registry
iai services	Create, update, delete, and sync deployed services
iai secrets	Manage runtime credentials and sensitive configuration
iai replicas	List running pod instances behind a service
iai logs	Stream or retrieve logs from specific replicas
iai organizations	List and select the active organization
iai projects	List projects within an organization

Platform Primitives

The CLI operates on five core primitives that map directly to the deployment layer:

• Organization is the top-level tenant boundary. Your account may belong to multiple organizations. Select one as the default to avoid passing it on every command.

• Project scopes all deployment resources. Images, services, secrets, replicas, and logs are project-scoped. Projects typically correspond to environments (dev, staging, prod) or product areas.

• Service defines a deployed workload: which image to run, how many replicas, resource limits, environment variables, secrets, and whether to expose an external endpoint.

• Replica is an individual running instance of a service. Services may have multiple replicas for scaling and availability. Logs are replica-scoped.

• Secret stores sensitive key-value pairs (API keys, database URLs, tokens). Services reference secrets by name; the platform injects them as environment variables at runtime.

The Deployment Chain

A typical deployment follows this sequence:

1. Build the container image from source code

2. Push the image to the project registry

3. Create secrets required for integrations

4. Deploy the service referencing the image and secrets

5. Inspect replicas and logs to verify the deployment

This chain also serves as a debugging checklist. Image build failures surface in step 1. Registry issues appear in step 2. Misconfigurations show in step 4. Runtime crashes appear in step 5 through replica logs.

---

Authentication

The CLI supports two authentication methods:

• Session-based: Run iai login with email and password. The session persists locally until iai logout.

• API key: Pass --api-key to any command for stateless authentication, useful in CI/CD pipelines.

---

Declarative Configuration

The iai services sync command applies a desired state from a YAML configuration file. This enables GitOps-style workflows where the YAML file is the source of truth.

Sync behavior:

• Creates services defined in the config but not in the project

• Updates services that exist in both

• Deletes services that exist in the project but not in the config

This reduces configuration drift and makes environments reproducible across dev, staging, and production.

---

For detailed command reference, flags, and configuration options, see the Deployment CLI Documentation.