Roadmap

The order is the promise. The calendar is not.

v0 ships pull, plan, apply and a typed client as one release. What comes after is listed below in the order it will be built, with no dates attached.

In v0LaterNot planned
release:v0

What v0 ships.

Four parts, one release. Everything runs on your machine or in your CI against HubSpot's public APIs.

  1. Pull and validate

    In v0

    kalup pull reads a portal into kalup/objects/*.ts, and the app gets its types from those files with no generate step.

    • The packages kalup (the CLI) and @kalup/core.
    • Commands init, pull, validate, ir, fmt and status.
    • Resource types property, group and object (custom object schema).
    • The config reader and canonical writer. The tool parses config and never executes it.
    • Codecs, InferProperties and toCreatePayload, with zero runtime dependencies.
    • pull scoped by config, with --discover for resources outside the scope, and a copy of every overwritten file in .kalup/history/.
    • --json on every command as one envelope/1, and fixed exit codes.

  2. Compare and plan

    In v0

    See what differs between your files and a portal, or between two portals, before anything is written.

    • compare <a> <b>, where each side is a target, a snapshot file or config.
    • plan --target X in the full plan/1 shape, with held fields, expect and counts by risk.
    • A preflight before every plan: account info, tier and headroom, token scopes. A tier gap is blocked with the override that excludes it.
    • snapshot --target X, a full pull saved as a file.
    • docs, a Markdown data dictionary.

  3. Apply

    In v0

    kalup apply writes a reviewed plan to a target, keeps state, and holds drift instead of reverting it.

    • apply, rm and rm --release, bind, state rebuild, target rebind, and plan --take config.
    • State per target in .kalup/state/<target>.json, so a plan can tell your change from someone else's.
    • Resource types pipeline, stage and association, with create, update and remove.
    • Serial writes, destructive steps last, expect re-checked before each write and read back after it.
    • A person at a terminal types the target name and the destructive count. Protected targets accept only saved plans.
    • The CI recipe as documented GitHub Actions steps.

  4. Typed client

    In v0

    @kalup/client reads, writes and searches records, typed by the same files the portal is configured from.

    • createClient with per-object get, create, update, archive, their batch forms, and search.
    • searchAll, an async iterator that restarts past the 10,000-result cap.
    • Default unlabeled associations: listAssociated, associate, dissociate.
    • where operators typed per property kind and checked before sending.
    • Separate rate limiters for search and general calls. Depends on @kalup/core only.
release:next

What comes next.

In no fixed order. Each one builds on the same two JSON contracts, the IR and the plan, so none of them changes how v0 works.

  • Blueprints

    Later

    Versioned JSON fragments added with kalup add, with provenance and blueprint upgrade as a three-way merge that never touches a portal.

  • Runbooks and attest

    Later

    attest and runbook resource types, written in the words of the HubSpot UI.

  • Lists, forms, workflows

    Later

    In that order, each with reads before writes. Workflows sit behind a per-resource flag because the API is beta.

  • generate <language>

    Later

    Native types and codecs from the IR, with no Node at run time. Research points at Python, then PHP.

  • More for the client

    Later

    Typed association labels, upsert by a unique property, and OAuth refresh.

  • Keychain credentials

    Later

    Keys read from the operating system keychain instead of environment variables.

  • MCP server and Claude Code plugin

    Later

    Read-mostly, with apply off by default and never for protected targets.

  • Hosted service

    Later

    For teams that need shared state with locking and history, and scheduled snapshots.

scope:out

Not planned.

Saying what Kalup will not do is part of the roadmap. These are out, not postponed.

  • Record data migration

    Copying values between properties, bulk record edits, seed data. The rename recipe names the steps and stops there.

  • Rebuilding the HubSpot CLI

    Projects, apps, CMS themes, serverless functions, test account creation. Use hs for the app and Kalup for the portal.

  • Claims beyond a runbook

    For assets with no public write API, plan prints the manual steps and attest records that a person did them.

  • rollback, resume and promote

    Recovery is running plan again.

  • Promises about undocumented behaviour

    An unverified HubSpot behaviour stays labelled until a live test settles it.