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 talks to clouds through providers. Each provider runs as a separate process, and the engine calls it over gRPC; the built-in Files provider is the exception and runs inside the engine.
Official providers:
- AWS - Amazon Web Services
- Azure - Microsoft Azure
- GCP - Google Cloud
- Files - Local file system operations
How Providers Work explains how providers are installed, started, reused and called, and how to write one with the kite-provider-sdk and its Gradle plugin.