Kalup and HubSpot's tools

The layer above HubSpot's own tools.

HubSpot's tools make changes. Kalup records them in files, reviews them as plans, and applies property and group changes to any portal you name. It calls HubSpot's public REST APIs directly and is built to be used alongside everything below, not instead of it.

>_>_>_agent editsyou reviewKALUPFIG. 2 · THE PROMPTSCALE 1:1 · SHEET 2 OF 4
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.

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 a record in your files and a plan to review, whoever made the change.

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 compares any two portals, edits included, plans your files against either, and applies the reviewed plan for properties and property groups. Where HubSpot reports no room left under a limit for a create, 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 any two portals you name, edits included, plans your files against either, and applies property and group changes after a review. It is open source, on npm, and 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. A typed record client for your app is on the later list, and it will not be a migration engine either.
  • Not a backup.A snapshot is a scoped observation of the configuration, with what could not be read listed. It holds no record values, and nothing restores from it.
  • Not a replacement for HubSpot's UI.People keep using it. Kalup's job is to notice their edits and hold them.
  • No promise beyond a runbook.If HubSpot has no endpoint for something, the plan says so. Printing the steps for a person, and recording that they did them, come later. Kalup never claims to have done them itself.
hs + kalup

Use hs for the app and Kalup for the portal.