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.
Take this scenario: You have 10x developers, 5 of which are Juniors. You keep them focused on features, and they do not get involved with infra or deployments at all.
Vercel is saying that in order for you to deploy their contributions, you now need to pay them an extra $100 and link them as team members.
Imaging running a company that has 20-50 developers, you’d be paying $400-$1000 just for seats to be able to deploy their work!
I agree with others, “closing this gap” when you clearly know your users are using it without any real warning is a sad move when the expectation is these users just need to start paying you more money.
I understand you’re frustrated about the change. Vercel is taking security very seriously and closing any gaps we find to ensure all customers and systems are safe and secure.