Current release guide

Overview

What Dekaplane is

Dekaplane is a self-hosted AIOps control plane. It gives operators one product surface for AI Gateway routing, governed ChatOps, agent-enabled workflows, tool calling, MCP integrations, observability, and model/provider onboarding.

The current public offer is Free, single-tenant, and self-hosted. The docs below describe the current release package, not speculative future editions.

Package

What Dekaplane includes

Architecture

How Dekaplane works

Dekaplane keeps operational configuration in the control plane and coordinates the runtime services that execute work. Admin changes are made through guided pages and sync-aware workflows instead of one-off runtime edits.

1. Admins onboard providers, model aliases, tools, MCP integrations, ChatOps settings, and agent workflow policy.
2. Dekaplane stores the source-of-truth configuration and tenant-aware policy in the control-plane database.
3. Gateway, tool, ChatOps, and workflow services use that policy when routing requests or executing hosted workflows.
4. Runs emit durable workflow records, trace events, metrics, and optional OpenTelemetry or Langfuse telemetry.

AI Gateway

Gateway management and routing

The AI Gateway lets admins expose local and cloud-backed models through stable aliases. Dekaplane owns the control-plane catalog, provider metadata, alias lifecycle, tenant policy, sync status, and route verification.

• Create tenant-facing aliases for approved models
• Capture provider settings and credentials through guided onboarding
• Sync managed aliases into the gateway routing layer
• Discover or import externally managed aliases without silently overwriting them
• Verify that a route is visible and reachable through the runtime path

ChatOps

Governed ChatOps

Dekaplane's ChatOps runtime is built around a controlled workflow handoff. Slack ingress can arrive through HTTP Events or Socket Mode, then converges into a shared runtime that checks tenant status, approved user access, thread context, model policy, and enabled tools before a hosted workflow runs.

Tools

Tool onboarding and MCP integrations

Dekaplane supports two tool backends: native HTTP tools stored in the control plane, and MCP-backed tools discovered from configured MCP servers. Both are presented as hosted-safe inventory so workflows can select from approved capabilities.

1. Save connection metadata and authentication settings.
2. Verify the connection and discover available tools.
3. Enable selected tools for hosted workflows and, where appropriate, ChatOps exposure.
4. Sync MCP server, access-group, and team permissions for runtime execution.
5. Run quick tests and use routing metadata such as purpose, expected inputs, tags, and examples.

Native HTTP tools execute directly from Dekaplane. MCP-backed tools are discovered, enabled, and governed in Dekaplane, then invoked through the gateway MCP runtime path.

Agents

Agents and workflow foundations

Dekaplane agents are governed workflows, not arbitrary uploaded code. The framework uses versioned blueprints, trigger policy, invoker policy, execution policy, allowed tools, approval gates, and durable run records.

• Blueprint-style workflows with versioned specs
• Trigger types such as API, Slack mentions, webhooks, scheduler, and internal events
• Invoker rules for tenant roles, Slack users, service principals, or admin-only use
• Execution rules for tool allowlists, approval nodes, dry-run defaults, timeout, and retry policy
• Checkpointed runs with trace events, audit records, and resumable approval pauses

Observability

Tracing and debugging foundations

Dekaplane includes durable observability for AIOps workflows. A workflow can involve ChatOps ingress, route selection, tool selection, MCP argument resolution, native or MCP tool execution, gateway calls, fallback behavior, and final response delivery. Dekaplane records that path so operators can debug behavior after the fact.

Providers

Supported model/provider onboarding

The current release focuses on practical local and cloud-backed model flows. The guided onboarding path is designed for fast setup: choose a provider, enter required connection details, create a tenant-facing alias, sync the AI Gateway, and run verification.

• Local OpenAI-compatible or vLLM-style inference endpoints
• Azure OpenAI deployments with endpoint and API-version configuration
• AWS Bedrock models with region-aware provider details
• Alias verification that records route, provider, credential source, visibility, and sync details

Admin

Admin, governance, and controlled updates

Dekaplane is designed so operators make changes through control-plane flows with validation, versioning, sync status, and traceability where those concepts apply. This keeps operational changes more understandable than hand-editing gateway state, tool access, or workflow definitions separately.

• Create and manage model aliases and provider configuration
• Manage native tools, MCP integrations, and enabled tool inventory
• Configure ChatOps runtime access and hosted workflow behavior
• Create governed agent blueprints through constrained builder flows
• Use traces, workflow runs, and audit records for debugging and review

Deployment

Self-hosted deployment and fast onboarding

The public package is built to reduce setup friction for a first self-hosted deployment. The portal provides the release package, license materials, release notes, and install guidance; the installed product then creates its own local tenant-admin identity.

1. Create a free portal account and download the current package.
2. Prepare a supported Linux host with Docker and Docker Compose.
3. Run the included install flow with your license file.
4. Sign in locally with the generated or supplied tenant-admin credentials.
5. Onboard your first model/provider, verify the AI Gateway route, then configure tools or ChatOps as needed.

