विषय-सूची
- 1. "Agent Skills", "MCP" और "Plugin" अलग-अलग चीज़ें हैं
- 2. Vercel के पाँच प्रवेश-द्वार — हर एक क्या करता है और कैसे authenticate होता है
- 3. तीन approaches एक नज़र में
- 4. Approach 1: Git integration (git push पर auto-deploy)
- 5. Approach 2: सीधे editor से (Vercel MCP और Vercel Plugin)
- 6. Approach 3: GitHub Actions (@claude और जाँच-द्वार)
- 7. Preview environments का उपयोग — branch → URL → साझा करना
- 8. चार जाल — env leak, सीमाएँ और लागत, conflicts, rollback
- सारांश
- FAQ
"Claude Code ने fix कर दिया — अब मैं हाथ से push करूँ और browser में Vercel dashboard खोलूँ…" इस आने-जाने को कम करने के लिए Vercel आधिकारिक रूप से तीन tools देता है: Vercel MCP (एक server जिससे AI tools आपके Vercel projects, deployments और logs के साथ काम कर सकते हैं), Vercel Plugin (एक extension जो Claude Code, Cursor आदि में Vercel का ज्ञान और slash commands जोड़ता है) और Agent Skills (npx skills add से install होने वाले निर्देशों के पैकेट)। नाम मिलते-जुलते हैं और भूमिकाएँ आपस में मिलती हुई लगती हैं, इसलिए "Agent Skills को MCP से जोड़ें" जैसी उलझी हुई व्याख्याएँ ख़ूब चलती हैं।
पहले निष्कर्ष: AI agent से Vercel पर deploy को तीन approaches में बाँटकर सोचना मददगार है। ① Git integration (git push → auto-deploy) ज़्यादातर solo काम के लिए काफ़ी है। ② सीधे editor से (Vercel MCP, Vercel Plugin) उनके लिए है जो deploy के आस-पास का काम भी AI को देना चाहते हैं — logs पढ़ना, environment variables संभालना। ③ GitHub Actions + Claude Code Action उन teams के लिए है जो चाहती हैं कि @claude PR comments से सुधार करे और release तभी हो जब tests या approvals पास हों। कोई "सबसे अच्छा" नहीं है — फ़ैसला इस पर है कि आप AI को कितना सौंपते हैं और इंसान उसे कहाँ रोकता है।
यह लेख 30 सितंबर 2026 को Vercel और Anthropic के मूल दस्तावेज़ दोबारा पढ़कर लिखा गया है। Config के उदाहरण, commands और plan की शर्तें उसी तारीख़ की हैं (दोनों तेज़ी से बदलते हैं, इसलिए भरोसा करने से पहले linked pages जाँच लें)। साथ में पढ़ें: AI Vercel की सिफ़ारिश करता है, Cursor क्या है और क्या AI infrastructure संभाल सकता है?।
तीन workflows — अकेले / रोज़ का काम / टीम
— AI को कितना सौंपें, और इंसान उसे कहाँ रोके
कोई भी approach चुनें, आधार एक ही है: preview तक automation, production की मंज़ूरी इंसान दे।
Vercel का अपना MCP दस्तावेज़ भी हमेशा human confirmation चालू रखने की सलाह देता है।
1. "Agent Skills", "MCP" और "Plugin" अलग-अलग चीज़ें हैं
AI code लिख भी दे, तब भी deploy जाँचना दूसरी screen पर होता है: git add . && git commit -m "fix" && git push के लिए terminal पर लौटना, browser में Vercel dashboard खोलना, preview URL copy करके Slack में चिपकाना। इस आने-जाने को कम करने के लिए Vercel ने धीरे-धीरे AI के लिए बने प्रवेश-द्वार जोड़े हैं।
इन्हें समय के क्रम में रखें तो उलझन सुलझ जाती है। 4 अगस्त 2025 को Vercel MCP public beta में आया (Vercel की घोषणा) — यह https://mcp.vercel.com पर चलने वाला OAuth authentication वाला remote MCP server है। उसी महीने, अगस्त 2025 में, Anthropic की Claude Code GitHub Action v1.0 पर पहुँची (v1.0.0 tag की तारीख़ 2025-08-25 है)। 17 मार्च 2026 को Vercel Plugin आया (घोषणा), और 23 जुलाई 2026 से Vercel MCP सीधे code deploy कर सकता है (घोषणा)।
और Agent Skills, MCP नहीं हैं। Vercel का Agent Skills page इन्हें ऐसी packaged क्षमताएँ बताता है जो npx skills add <owner/repo> से install होकर agent को काम करने का एक ख़ास तरीक़ा सिखाती हैं, और ये Claude Code, GitHub Copilot, Cursor समेत 18 से ज़्यादा agents में चलती हैं। अगर MCP आपके account पर काम करने का साधन है, तो Skills काम करने का तरीक़ा हैं। साथ में MCP क्या है और Claude Agent SDK भी देखें।
2. Vercel के पाँच प्रवेश-द्वार — हर एक क्या करता है और कैसे authenticate होता है
ये वे रास्ते हैं जिनसे कोई AI agent Vercel तक पहुँच सकता है, जैसा आधिकारिक दस्तावेज़ बताते हैं (30 सितंबर 2026 की स्थिति)। Authentication वाला कॉलम — यानी आप AI को क्या सौंपते हैं — तय करता है कि दुर्घटना कितनी बड़ी हो सकती है।
| प्रवेश-द्वार | क्या करता है | कैसे जोड़ें | Authentication | शर्तें और सावधानियाँ |
|---|---|---|---|---|
| Git integration (Vercel for GitHub आदि) | हर push पर build और deploy। PR पर preview URL, production का rollback | Dashboard में repository import करें | GitHub App (AI को कुछ नहीं मिलता) | Private repository में commit author के पास Vercel की तरफ़ पहुँच होनी चाहिए |
| Vercel CLI | सब कुछ, जिसमें vercel deploy, vercel env, vercel rollback शामिल हैं | npm i -g vercel | Interactive login; CI में VERCEL_TOKEN | Tokens बहुत ताक़तवर हैं। इन्हें CI secrets में रखें |
| Vercel MCP | Tools बुलाता है: deployments बनाना और सूची देखना, build व runtime logs पढ़ना, env vars संभालना, rollback आदि | अपने client में https://mcp.vercel.com दर्ज करें | OAuth (browser में login करें और तय करें कि किन teams तक पहुँच देनी है) | Beta। सिर्फ़ Vercel द्वारा जाँचे और मंज़ूर clients ही जुड़ सकते हैं। इसे आपके Vercel account जितनी ही पहुँच मिलती है |
| Vercel Plugin | Vercel का ज्ञान (28 skills), 3 विशेषज्ञ agents, 5 slash commands | npx plugins add vercel/vercel-plugin | आपके local Vercel CLI के ज़रिए काम करता है | Node.js 18+ और Bun चाहिए। Claude Code, Cursor, Codex CLI, VS Code आदि में चलता है |
| Agent Skills | ख़ास कामों के निर्देश (जैसे vercel-deploy, vercel-cli) | npx skills add vercel-labs/agent-skills | Skills के पास अपने credentials नहीं होते | असली काम CLI या MCP करते हैं |
स्रोत: Vercel MCP, MCP tools reference, Vercel Plugin, Agent Skills, commits से deploy क्यों नहीं होता (Vercel KB)।
इसे कैसे पढ़ें: अगर सिर्फ़ "deploy हो जाए" चाहिए, तो Git integration काफ़ी है। MCP और Plugin तब काम आते हैं जब आप चाहते हैं कि बातचीत में deploy के आस-पास का काम भी हो जाए — AI से logs पढ़वाकर पता करना कि build क्यों फ़ेल हुआ, env vars का अंतर दिखाना, production को एक क़दम पीछे ले जाना।
3. तीन approaches एक नज़र में
तीनों approaches को AI को क्या मिलता है × automation की गहराई × इंसान कहाँ रोकता है के आधार पर देखें।
| Approach | AI को क्या मिलता है | Automation | इंसान कहाँ रोकता है | किसके लिए सही |
|---|---|---|---|---|
| 1. Git integration | सिर्फ़ git में push की अनुमति | ★★☆☆☆ | main में merge पर | अकेले काम, छोटी teams |
| 2. MCP / Plugin | आपके Vercel account की पहुँच (OAuth) या आपका CLI login | ★★★★☆ | हर tool call की पुष्टि पर | जो logs की जाँच और env प्रबंधन भी AI को देना चाहते हैं |
| 3. Actions | Repository secrets (API key, ज़रूरत हो तो VERCEL_TOKEN) | ★★★★★ | PR review और जाँच-द्वार पर | वे teams जहाँ PR review रोज़ का काम है |
अंगूठे के नियम: अगर deploy के बाद आप अक्सर सिर्फ़ logs पढ़ने के लिए dashboard खोलते हैं, तो ② चुनें। अगर PR review रोज़ का काम है और सिर्फ़ tested बदलाव release करने हैं, तो ③ चुनें। निजी blog या छोटे app के लिए ① काफ़ी है — ज़रूरत से ज़्यादा जटिलता रखरखाव में उससे ज़्यादा ख़र्च करती है जितना बचाती है। तीनों एक-दूसरे को नहीं काटते; आम तौर पर ① आधार होता है और उसके ऊपर ② या ③ जुड़ता है।
4. Approach 1: Git integration (git push पर auto-deploy)
सबसे बुनियादी setup। Vercel को GitHub से जोड़ दें, फिर हर git push पर Vercel build करता है और build पूरा होते ही publish करता है। AI का काम बस code लिखना, commit message लिखना और push करना है। Vercel की अपनी GitHub Actions guide कहती है कि क्योंकि Git integration पहले से preview URLs, न बदलने वाले deployments और instant rollback संभालता है, ज़्यादातर teams को कोई pipeline चाहिए ही नहीं।
# Setup (एक बार)
1. Vercel dashboard → Add New → Project
2. GitHub repository चुनें → Import
3. Framework Preset: अपने-आप पहचान (Next.js आदि)
4. Environment Variables: ज़रूरत के हिसाब से जोड़ें
5. Deploy
# रोज़ का flow (Cursor / Claude Code के अंदर)
> इस button को लाल कर दो। हो जाए तो feature/red-button branch पर push कर दो।
# AI जो commands चलाता है
git switch -c feature/red-button
git add app/components/Button.tsx
git commit -m "feat: change primary button to red"
git push -u origin feature/red-button
# Vercel preview build करता है → PR को preview URL मिलता है
यहाँ असली फ़ायदा यह है कि हर branch को अपने-आप preview URL मिलता है। Vercel के preview URLs दो तरह के होते हैं: branch URL, जो हमेशा उस branch की नवीनतम स्थिति दिखाता है, और commit URL, जो ठीक उसी deployment को दिखाता है (Environments)। अगर production में सिर्फ़ main के merges जाते हैं, तो AI जितनी बार चाहे push करे, सब preview पर ही रुकता है।
सावधानी: Hobby plan सिर्फ़ निजी, ग़ैर-व्यावसायिक उपयोग के लिए है (Hobby plan)। एक दिन में Hobby पर 100 और Pro पर 6,000 deployments बन सकते हैं, और Hobby एक समय में एक ही build चलाता है (Limits)। AI छोटे-छोटे क़दमों में push करे तो सबसे पहले इन्हीं सीमाओं से टकराएँगे। कीमत के जालों के लिए AI Vercel की सिफ़ारिश करता है का §5 देखें।
5. Approach 2: सीधे editor से (Vercel MCP और Vercel Plugin)
अगर deploy के आस-पास का काम भी AI को देना है, तो Vercel MCP या Vercel Plugin इस्तेमाल करें। दोनों में किसी file में token लिखने की ज़रूरत नहीं है।
Vercel MCP का setup (Cursor): आधिकारिक निर्देशों के अनुसार .cursor/mcp.json (project-स्तर या global) में बस एक URL लिखना होता है।
{
"mcpServers": {
"vercel": {
"url": "https://mcp.vercel.com"
}
}
}
जोड़ने के बाद Cursor जुड़ने की कोशिश करता है और Needs login दिखाता है। उस पर click करें, browser में Vercel login होगा और आप चुनेंगे कि Cursor किन teams का उपयोग कर सकता है। Claude Code में यह दो lines का काम है:
claude mcp add --transport http vercel https://mcp.vercel.com
# फिर claude शुरू करें और /mcp से authenticate करें
दस्तावेज़ में npx add-mcp https://mcp.vercel.com भी है, जो एक साथ कई clients में server दर्ज कर देता है। ध्यान रखें: server जोड़ देने से authorization पूरा नहीं होता। जब तक आप login करके किसी team को पहुँच नहीं देते, AI उसके deployments और logs नहीं देख सकता (tools reference)।
MCP tools देता है, slash commands नहीं। आप बस कहते हैं "मेरे latest deployment की errors देखो", और AI ऐसे tools चुनकर बुलाता है (30 सितंबर 2026 की सूची से अंश):
| आप क्या चाहते हैं | Vercel MCP tool |
|---|---|
Deployment बनाना (target छोड़ दें तो preview) | create_deployment |
| Deployments की सूची, स्थिति देखना | list_deployments, get_deployment |
| Build output, runtime logs और errors | list_deployment_events, get_runtime_logs, get_runtime_errors |
| Env vars जोड़ना, बदलना, सूची देखना | create_project_env, edit_project_env, filter_project_envs |
| Production को पिछले deployment पर लौटाना | request_rollback |
| Protected preview के लिए share link | get_access_to_vercel_url |
Vercel Plugin (npx plugins add vercel/vercel-plugin) Vercel का ज्ञान और पाँच slash commands जोड़ता है, जो namespace के साथ आते हैं: /vercel-plugin:deploy (production के लिए prod जोड़ें), /vercel-plugin:env (list, pull, add, remove, diff), /vercel-plugin:status, /vercel-plugin:bootstrap और /vercel-plugin:marketplace (Vercel Plugin)। deploy command की परिभाषा पढ़ने पर दिखता है कि यह आपका local Vercel CLI (vercel, vercel --prod) चलाता है, default रूप से preview बनाता है और production से पहले साफ़ "हाँ" का इंतज़ार करता है। /logs या /rollback जैसे commands नहीं हैं; logs और rollback MCP tools या CLI (vercel rollback) से होते हैं।
असली फ़ायदा यह है कि सब कुछ बातचीत के अंदर ही रहता है। कहें "यह API जोड़ो, preview पर deploy करो, और error आए तो logs पढ़कर ठीक करो", और AI क्रम से code बदलना → deploy → build log जाँचना → सुधार → दोबारा deploy करता है। क्या AI infrastructure संभाल सकता है? की भाषा में यह "सक्षम पर ख़तरनाक" क्षेत्र है। Vercel साफ़ लिखता है कि MCP connection AI को आपके Vercel user account जितनी ही पहुँच देता है, और हमेशा human confirmation चालू रखने की सलाह देता है। Tool calls को auto-approve पर न रखें।
6. Approach 3: GitHub Actions (@claude और जाँच-द्वार)
यह teams का setup है। Claude Code GitHub Actions के साथ आप issue या PR comment में @claude mention करते हैं, और Claude सुधार commit करके उसी thread में जवाब देता है। Preview deploy अब भी Approach 1 का Git integration ही करता है — जैसे ही Claude PR branch पर push करता है, Vercel preview फिर से build कर देता है।
# Setup
1. Claude Code में /install-github-app चलाएँ (सिर्फ़ github.com की repositories)
2. Claude GitHub App install करें; ANTHROPIC_API_KEY (या CLAUDE_CODE_OAUTH_TOKEN) Secrets में रखें
3. .github/workflows/claude.yml एक pull request के रूप में आता है
# .github/workflows/claude.yml (आधिकारिक दस्तावेज़ का उदाहरण)
name: Claude Code
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
jobs:
claude:
if: contains(github.event.comment.body, '@claude')
runs-on: ubuntu-latest
timeout-minutes: 30 # बेक़ाबू jobs रोकें (दस्तावेज़ की सलाह)
permissions:
contents: write
pull-requests: write
issues: write
id-token: write # default GitHub App authentication के लिए ज़रूरी
actions: read # PR पर CI के नतीजे पढ़ना
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 1
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
claude_args: "--max-turns 10" # हर run में turns की सीमा
timeout-minutes और --max-turns उदाहरण के तौर पर जोड़े गए हैं — दस्तावेज़ का "Manage costs" खंड यही दो उपाय सुझाता है (मान अपने project के अनुसार रखें)। Default रूप से turns की कोई सीमा लागू नहीं होती, इसलिए ख़ुद लगाएँ।
अगर आप GitHub Actions से deploy भी करवाना चाहते हैं — सिर्फ़ तब, जब deploy से पहले tests, security scans, performance budget या इंसानी मंज़ूरी चाहिए — तो Vercel की आधिकारिक guide का तरीक़ा अपनाएँ। तीन secrets चाहिए: VERCEL_TOKEN, VERCEL_ORG_ID और VERCEL_PROJECT_ID (आख़िरी दो vercel link से बने .vercel/project.json में होते हैं)।
# .github/workflows/vercel-preview.yml (Vercel KB वाला रूप)
name: Vercel Preview Deployment
env:
VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
push:
branches-ignore:
- main
jobs:
Deploy-Preview:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install --global vercel@latest
- run: vercel pull --yes --environment=preview --token=${{ secrets.VERCEL_TOKEN }}
# tests और scans यहाँ डालें
- run: vercel build --token=${{ secrets.VERCEL_TOKEN }}
- run: vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }}
# vercel.json — Git से होने वाले deploys बंद करें ताकि दो बार deploy न हो
{ "git": { "deploymentEnabled": false } }
वही guide जालों की सूची देती है: Git integration चालू रहे और Actions भी deploy करे, तो एक ही commit पर दोनों चल पड़ते हैं; --prebuilt न लगाएँ तो Vercel वही चीज़ दोबारा build करता है। इसके उलट, अगर सिर्फ़ tests चलाने हैं, तो हल्का तरीक़ा यह है कि Git integration रहने दें, deployment_status event पर preview के ख़िलाफ़ tests चलाएँ, और Deployment Checks से production में promotion रोकें।
# व्यवहार में यह ऐसा दिखता है
# Developer PR खोलता है → Git integration preview build करता है
[Bot] Vercel Preview: https://<preview-url>
# Reviewer PR पर comment करता है
@claude इस button का रंग hover पर भी बदलो
# Claude commit जोड़कर जवाब देता है → Vercel preview दोबारा build करता है
# Reviewer जाँचता है → approve → merge → production deploy
सावधानी: private repositories में commit author का Vercel team का सदस्य (Hobby पर ख़ुद owner) होना ज़रूरी है, वरना कुछ deploy नहीं होता (Vercel KB)। अगर Actions के अंदर बने commits से preview नहीं बनता, तो पहले Vercel Bot का comment और commit author जाँचें।
इस setup से "PR पूरा होने तक कोई इंसान code नहीं छूता" वाला परिदृश्य व्यावहारिक हो जाता है। जैसा अनुभवी बनाम नए और क्या AI white-collar नौकरियाँ ख़त्म करेगा? में लिखा है, team review पर ध्यान देती है और implementation AI करता है।
7. Preview environments का उपयोग — branch → URL → साझा करना
तीनों approaches में जो चीज़ फ़ायदा देती है, वह है preview environments का पूरा इस्तेमाल। Vercel non-production branches और PRs के लिए अपने-आप preview deployments बनाता है, इसलिए बिना किसी अतिरिक्त setup के एक ही बदलाव के कई रूप साथ-साथ रखकर तुलना की जा सकती है।
Preview environments के तीन उपयोग
develop जैसी branch को स्थायी staging बनाएँ। Preview के env vars अलग रखें ताकि production DB कभी न छुए। यह Hobby समेत सभी plans पर चलता है।
Env vars को Development / Preview / Production के लिए अलग-अलग रखा जा सकता है — staging के मान production में न जाएँ।
Hobby पर पूरे account में सिर्फ़ एक share link मिलता है।
स्रोत: Environments (staging के विकल्प और plans), Password Protection (कीमत), Sharable Links (Hobby पर एक), सभी 30 सितंबर 2026 की स्थिति। Password के बिना default सुरक्षा Vercel Authentication है (सिर्फ़ team के सदस्य देख सकते हैं), जिसे Vercel अनुशंसित तरीक़ा बताता है।
8. चार जाल — env leak, सीमाएँ और लागत, conflicts, rollback
Deploy का काम AI agent को सौंपने पर इन चार जालों से टकराना आसान है। हर एक को पहले से किए गए setup से काबू में रखा जा सकता है।
AI agents चलाने के चार जाल
उपाय:
.gitignore में .env*, GitHub Push Protection, AI को निर्देश "कभी git add . मत चलाना", हर tool call की पुष्टि।उपाय: Pro पर Spend Management, AI को निर्देश "आख़िर में एक बार push करना", ग़ैरज़रूरी branches का auto-deploy
git.deploymentEnabled से बंद।उपाय: एक PR = एक issue = एक agent, branch के नाम के नियम, ज़रूरी reviewers तय करने के लिए CODEOWNERS।
उपाय: Instant Rollback का तरीक़ा पहले से तय करें (Hobby पिछले deployment पर लौटता है; Pro और ऊपर कोई भी पुराना production deployment चुन सकते हैं), error monitoring, production के लिए इंसानी मंज़ूरी।
तीन हिस्सों वाली सुरक्षा: Spend Management (Pro) + Deployment Checks + error monitoring।
ज़रूरत पड़ने से पहले ऐसी व्यवस्था बनाएँ कि "बेक़ाबू AI भी घातक नुक़सान न कर सके"।
स्रोत: env vars के MCP tools (get_project_env decrypt किया गया मान लौटाता है), Spend Management (Pro और कुछ Enterprise plans पर बिना अतिरिक्त शुल्क; उपयोग हर कुछ मिनट में जाँचा जाता है, इसलिए रुकने में थोड़ी देर लगती है), Instant Rollback, Git configuration।
अक्सर दोहराई जाने वाली सलाह "Vercel के आगे Cloudflare proxy लगाएँ" को हम सुरक्षा उपाय के रूप में नहीं सुझाते। Vercel एक आधिकारिक KB लेख में लिखता है कि वह आगे बाहरी proxy लगाने की सिफ़ारिश नहीं करता, क्योंकि तब Vercel Firewall को पूरा traffic नहीं दिखता और performance भी घटती है।
एक और सावधानी: हम AI से production deploy को पूरी तरह automate कराने की सलाह नहीं देते। Approach ② और ③ में भी production की अंतिम मंज़ूरी इंसान के पास रखें। जैसा AI को क्या नहीं देना चाहिए में लिखा है, AI बिना किसी बुरी नीयत की ग़लती से भी production तोड़ सकता है। Preview और staging तक automation रखें और production के लिए इंसानी मंज़ूरी माँगें — यह दो-चरण वाला द्वार है।
सारांश
Claude Code या Cursor से Vercel पर deploy के बारे में सोचते समय पहले Git integration, CLI, Vercel MCP, Vercel Plugin और Agent Skills को अलग-अलग पहचानें। MCP OAuth से जुड़ने वाला काम करने का साधन है; Plugin /vercel-plugin:* commands और ज्ञान लाता है; Skills निर्देश हैं। Deploy ख़ुद ज़्यादातर मामलों में Git integration से ही अच्छी तरह हो जाता है।
चुनाव इस पर निर्भर है कि आप AI को कितना सौंपते हैं और इंसान उसे कहाँ रोकता है: ① अकेले काम → Git integration; ② AI से logs की जाँच और env प्रबंधन भी कराना है → Vercel MCP / Plugin (file में token नहीं — OAuth से login); ③ जिन teams में PR review रोज़ का काम है → GitHub Actions (@claude सुधारता है; deploy Git integration से, या जाँच-द्वार चाहिए तो Actions + CLI से)। Previews को A/B तुलना, staging और client review के लिए इस्तेमाल करें, और चारों जालों का सामना tool calls की पुष्टि, सीमा और ख़र्च की सेटिंग, rollback का तरीक़ा और production के लिए इंसानी मंज़ूरी से करें।
संबंधित लेख: AI Vercel की सिफ़ारिश करता है, Vercel AI SDK, v0 vs Bolt vs Lovable, Cursor क्या है और क्या AI infrastructure संभाल सकता है?।
FAQ
प्र. क्या दूसरी hosting (Cloudflare, Netlify) पर भी यही हो सकता है?
उ. हाँ। दोनों आधिकारिक MCP servers देते हैं। Cloudflare OAuth से जुड़ने वाले remote MCP servers की एक सूची चलाता है, जिसमें Workers builds के लिए भी एक है (Cloudflare के MCP servers)। Netlify के पास Netlify MCP Server है। चुनाव agent integration के होने या न होने से ज़्यादा framework के मेल और कीमत पर करें। AI Vercel की सिफ़ारिश करता है के मानदंड भी देखें।
प्र. Vercel पर deploy के लिए Claude Code बेहतर है या Cursor?
उ. दोनों Vercel MCP और Vercel Plugin द्वारा समर्थित हैं, इसलिए Vercel की तरफ़ लगभग एक-सा काम हो सकता है। फ़र्क़ काम करने के ढंग में है: Claude Code terminal-केंद्रित है और इसका GitHub Actions से आधिकारिक integration है; Cursor editor-केंद्रित है और इसमें एक click में MCP जुड़ता है। VS Code में रहते हैं तो Cursor स्वाभाविक लगेगा; terminal में रहते हैं तो Claude Code।
प्र. क्या AI से production deploy पूरी तरह automate करवा सकते हैं?
उ. सलाह नहीं दी जाती। Preview और staging तक automate करें, पर production की अंतिम मंज़ूरी हमेशा इंसान के पास रखें। कारण: AI बिना किसी बुरी नीयत के भी production तोड़ सकता है, और कुछ गड़बड़ होने पर ज़िम्मेदारी धुंधली हो जाती है। GitHub Branch Protection से main पर सीधा push रोकें और मंज़ूर PR अनिवार्य करें।
प्र. क्या .cursor/mcp.json को git में commit कर सकते हैं?
उ. Vercel MCP की आधिकारिक configuration में कोई secret नहीं होता। इसमें सिर्फ़ URL https://mcp.vercel.com होता है; authentication OAuth से होता है और browser की तरफ़ रहता है, इसलिए team के साथ साझा करने के लिए इसे commit करना ठीक है। अगर आपने किसी दूसरे MCP server की API key सीधे header में लिख दी है, तो बात अलग है — वह file git में न डालें। CI में इस्तेमाल होने वाला VERCEL_TOKEN GitHub Secrets में रखें, workflow file में कभी नहीं।
प्र. मुझे GitHub Actions की लागत की चिंता है।
उ. आधिकारिक दस्तावेज़ के अनुसार लागत दो चीज़ों से आती है: GitHub Actions के minutes और Claude API के tokens (subscription वाले OAuth token से authenticate करें तो runs API billing की जगह आपकी Claude subscription से चलते हैं)। हर run की रक़म prompt की लंबाई, काम की जटिलता और codebase के आकार पर निर्भर करती है। दस्तावेज़ में बताए उपाय: claude_args में --max-turns से turns सीमित करें, workflow पर timeouts लगाएँ, @claude से साफ़ और ठोस अनुरोध करें और CLAUDE.md छोटा रखें। Default रूप से turns की कोई सीमा नहीं होती, इसलिए ख़ुद लगाएँ।