Plane Compose

Your project's structure: workflows, states, fields, labels, is a first-class artifact. Define it in code and version it in Git. Introducing, the first-ever framework for Projects-as-code.

Read the docs

CLI first

GitOps ready

Built for scale

~/projects/acme

COMPOSE

❯
plane init

? Select workspace › Acme Corp

? Project identifier › sprint-q1

  ✓ Created plane.yaml
  ✓ Created .plane/schema/
  ✓ Created .plane/work/
  ✓ Created .plane/inbox/
  Project scaffold ready. Edit plane.yaml to configure.

See it in action

Watch how Plane Compose transforms project management workflows

Introducing Plane Compose, the implementation layer of Projects-as-Code.

Capabilities

Everything you need to manage projects-as-code

Bootstrap instantly

Initialize a project scaffold with one command. Enforce strict directory structure for predictable automation.

plane init
# Select workspace → Set project key
# Creates:
#   plane.yaml
#   .plane/
#   schema/
#   work/

Schema as YAML

Define states, labels, workflows, types, and custom fields in YAML. Keep everything version-controlled and human-readable.

# schema/workflows/sprint.yaml
states:
  - name: backlog
    color: "#6B7280"
  - name: in-progress
    color: "#3B82F6"
  - name: done
    color: "#10B981"

Push and pull

Sync changes both ways between local files and Plane. Use Git-style operations your team already knows.

plane schema pull   # Fetch remote → local
plane schema push   # Apply local → remote
plane push          # Sync work items
plane pull          # Pull work items

Clone your project

Clone an entire project to disk. Replicate the same configuration across workspaces without rework.

plane clone PROJECT_ID
# Edit plane.yaml → new project name
plane schema push
# → Identical structure, new project

What is Projects-as-code

Every project has two layers: the work and the structure that holds it.

The work includes tasks, issues, and tickets. It changes daily. It is meant to be completed and archived. But a project also accumulates data that should persist. Specs, decisions, templates, intake patterns, recurring checklists, and the context that keeps work understandable over time.

Then there is the structure. Workflows, states, labels, types, and custom fields. Structure defines how your team operates. It is the shape of your process.

Projects-as-code changes this. Your project becomes a set of files that are readable, versionable, and deployable. It lives in Git alongside your code. Changes go through pull requests. You can clone it, diff it, roll it back, and reuse it across projects and workspaces.

The same rigor you apply to your codebase, applied to how projects are defined—and how project context is preserved.

How it works

Four commands to transform your workflow

01

Initialize

Scaffold a strict directory structure with plane.yaml manifest and schema directories.

$ plane init

02

Define

Configure states, labels, workflows, and custom fields in human-readable YAML.

$ vim schema/workflows.yaml

03

Push

Apply your configuration to Plane with interactive confirmation.

$ plane schema push

04

Version

Commit your project configuration to Git. Review changes via pull requests.

$ git commit -am "add workflow"

Why this matters

Project management hasn't caught up to how developers work

$2T

Wasted annually on poor project management

60%

Time spent on "work about work"

28×

Less waste with IaC principles

Start building with Plane Compose

Define your projects declaratively. Version everything in Git.

Start treating project configuration as the infrastructure it is.