Architecture

This page describes the overall architecture of the Kite infrastructure-as-code system.

Two-Phase Execution

Kite runs in two strictly separated phases. The CLI hands your source code to the Engine, which delegates evaluation to the Language module — a pure, in-memory step that makes no cloud calls, so errors are caught before anything is provisioned. The Language module returns the resources to create; the Engine then applies them against the providers and persists state, rolling back on failure.

State Management

Kite maintains state in a database (PostgreSQL by default) to track:

• •Resource IDs from cloud providers
• •Resource metadata and configuration
• •Dependency relationships between resources
• •Creation timestamps and current state

This enables operations like kite destroy to know exactly which resources to remove, and allows for safe rollback on failures.

Dependency Resolution

When resources reference each other, Kite automatically builds a dependency graph and creates resources in the correct order using topology sort.

Input Code:
───────────
resource vm web {
    name = "web-server"
    network = net.id
}

resource network net {
    name = "vpc-main"
}

resource loadbalancer lb {
    name = "web-lb"
    backend = web.id
}


Dependency Graph:
─────────────────

      ┌─────────┐
      │ network │ (no dependencies)
      └────┬────┘
           │
           │ net.id
           ▼
        ┌─────┐
        │ vm  │ (depends on network)
        └──┬──┘
           │
           │ web.id
           ▼
    ┌──────────────┐
    │ loadbalancer │ (depends on vm)
    └──────────────┘

Execution Order: [network, vm, loadbalancer]

Provider System

Kite uses a plugin-based provider system built on gRPC. Each provider runs as a separate process and communicates with the engine via protocol buffers.

Custom providers can be built using the kite-provider-sdk and the Gradle plugin for automated documentation generation.