Kalup and HubSpot's tools

The layer above HubSpot's own tools.

HubSpot's tools make changes. Kalup reviews, repeats and records them. It calls HubSpot's public REST APIs directly and is built to be used alongside everything below, not instead of it.

How it works See coverage

Any tool can pour. Kalup keeps the mould and checks the cast.

compare:tools

Use both. Here is where each one fits.

Each of these does its job well. None of them keeps a desired state in a file you can review. That gap is the one Kalup fills.

Tool	What it does well	What it leaves out	How Kalup fits
HubSpot Agent CLIPublic beta since June 2026	Gives an agent create, update and delete over properties, pipelines, custom object schemas, association labels, workflows, saved views and reports, with --dry-run and a blast digest plus --confirm.	It is a primitive. No desired-state file, no diff against a portal, no plan over a whole change set, no targets, no drift detection, no multi-portal.	Kalup is the file and the plan around it. When an agent makes a quick change with the Agent CLI, run kalup pull afterwards and your files catch up.
MCP configuration tools and BreezeOn HubSpot's remote MCP server, properties and pipelines since 15 September 2026	The same kind of change, made from a chat window.	A prompt is not a review. The change lands in the portal with no file, no diff and no plan a person approved.	"AI sets up your portal" is HubSpot's to give away. Kalup adds review, repeatability and rollback for changes, whoever made them.
Sandbox deploy to productionEnterprise only	Moves new assets from a sandbox to production, from the HubSpot UI.	Needs an Enterprise subscription and a Super Admin, runs from the UI only, moves new assets only and cannot push an edit to anything that already exists in production. No API, no rollback. Below Enterprise there is no sandbox at all.	Kalup's compare, plan and apply work between any two portals, including edits. Where a portal's tier lacks a feature, the plan marks that resource blocked and prints the override that leaves it out on that target.
hs CLI and the projects frameworkConfiguration as code for apps and CMS	Apps and CMS assets as code: modules, themes, serverless functions, app cards and app objects.	Nothing Kalup needs to fill. The two cover different ground.	Kalup does not rebuild any of this and never will. Use hs for the app and Kalup for the portal.

HubSpot Agent CLI

Public beta since June 2026

What it does well: Gives an agent create, update and delete over properties, pipelines, custom object schemas, association labels, workflows, saved views and reports, with --dry-run and a blast digest plus --confirm.
What it leaves out: It is a primitive. No desired-state file, no diff against a portal, no plan over a whole change set, no targets, no drift detection, no multi-portal.
How Kalup fits: Kalup is the file and the plan around it. When an agent makes a quick change with the Agent CLI, run kalup pull afterwards and your files catch up.

MCP configuration tools and Breeze

On HubSpot's remote MCP server, properties and pipelines since 15 September 2026

What it does well: The same kind of change, made from a chat window.
What it leaves out: A prompt is not a review. The change lands in the portal with no file, no diff and no plan a person approved.
How Kalup fits: "AI sets up your portal" is HubSpot's to give away. Kalup adds review, repeatability and rollback for changes, whoever made them.

Sandbox deploy to production

Enterprise only

What it does well: Moves new assets from a sandbox to production, from the HubSpot UI.
What it leaves out: Needs an Enterprise subscription and a Super Admin, runs from the UI only, moves new assets only and cannot push an edit to anything that already exists in production. No API, no rollback. Below Enterprise there is no sandbox at all.
How Kalup fits: Kalup's compare, plan and apply work between any two portals, including edits. Where a portal's tier lacks a feature, the plan marks that resource blocked and prints the override that leaves it out on that target.

hs CLI and the projects framework

Configuration as code for apps and CMS

What it does well: Apps and CMS assets as code: modules, themes, serverless functions, app cards and app objects.
What it leaves out: Nothing Kalup needs to fill. The two cover different ground.
How Kalup fits: Kalup does not rebuild any of this and never will. Use hs for the app and Kalup for the portal.

Kalup compares, plans and applies between any two portals you name, edits included. It calls HubSpot's public REST APIs directly.

scope:not

Where Kalup stops.

Saying what a tool will not do is part of saying what it does. These are part of the design, not gaps waiting to be filled.

Not a record data migration tool.Kalup moves configuration, never contacts, deals or any other record. The typed client reads and writes records for your app. It is not a migration engine.
Not a backup for record data.Snapshots capture configuration. A recreated property has no values, and the docs list, per resource type, what a re-apply brings back and what it does not.
Not a replacement for HubSpot's UI.People keep using it. Kalup's job is to notice, hold and reconcile.
No promise beyond a runbook.If HubSpot has no endpoint for something, Kalup prints the steps and records that a person did them. It does not claim to have done them itself.

hs + kalup

Use hs for the app and Kalup for the portal.

Install Kalup Read the docs