OpenSource: New Terraform Hubspot Provider v0.1.0

Apps Third-Party Apps
,
1

Dear Dev Community!

We just released terraform-provider-hubspot v0.1.0 (open source, MPL-2.0). We built it for pains this community knows well: sandbox→prod deploy can’t promote edits to existing assets, there’s no change history or rollback below Enterprise, and keeping multiple portals in sync is manual work.

The provider brings infrastructure-as-code to HubSpot’s configuration plane: version control, review, terraform plan before anything changes, one-command promotion (including edits), drift detection, and rollback via git. And with AI now you can just work with HubSpot configuration as you do with source code (review, rollback etc)

v0.1.0 has six resources (hubspot_property, hubspot_property_group, hubspot_pipeline, hubspot_object_schema, hubspot_association_label, hubspot_list) plus seven data sources. It works with Terraform and OpenTofu (published on both), and auth is via private-app token (service key is in the works, see below). Portal-specific IDs are resolved by name, so one module works across portals.

Not in scope: CRM records (no contacts or deals in state, by design). Workflows, webhooks, and users are on the roadmap but not shipped yet. This is an early 0.x release.

Want to try it without risk? Import one property group and run terraform plan. Nothing changes in your portal, and you see drift detection on your own config.

Repo: GitHub - revosai/terraform-provider-hubspot: Terraform provider for HubSpot CRM Configuration and Admin · GitHub

The roadmap order is up for debate. If you need workflows-as-code before anything else, open an issue and say so. Rough edges and feedback welcome, here or on GitHub.

Curious what do you think and if we shall continue with it?

Renat

4

Thanks for your feedback and quesiton @Emmytech ,

re:workflows - great idea, we’ll put it as next thing on the roadmap

re:drift - yes, that’s one of the key features from Terraform actually, we do a plan on cron (e.g. github workflows) to detect manual changes and inform us about that - then a decision could be make to ‘adopt’ it and include in the ‘standard’ version

And BTW that is also one aspect - if you already have a HubSpot instance where you want to adopt the revisioned/CICD approach for configuring it you can run the provider to ‘capture’ the existing configuration and then detect changes/apply changes automatically after.