wp CLI

The wp command-line interface is the supported customer command surface for turning an idea into a Webpresso workspace you can launch, operate, and improve. Use it to create the starter, validate the checked-in contract, run local development, deploy the supported starter, and operate the schema/database workflow.

CLI Usage

The CLI owns the supported customer flow. This page stays on the launch path first, then drills into the commands that make that path real:

Terminal

wp --help

Getting Started

The supported happy path is intentionally narrow: one starter, one workspace shape, and one launch story you can take from idea to first live version without detouring through platform-internals.

wp new my-app

Scaffold the supported starter.

ak blueprint new "Launch customer portal" --complexity M

Create the canonical draft blueprint scaffold before refining and executing it.

wp validate

Validate the supported workspace lanes under apps/, packages/, and webpresso/.

wp dev

Run the supported local development workflow for the current workspace.

wp deploy

Publish the workspace through the supported Webpresso deployment flow.

wp schema check

Run the schema validation suite; add --runtime to validate against a live ephemeral GraphQL runtime and schema snapshot.

wp db push

Push database changes through the supported Webpresso database workflow.

wp config codegen

Generate TypeScript config artifacts from checked-in YAML sources.

Schema Scaffolds

Add new checked-in intent files without dropping into older generator plumbing.

wp add entity customer_orders

Create a starter entity definition in webpresso/entities.

wp add workflow onboarding_flow

Create a starter workflow definition in webpresso/workflows.

wp add page customer_portal

Create a starter custom page definition in webpresso/ui/pages.

wp add endpoint customer_webhook

Create a starter endpoint definition in webpresso/endpoints.

wp add job nightly_rollup

Create a starter job definition in webpresso/jobs.

Schema and Database Operations

The grouped operational surface now lives under wp schema, wp db, and wp config.

wp schema compile

Compile checked-in YAML metadata into generated runtime, frontend, and type artifacts.

wp schema codegen

Run the schema codegen pipeline after compile/apply steps.

wp schema apply

Apply metadata, validation, and codegen to the GraphQL runtime.

wp schema check --runtime

Export a live ephemeral schema snapshot, validate operations against it, then run runtime metadata validation against an ephemeral GraphQL runtime and database branch.

wp db migrate

Run database migrations against the active environment.

wp db seed

Seed development or E2E data using the supported profiles.

wp db e2e-prepare

Prepare an E2E database branch with migrations and seed data.

Export & Portability

Every Webpresso project is standard code you own. Use wp export to produce a self-contained project bundle that can be opened in any editor and run with standard tooling — no Webpresso CLI required. The exported bundle includes your customer-owned contract roots (apps/, packages/, webpresso/), all generated artifacts, and an ownership manifest describing exactly what Webpresso managed. Use wp eject for the same output with a stronger declaration of intent to operate fully independently.

wp export --out ./my-app-exported

Export the workspace to a self-contained bundle you can run without the Webpresso CLI.

wp eject --out ./my-app-standalone

Eject the workspace with explicit intent to operate fully independently of Webpresso.

Project Contract

Checked-in customer intent lives in webpresso/. Runnable apps live in apps/. Shared implementation packages live in packages/. Local machine state and generated artifacts live in .webpresso/.

Generated CRUD is a partial supported path: define entity UI in webpresso/entities/, let Webpresso generate the default list/detail/form surfaces, and switch to manual ownership or custom pages when you need bespoke behavior.

Project Layout

your-project/
├── apps/                          # Dev/deploy lane
│   ├── api/                       # API worker app
│   └── web/                       # Web app
├── packages/                      # Shared implementation lane
│   └── ui/                        # Starter shared UI package
├── webpresso/                     # Checked-in customer-owned project contract
│   ├── config.yaml                # Supported project config
│   ├── entities/                  # Data model definitions
│   ├── workflows/                 # Workflow definitions
│   ├── blueprints/                          # Planning and implementation blueprints
│   ├── tech-debt/                           # Tracked follow-up work and debt notes
│   ├── ui/pages/                  # Custom non-CRUD pages
│   ├── actions/                   # Optional supported action metadata
│   ├── events/                    # Optional supported event definitions
│   ├── permissions/               # Optional supported authorization policy
│   ├── seeds/                     # Optional supported seed configuration
│   ├── types/                     # Optional supported source type definitions
│   ├── ui/navigation/             # Optional supported customer navigation
│   ├── endpoints/                 # HTTP handlers
│   └── jobs/                      # Background jobs
└── .webpresso/
    └── generated/
        ├── runtime/               # Generated runtime artifacts
        ├── types/                 # Generated types
        ├── frontend/              # Generated frontend artifacts
        └── .webpresso/generated/.manifest.json         # Tool-owned generated-artifacts manifest

Local State Rules

→Commit webpresso/config.yaml
→Keep deployable apps under apps/ and shared implementation packages under packages/
→Create planning blueprints with ak blueprint new "<goal>" --complexity <size> and keep the generated files in webpresso/blueprints/; track follow-up debt in webpresso/tech-debt/
→Optional supported roots like webpresso/actions/, webpresso/events/, webpresso/permissions/, webpresso/seeds/, webpresso/types/, and webpresso/ui/navigation/ are valid customer inputs when your project needs them
→Keep .webpresso/generated/ out of git
→Treat generated CRUD as a default path, then use generated/manual ownership in entity YAML or custom pages for exceptions

webpresso/config.yaml

Keep project identity and runtime choices in the checked-in config:

webpresso/config.yaml

project:
  name: my-app
  slug: my-app
  version: 1.0.0

functions:
  runtime: nodejs20
  timeout: 30