Infrastructure + IDP

Multi-cloud. Kubernetes-native.
IDP-fronted. Drift-free.

Crossplane-abstracted self-service provisioning, Pulumi-powered automation, and an Internal Developer Platform that gives engineers infrastructure in minutes — while the platform team maintains a single, continuously reconciled source of truth across every cloud and cluster.

Request infrastructure.
Receive infrastructure.

The IDP in FalconIO is the engineer-facing surface of the infra control feature. Engineers interact with a service catalogue — infrastructure intents expressed as operational capabilities, not cloud configuration parameters. Every intent maps to a provisioning engine that enforces policy, registers the result in the shared topology graph, and creates an incident ticket recording the full lifecycle.

1
Service Catalogue
Engineers browse approved intents: PostgreSQL cluster, Kafka namespace, compute environment, object storage, VPN endpoint. Expressed as what they need — not what the cloud calls it.
2
Policy Gate
Every request evaluated against OPA guardrails before provisioning begins. Cost, security, environment-tier, and compliance policies enforced in the workflow — not surfaced three days later as a rejected ticket.
3
Crossplane or Pulumi Execution
Self-service requests execute via Crossplane compositions. Complex bootstrap operations and BC/DR failover execute via Pulumi stacks. The right engine for the right job — transparently to the engineer.
4
Topology Registration
Provisioned resources registered in the CockroachDB topology graph immediately. Observability, BC/DR, and the unified dashboard have context about the new resource before the request is confirmed.
5
Incident Ticket Created
A ticket is created automatically with the provisioning spec, policy check result, resource IDs, topology registration state, and requesting engineer. The audit trail is not a separate workflow — it is the workflow.
The IDP in FalconIO is not a portal bolted onto a provisioning engine. It is the engineer-facing surface of the infra control feature — built on a hybrid of Crossplane and Pulumi, each doing what the other cannot.
IDP Analytics Available
Which intents are requested most — and by which teams
Where policy gates reject requests — and why
Average provisioning time per intent type
Where developer friction is highest in the catalogue
Environment tier usage — dev vs staging vs production
Resource decommission velocity — are resources being cleaned up?
Integrations
Jira Software & Service Management · ServiceNow ITSM · Linear · GitHub Issues · PagerDuty · OpsGenie · Slack

Crossplane + Pulumi.
Complementary, not competing.

The IDP is not built on a single provisioning engine. It is built on a deliberate hybrid of two — each doing what the other cannot, together delivering self-service infrastructure that is developer-friendly, drift-free, and code-quality-tested.

🔄
Crossplane — Kubernetes-Native Steady State

Crossplane exposes infrastructure as Custom Resources — a developer requesting a PostgreSQL cluster submits a Kubernetes manifest, not a cloud console action. Its reconciliation loop continuously compares declared state with actual cloud state and corrects drift automatically, without human intervention.

Crossplane is the right engine when your platform team is GitOps-native. Compositions and XRDs live in Git, delivered via FluxCD, reviewed via pull request, rolled back via revert.

Crossplane Owns:
Self-service IDP provisioning via catalogue
Steady-state reconciliation and drift correction
GitOps delivery of XRDs and Compositions
Multi-cloud abstraction — one XRD, many providers
Kubernetes-native resource visibility via kubectl
⚙️
Pulumi — Code-First Complex Provisioning

Pulumi is the infrastructure-as-code execution layer for everything that Crossplane's YAML-based composition model cannot express cleanly. Complex VPCs, multi-account bootstrapping, conditional configuration, cross-stack dependency resolution — these require imperative logic and modular decomposition.

For a Go-native team, Pulumi in Go means infrastructure code with type safety, IDE completion, unit tests with standard Go testing, and the same code review discipline as application code.

Pulumi Owns:
Bootstrap provisioning — VPCs, accounts, IAM foundations
Complex change management with conditional logic
BC/DR failover execution — imperative, ordered, audited
Cross-account and cross-region operations
Unit and integration tested infrastructure automation
The Division of Responsibility
Scenario Crossplane Pulumi
Developer requests dev database via IDP✓ Executes composition
Bootstrap new AWS account for business unit✓ Executes stack
Drift correction on production database✓ Reconciliation loop
BC/DR failover to secondary region✓ Executes failover stack
Daily self-service provisioning at scale✓ Primary engine
Complex VPC with conditional routing logic✓ Imperative Go code
Multi-cloud steady-state management✓ Provider compositions
Infrastructure unit and integration testing✓ Go test suite
Pulumi provisions the foundation. Crossplane manages the steady state. This is a principled division of responsibility — not a transitional architecture. For a Go-native platform engineering team, this hybrid is the highest-productivity, highest-reliability model available today.

Kubernetes used
at full operational depth.

Network
Cilium CNI + Envoy Gateway

eBPF-native networking, L7 network policy, zero-trust workload isolation, full multi-tenancy. Envoy Gateway for L7 traffic management, advanced routing, and traffic splitting with full observability integration.

Autoscaling
KEDA + Karpenter Intelligence

Event-driven autoscaling tuned by ClickHouse demand analytics — with and without AI-assisted parameter recommendation. Karpenter node provisioning correlated with real workload demand patterns, not worst-case estimates.

Security & Policy
OPA + Kubernetes Security Primitives

Pod Disruption Budgets, Resource Constraints, Pod Security Admission, and Network Policies enforced by default. OPA policy guardrails at provisioning time. Security is not a layer added later — it is the foundation.

AWS
EKS · RDS · MSK · ElastiCache · S3 · DynamoDB
GCP
GKE · CloudSQL · Pub/Sub · Memorystore
Azure
AKS · Azure DB · Service Bus
OCI + On-prem
OKE · On-prem Kubernetes clusters · Edge nodes