TL;DR: Open the project in the Mac IDE, click Deploy β Magic Deploy, pick a target (Vercel / Netlify / Railway / Fly.io / Heroku), paste the API token, click Ship. LingCode handles the build, the env vars, and the post-deploy verification.
Paste a token. Get a live URL. Magic Deploy is the difference between "I built a thing" and "my friends can see the thing" β and the whole gap is filled by the agent reading your project and picking the right hosting target.
Most developers who can build a website cannot, off the top of their head, deploy one. The barrier isn't the act of deployment β it's the layered specificity of every host. Vercel wants a different build command than Netlify, which wants a different one from Cloudflare Pages, which wants a different one from a generic SSH-to-a-droplet. Each host has its own auth flow, its own environment variable conventions, its own way of binding a custom domain. By the time you've decided which host fits the project, you've spent the same energy you'd have spent shipping the first version of the project itself.
Magic Deploy is the assertion that none of this should be your problem. The agent already knows what your project is β it just read your package.json, your vercel.json, your index.html. It can tell that this is a Next.js app or a static HTML one or a Python Flask backend. Given a deploy token, it can pick the right host, generate the right config, and run the right commands without you re-learning the matrix.
The trade-off is the token. You're handing the agent a credential that can deploy things on your behalf. This tutorial walks through the deploy flow itself, but also through the threat model: where the token comes from, where it ends up, and what to do when you want to revoke it. The point isn't to be cavalier β it's to do the deploy without doing the bookkeeping.
Before you generate any tokens, look at your project type. The agent's defaults β which you can override β go roughly like this:
If you're not sure, ask the agent "where should I deploy this?" The answer will be informed by the actual files in your project, not a vague pattern match.
Go to your host's dashboard and create an API token:
~/.ssh/authorized_keys on the server, give LingCode the private key path.The token is the credential. Copy it. We're about to hand it to the agent.
In the chat panel: "Deploy this to Vercel. Token: vercel_xxxxxβ¦"
That's the whole step. The agent reads the token, stores it in your macOS Keychain under the appropriate service name, then picks up the project's settings: framework detection, build command, output directory, env vars from .env.local if present. It runs the host's CLI (or hits the host's API directly) and watches the deploy progress.
You'll see a phase log in the run console: building, uploading, deploying, "live at https://<your-project>.vercel.app." The URL is your live site. The agent doesn't need you again unless something specific needs your attention.
Two common follow-up prompts:
process.env.STRIPE_API_KEY referenced in the code but no .env file. Should I set that on Vercel?" Answer with the value, or set it directly in the host's dashboard. The agent will re-deploy after the env var is in place.yourdomain.com?" If yes, the agent walks you through the DNS records you need to add at your registrar and verifies them once they're in place.Both can also be done after deploy: the live URL works immediately on the host's default domain, and you can wire up env vars or a custom domain whenever.
The token is in Keychain, the project knows its host, the env vars are set. From the second deploy onward: "deploy this" is enough. No re-pasting, no re-configuring. The agent recognizes that the project has been deployed before and reuses the prior setup.
If you want to deploy to a different host or branch, say so explicitly: "deploy this to staging on Vercel" or "deploy the experiment branch to a preview."
When the project is done, or you no longer want LingCode to be able to deploy: