Apache-2.0

KRM/Protobuf/Buf

Pulumi/OpenTofu

CLI-first

CI/CD-ready

Open‑Source Multi‑CloudInfrastructure Framework

Stop learning different tools for every cloud. Write declarative YAML once, deploy to AWS, GCP, Azure, and Kubernetes with the same CLI and workflow. No vendor lock‑in, no artificial abstractions—just consistent infrastructure deployment everywhere.

Define once.Deploy anywhere.

The Multi-Cloud Problem

Deploying the same infrastructure across different clouds means learning completely different tools, CLIs, and workflows

Example: Deploying PostgreSQL

AWS RDS

aws rds create-db-instance \

--db-instance-identifier mydb \

--db-instance-class db.t3.medium \

--engine postgres \

--master-username admin \

--allocated-storage 100

Learn: CloudFormation, IAM roles, Security Groups, Parameter Groups...

GCP Cloud SQL

gcloud sql instances create mydb \

--tier db-n1-standard-1 \

--database-version POSTGRES_13 \

--region us-central1 \

--storage-size 100GB

Learn: Deployment Manager, Cloud IAM, Authorized Networks, Flags...

Azure PostgreSQL

az postgres server create \

--name mydb \

--resource-group mygroup \

--sku-name GP_Gen5_2 \

--storage-size 102400

Learn: ARM templates, Azure AD, Firewall Rules, Server Parameters...

Three different CLIs. Three different terminologies. Three different mental models.

For the same thing: a PostgreSQL database.

The Project Planton Way

Same Structure. Same Workflow. Any Cloud.

AWS RDS

apiVersion: aws.project-planton.org/v1

kind: AwsRdsInstance

metadata:

spec:

engine: postgres

engine_version: "15.4"

instance_class: db.t3.medium

allocated_storage_gb: 100

GCP Cloud SQL

apiVersion: gcp.project-planton.org/v1

kind: GcpCloudSql

metadata:

spec:

database_engine: POSTGRESQL

tier: db-n1-standard-1

Kubernetes

apiVersion: kubernetes.project-planton.org/v1

kind: PostgresKubernetes

metadata:

spec:

container:

replicas: 3

disk_size: "100Gi"

# Same deployment command for all providers:

project-planton apply -f postgres.yaml

Provider-specific configuration (no artificial abstractions), but consistent structure, workflow, and validation across all clouds.

Why ProjectPlanton?

Built for DevOps engineers, platform teams, and infrastructure architects who need consistency across clouds

Consistent across clouds

Same YAML structure across AWS, GCP, Azure, and Kubernetes. Provider-specific fields without artificial abstractions. Every manifest follows the Kubernetes pattern: apiVersion, kind, metadata, spec, status.

Catch errors before deployment

Strongly-typed schemas with field-level validation and sensible defaults. Configuration errors caught immediately with clear messages—before any cloud APIs are called.

Battle-tested modules included

Curated Pulumi and Terraform modules maintained for every component. Choose your preferred execution engine—same manifests work with both. Stop writing raw IaC code.

Production-ready workflow

Complete lifecycle management: preview, apply, refresh, destroy. Stack isolation with org/project/stack namespacing. One CLI for all operations across any cloud.

Security built-in

Standard cloud provider authentication via environment variables. Consistent resource labeling for governance. Native support for cross-resource references.

Fully extensible

Fork and customize any module. Add new components. Generate SDKs from APIs via Buf Schema Registry. Override any field at runtime with --set flags.

Built for Production

A mature, comprehensive framework ready for real-world multi-cloud deployments

100+

Deployment Components

Pre-built, battle-tested modules for common infrastructure patterns

Cloud Providers

AWS, GCP, Azure, Kubernetes, Cloudflare, DigitalOcean, Civo, and more

IaC Engines

Choose between Pulumi or OpenTofu—same manifests work with both

100%

Open Source

Apache 2.0 licensed. All modules, APIs, and CLI are fully transparent

✓Published on Buf Schema Registry

✓Comprehensive Documentation

✓Active Development

✓Community Driven

How It Works

From YAML manifest to deployed infrastructure in five clear steps

Unlike tools that force you to learn different abstractions or write imperative code, Project Planton follows the Kubernetes philosophy: declarative configuration, strong validation, consistent workflow. Whether you're deploying to AWS, GCP, Azure, or Kubernetes, the same five-step process applies.

Parse

Validate

Build

Plan

Apply

Input: YAML Manifest

# example: postgres-on-kubernetes.yaml

apiVersion: kubernetes.project-planton.org/v1

kind: PostgresKubernetes

metadata:

spec:

container:

replicas: 3

disk_size: "100Gi"

Output: Status/Results

# modules export status.outputs

status:

outputs:

namespace: payments-db-main

service: payments-db

kube_endpoint: payments-db.payments-db-main.svc:5432

Get Started in Minutes

Five simple steps to deploy with kubectl-style commands

1. Install

brew install project-planton/tap/project-planton

2. Create manifest with provisioner label

cat > manifest.yaml <<EOF
apiVersion: kubernetes.project-planton.org/v1
kind: KubernetesPostgres
metadata:
  name: my-database
  labels:
    project-planton.org/provisioner: pulumi  # or tofu
spec:
  container:
    replicas: 1
    resources:
      limits:
        cpu: 500m
        memory: 1Gi
EOF

3. Validate

project-planton validate -f manifest.yaml

4. Deploy (kubectl-style! 🚀)

# Auto-detects provisioner from label
project-planton apply -f manifest.yaml

# With field overrides
project-planton apply -f manifest.yaml --set spec.container.replicas=3

5. Destroy (optional)

project-planton destroy -f manifest.yaml

✨ What's New

• kubectl-style commands: Use apply and destroy for all deployments
• Auto-detection: Provisioner automatically detected from project-planton.org/provisioner label
• Interactive prompts: If label is missing, CLI prompts you to choose (defaults to Pulumi)
• Backward compatible: Traditional pulumi and tofu commands still work

Prerequisites

• Provider credentials are read from environment variables (AWS_ACCESS_KEY_ID, GOOGLE_APPLICATION_CREDENTIALS, KUBECONFIG, etc.)
• Pulumi and/or OpenTofu CLI must be installed separately
• Supported provisioners: pulumi, tofu, terraform

Example Gallery

Real manifests from the repo (trimmed for clarity). Replace placeholders like <project-id>.

RDS PostgreSQL Instance

aws-rds-instance.yaml

apiVersion: aws.project-planton.org/v1
kind: AwsRdsInstance
metadata:
  name: payments-db
spec:
  subnetIds:
    - value: subnet-abc123
    - value: subnet-def456
  engine: postgres
  engineVersion: "15.4"
  instanceClass: db.t3.medium
  allocatedStorageGb: 100
  storageEncrypted: true
  username: dbadmin
  password: <secret>
  port: 5432
  multiAz: true

Deploy:

project-planton validate aws-rds-instance.yaml
project-planton apply -f aws-rds-instance.yaml

S3 Bucket

aws-s3-bucket.yaml

apiVersion: aws.project-planton.org/v1
kind: AwsS3Bucket
metadata:
  name: app-assets
spec:
  bucketName: my-app-assets-bucket
  versioningEnabled: true
  encryptionEnabled: true
  publicAccessBlock:
    blockPublicAcls: true
    blockPublicPolicy: true
    ignorePublicAcls: true
    restrictPublicBuckets: true

Deploy:

project-planton validate aws-s3-bucket.yaml
project-planton apply -f aws-s3-bucket.yaml

CLI Reference

Complete command reference for the ProjectPlanton CLI

Primary Commands

project-planton apply -f <manifest.yaml>

Deploy infrastructure (kubectl-style, auto-detects provisioner) 🆕

project-planton destroy -f <manifest.yaml>

Destroy infrastructure (kubectl-style, auto-detects provisioner) 🆕

project-planton plan -f <manifest.yaml>

Preview changes (auto-detects provisioner) 🆕

project-planton init -f <manifest.yaml>

Initialize backend (auto-detects provisioner) 🆕

project-planton refresh -f <manifest.yaml>

Refresh state (auto-detects provisioner) 🆕

project-planton validate <manifest.yaml>

Validate manifest with Buf ProtoValidate

project-planton version

Show CLI version

Validation Example

# Validate a manifest before deployment

project-planton validate manifest.yaml

# Example output:

✓ Manifest validation passed

✓ Buf ProtoValidate rules: OK

✓ CEL expressions: OK

✓ Required fields: OK

Core Flags

Flag	Description	Required
-f, --manifest <path>	path to the deployment‑component manifest file (kubectl-style -f shorthand)	Required
--stack <org/project/stack>	Pulumi stack FQDN (can be in manifest labels)	Optional
--module-dir <dir>	directory containing the Pulumi/Tofu module (defaults to current dir)	Optional
--kustomize-dir <dir>	directory containing kustomize configuration	Optional
--overlay <name>	kustomize overlay to use (e.g., prod, dev, staging)	Optional
--set key=value	override manifest fields (deep dot‑paths supported)	Optional
--auto-approve	skip interactive approval (tofu/terraform commands)	Optional
--yes	auto-approve operations without confirmation (Pulumi)	Optional
--diff	show detailed resource diffs (Pulumi)	Optional

