🐙 GitHub MCP + Token + Docker
To publish without leaving the editor, connect AntiGravity to GitHub via MCP: this way, you manage and publish repositories directly from there. The integration requires two things: a Personal Access Token (fine-grained, with expiration) and the Docker installed.
✓ Prerequisites
- ✓Personal Access Token fine-grained
- ✓Define a validity for the token
- ✓Docker installed and running
✗ Common mistakes
- ✗Token with no expiration or overly broad scope
- ✗Forget to open Docker first
- ✗Paste the token into the code (use the right place)
of the editor
fine-grained
with expiration
installed
▲ Deploy on Vercel
A Vercel is the GitHub “bridge” to the world: it hosts your app at production. The workflow is short and visual: Add New → Project → import the repo → publish. In just a few clicks, the app is live with a public link.
Add New → Project
In the Vercel dashboard, start a new project.
Import the repo
Connect your GitHub account and select the app repository.
Publish
Vercel builds and deploys the app. Done: it’s live for the world to see.
💡 Localhost × production
In localhost, only you can see. In production (Vercel), anyone with the link can access it. This is the jump from "it works on my machine" to "it's live."
GitHub → world
the repo
public link
a few clicks
🔐 Environment Variables
API keys never should appear in the code. The golden rule: the agent only names the variable; you paste the key inside Vercel (Settings → Environment Variables) and gives Redeploy.
✓ Safe approach
- ✓The agent only names:
API_KEY - ✓You paste the value into Vercel
- ✓Redeploy for the key to take effect
✗ Never do this
- ✗Paste the key into the code
- ✗Upload the key to a public repo
- ✗Send the key in screenshots or chats
| Part | Who takes care of it | Where it lives |
|---|---|---|
| Variable name | the agent | in the code (name only) |
| Key value | you | Vercel → Settings → Env Vars |
| Enable change | you | Redeploy |
the agent
you, on Vercel
activate the key
in the code
📊 Analytics & Speed Insights
Once it’s live, you want to know whether people are using it — and whether the app is fast. Vercel offers Analytics (accesses) and Speed Insights (performance). Enable it in the dashboard and install the package through the terminal (npm). The free plan is generous.
npm i @vercel/analytics @vercel/speed-insights
📈 Analytics
How many visits, where they come from, which pages. Shows whether the app is really being used.
⚡ Speed Insights
Measures the real-world performance users experience. A slow app drives people away — here you can see where to improve.
💡 Data-driven decision
Without data, you guess what to improve. With Analytics and Speed Insights, you focus on what actually affects your users.
in the dashboard
install the package
+ performance
generous plan
🩺 Screenshot-based troubleshooting
When a build fails, don’t panic or try to decipher the error on your own. Take a screenshot of the error logs and send it to the agent: "there was a deployment error, fix it". For errors on the screen, use the DevTools (Console/Network) and send the screenshot.
Capture the error
Screenshot of the build logs in Vercel, or of the Console/Network tabs in DevTools.
Send it to the agent
"There was a deployment error (see screenshot). Fix it." The image provides the exact context.
It fixes it, and you republish
With the error in view, the agent can get the fix right much faster.
🔎 DevTools is your friend
O Console shows code errors; the tab Network shows failed requests. A screenshot of these screens is worth more than a thousand descriptions.
of the logs
with the screenshot
Console/Network
the image helps
💾 Commit Often
A lesson that hurts to learn in practice: commit frequently. Real story—coding 6 hours without committing and lose the best version in a misstep. Version control is your safety net.
✓ Always commit
- ✓With every small step that works
- ✓Short, clear messages
- ✓Each commit = a safe return point
✗ The risk of not committing
- ✗Hours of work in a single fragile block
- ✗One mistake erases the best version
- ✗Without a checkpoint, you start over
⚓ Return points
Think of each commit as a game “save.” If something goes wrong, you can go back to the last save—and never lose more than your latest work.
each step forward
timeline
return point
security
⏪ Rollback
A bad deployment isn’t the end of the world — it’s just a rollback. In Vercel: Deployments → choose the previous stable version → Redeploy. It's literally "going back in time." You can also revert through GitHub.
| Where to | Step | Result |
|---|---|---|
| Vercel | Deployments → stable version → Redeploy | go back in time |
| GitHub | revert to the good commit | undoes the change |
the history
the good version
go back in time
also reverts
💰 API Budget + Private Repo
Two final precautions to help you sleep easy. First: define a budget of API spending so you don’t get a huge bill. Second: make the private repository after publishing, protecting your code.
💰 API Budget
Set a spending limit in your API provider’s dashboard.
- •Helps avoid bill surprises
- •Protects against loops or abuse
🔒 Private Repo
After publishing, change the repository’s visibility to private.
- •Protects your code
- •Reduces the risk of leaked keys
🛡️ Production hygiene
An API budget + private repo + environment variables form the foundation of your app’s security when it’s live. These simple habits prevent costly headaches.
spending limit
on the bill
after publishing
code + keys
🔬 Practical example
Let’s publish the price tracker from Track 2.1 and keep it alive:
- Publish on Vercel — Add New → Project → import the repo → publish.
- Protect the key — the agent names
API_KEY; you paste the value into Settings → Environment Variables and click Redeploy. - Simulate a bad deploy — then make a rollback: Deployments → stable version → Redeploy.
Result: app live, key secure, and peace of mind knowing you can go back in time.
🏋️ Exercise
Take the app you built in 2.1 to the world:
- Publish your app on Vercel and confirm that the link works.
- Protect a key with an env var — name it in the code, paste the value into Vercel, Redeploy.
- Roll back to the previous version and see the app “go back in time.”
Bonus: connect Analytics and set an API budget. In Track 3, you’ll scale production.
⚡ Ready-made prompts
Copy, paste into your AI assistant, and adapt to your use case.
Crie um repositório no GitHub chamado [nome] e publique o projeto atual. Use o GitHub MCP. Não inclua chaves de API no código.
Especifique como a variável de ambiente deve se chamar (ex.: API_KEY); eu forneço a chave dentro da Vercel. Não coloque o valor no código.
Houve um erro no deploy (veja o print). Corrija. Explique em uma frase o que causou e o que você mudou.
✅ Module summary
Next track:
Track 3 — Scale Production