Hi, since yesterday we have had our deploy hook deployments being blocked. Previously it did not matter if the git author was not in the team, now it seems to.
Was there a change on Vercel’s end here? Cannot see any news/announcement to that effect
Hi, since yesterday we have had our deploy hook deployments being blocked. Previously it did not matter if the git author was not in the team, now it seems to.
Was there a change on Vercel’s end here? Cannot see any news/announcement to that effect
Deployments from private repos already required a team seat, however we have recently closed some gaps in enforcement. Those fixes would affect anyone previously using deploy hooks or the CLI to circumvent the seat requirement.
Thanks for the prompt reply ![]()
I added two members in a Pro Account, but even i cant deploy from bitbucket.
They also want to charge me $20 for each account that uses webhooks from Bitbucket.
Please, i need to run the webhook from Bitbucket as I did previously.
This is really frustrating.
We relied heavily on deploy hooks, and this change has broken an existing workflow without enough warning. Framing it as “closing enforcement gaps” doesn’t change the fact that this is a meaningful product and pricing change for teams using private repos.
I understand the security rationale, but requiring a Vercel seat for commit authors who may only be involved through Git/webhook-driven deploys is a big shift.
At this point I’m seriously considering alternatives, because this creates real operational issues for us.
It’s not expected that commits from Bitbucket would be blocked as long as the commit authors are already on your Pro team. Does the commit metadata match a current team member? Sometimes there are problems if the email address doesn’t match
Yes of course, it matches. But I removed the members so you wouldn’t charge me $20 for each one if it doesn’t work. How can this be fixed?
![]()
I have many of these blocked
Adding our experience here as well. Our team depended on deploy hooks as part of our normal deployment process, and this enforcement change abruptly stopped that workflow from functioning.
The main issue isn’t necessarily the policy itself, it’s that the rollout seems to have happened without prior communication or a migration window. Seat and pricing changes usually need coordination and approval internally, so we had no opportunity to prepare before deployments started failing.
This has already had a real operational impact for us: we currently have an urgent fix ready to go, but we can’t deploy it until we either change our setup or upgrade plans.
For changes that can immediately interrupt production workflows, advance notice or a documented transition period would have been extremely helpful.