Provider Configuration Flags

Configure cloud provider credentials and settings

--aws-provider-config <file>

AWS provider configuration file

--gcp-provider-config <file>

GCP provider configuration file

--azure-provider-config <file>

Azure provider configuration file

--kubernetes-provider-config <file>

Kubernetes provider configuration file

--confluent-provider-config <file>

Confluent provider configuration file

--mongodb-atlas-provider-config <file>

MongoDB Atlas provider configuration file

--snowflake-provider-config <file>

Snowflake provider configuration file

CI/CD Integration

Deploy your infrastructure automatically with GitHub Actions

GitHub Actions Workflow

name: Deploy with ProjectPlanton
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install ProjectPlanton CLI
        run: brew install project-planton/tap/project-planton

      - name: Install Pulumi & OpenTofu
        run: |
          curl -fsSL https://get.pulumi.com | sh
          echo "$HOME/.pulumi/bin" >> $GITHUB_PATH
          curl -L https://github.com/opentofu/opentofu/releases/latest/download/tofu_linux_amd64.zip -o tofu.zip
          sudo unzip -o tofu.zip -d /usr/local/bin

      - name: Plan
        run: project-planton plan -f infra/manifest.yaml

      - name: Apply
        run: project-planton apply -f infra/manifest.yaml --stack myorg/myproj/prod

Deterministic

Same commands, same results across all environments

Version Controlled

Infrastructure as code with full Git history

Portable

Works with any CI/CD system that supports CLI tools

How Project Planton Compares

Short, factual comparison with other infrastructure tools

vs Cloud Provider CLIs

Their way: Learn AWS, GCP, Azure CLIs separately. Different syntax, mental models, and workflows for every cloud.

Project Planton: One consistent YAML structure and CLI across all clouds. Same workflow everywhere.

vs Kubernetes Controllers

Crossplane: Requires running Kubernetes cluster to manage infrastructure. Controller-based reconciliation.

Project Planton: CLI-driven, runs anywhere. No cluster required. You control when deployments happen.

vs Writing Raw IaC

Terraform/Pulumi: Write imperative code or HCL. Learn provider-specific resource syntax for every service.

Project Planton: Write declarative YAML. The framework maintains battle-tested Pulumi and Terraform modules for you.

Feature Comparison

Feature	ProjectPlanton	Crossplane	Terraform	Pulumi
Declarative YAML	Yes
Multi-cloud consistency	Yes
Strong validation	Yes
Multiple backends	Yes
CLI workflow	Yes
Kubernetes native
Programming languages
Curated modules	Yes

🔍 Complete Transparency

All Pulumi and Terraform modules are open source. No black boxes. Audit the exact code deploying your infrastructure. Fork and customize if needed.

⚡ Your Choice of Engine

Use Pulumi OR OpenTofu as your execution engine. Same manifests work with both. Switch engines anytime. Not locked to one IaC provider.

🔓 Zero Vendor Lock-In

Standalone CLI with zero SaaS dependencies. Your manifests, your credentials, your infrastructure. Runs locally or in your CI/CD. You're never trapped.

Frequently Asked Questions

Everything you need to know about ProjectPlanton

Ready to Get Started?

Install the CLI and deploy your first resource in minutes

$ brew install project-planton/tap/project-planton

Open‑Source Multi‑CloudInfrastructure Framework

The Multi-Cloud Problem

Example: Deploying PostgreSQL

AWS RDS

GCP Cloud SQL

Azure PostgreSQL

The Project Planton Way

Same Structure. Same Workflow. Any Cloud.

Why ProjectPlanton?

Consistent across clouds

Catch errors before deployment

Battle-tested modules included

Production-ready workflow

Security built-in

Fully extensible

Built for Production

Deployment Components

Cloud Providers

IaC Engines

Open Source

How It Works

Parse

Validate

Build

Plan

Apply

Input: YAML Manifest

Output: Status/Results

Get Started in Minutes

✨ What's New

Prerequisites

Example Gallery

Deploy:

Deploy:

CLI Reference

CI/CD Integration

Deterministic

Version Controlled

Portable

How Project Planton Compares

🔍 Complete Transparency

⚡ Your Choice of Engine

🔓 Zero Vendor Lock-In

Frequently Asked Questions

Is this just another abstraction layer that hides cloud-specific details?

Is this locked to a SaaS platform?

Why would I use this instead of just learning Terraform or Pulumi?

What if I need to customize beyond what the modules provide?

Do I need Pulumi/Terraform knowledge to get started?

Which cloud providers are supported today?

How are configuration errors caught before deployment?

Where is infrastructure state stored?

How do credentials work?

Can I run this in CI/CD?

Ready to Get Started?