For later releases, existing installs should use the package `upgrade.sh` flow instead of rerunning first install. The upgrade script validates installed license version bounds before backup or image changes, backs up PostgreSQL through the existing database service without recreating a healthy `db` container, switches target image refs only after backup succeeds, and promotes the active release only after health checks pass.

Under the hood

Technical foundations

Dekaplane is built on concrete control-plane and workflow foundations. These details are here for technical evaluators; day-to-day admins can usually work through the product UI without managing these layers directly.

• LiteLLM powers the AI Gateway routing and provider integration layer beneath Dekaplane.
• LangGraph owns hosted workflow state, node transitions, checkpointing, route selection, and resume behavior.
• LangChain core is used for message and prompt primitives that flow into model calls and selected parsing paths.
• PostgreSQL stores workflow runs, trace events, checkpoints, model/provider catalog state, tools, MCP integrations, and tenant configuration.
• Langfuse and OpenTelemetry are optional observability integrations; durable Dekaplane workflow records remain the primary source of truth.

Limits

Current release limits

• The public offer is Free, single-tenant, and self-hosted.
• Multi-tenant editions and expanded commercial packaging are not part of this public package today.
• Authentication in the installed environment is local login only for the current release.
• Provider support is focused on local OpenAI-compatible endpoints, Azure OpenAI, and Bedrock.
• Observability integrations such as Langfuse and OpenTelemetry are optional and depend on deployment configuration.

Operations

Troubleshooting and maintenance

• If AI Gateway verification fails, confirm provider credentials, model/deployment names, and network access from the host.
• If a ChatOps turn behaves unexpectedly, compare the workflow run, trace event timeline, and Slack thread state.
• If a tool does not run, confirm it is verified, enabled, visible in hosted-safe inventory, and allowed by policy.
• If install startup fails, review release logs and confirm Docker, license files, and host architecture match the package.

For planned maintenance on a deployed x64 host, stop the stack from the active install directory, do your host work, then start it again. Do not remove Docker volumes unless support specifically tells you to reset data.

ENV_FILE=/opt/dekaplane/shared/env/self-hosted.env
sudo docker compose --env-file "$ENV_FILE" -p dekaplane -f /opt/dekaplane/current/compose.yaml ps
sudo docker compose --env-file "$ENV_FILE" -p dekaplane -f /opt/dekaplane/current/compose.yaml down --remove-orphans
# perform maintenance, then:
sudo docker compose --env-file "$ENV_FILE" -p dekaplane -f /opt/dekaplane/current/compose.yaml up -d

If Docker reports stuck containers and a normal compose shutdown does not clear them, remove only the stopped/stuck Dekaplane containers and rerun the install from the extracted release directory. This is for first-install retry or maintenance recovery, not for upgrading an existing healthy install.

sudo docker ps -a --filter "name=dekaplane-"
sudo docker rm -f dekaplane-api-1 dekaplane-worker-1 dekaplane-litellm-1 dekaplane-db-1 2>/dev/null || true

cd ~/dekaplane-setup/dekaplane-selfhosted-<version>
sudo ./install.sh \
  --install-root /opt/dekaplane \
  --mode offline \
  --license-file ~/dekaplane-setup/license \
  --license-public-key ~/dekaplane-setup/license \
  --release-public-key ~/dekaplane-setup/dekaplane-release-public.pem \
  --require-manifest-signature

• Use `uname -m` to confirm the host reports `x86_64` before installing the current x64 package.
• Use `upgrade.sh` instead of `install.sh` when moving a healthy existing install to a newer release.
• Container removal does not delete persistent data by itself; volume or install-root cleanup should be an intentional data-reset step.

If persistent Docker volumes are the suspected cause, use a clean reset only after taking any backup you need. This removes the database/runtime volumes for the Dekaplane compose project and the next install starts with fresh state.

ENV_FILE=/opt/dekaplane/shared/env/self-hosted.env
sudo docker compose --env-file "$ENV_FILE" -p dekaplane -f /opt/dekaplane/current/compose.yaml down --volumes --remove-orphans
sudo docker volume ls --filter "name=dekaplane"

cd ~/dekaplane-setup/dekaplane-selfhosted-<version>
sudo ./install.sh \
  --install-root /opt/dekaplane \
  --mode offline \
  --license-file ~/dekaplane-setup/license \
  --license-public-key ~/dekaplane-setup/license \
  --release-public-key ~/dekaplane-setup/dekaplane-release-public.pem \
  --require-manifest-signature

• This is a data reset path. Existing local product data in Docker volumes can be removed.
• Use it for failed first installs, corrupted local state, or explicit support-directed recovery.
• For a healthy existing install, use `upgrade.sh` rather than resetting volumes.