How To Deploy A Website With Claude Code

Most people who build something good with Claude Code get stuck at the same place. The site works. It opens in a browser. And it exists only on their laptop, in a folder, visible to nobody. That gap is not a design problem or a coding problem. It is a plumbing problem with a fixed shape you learn once.

There are two platforms in this, and they do two completely different jobs. Confusing them is the reason the whole thing feels harder than it is.

GitHub is where your code lives. Think of it as a drive built specifically for code. It holds the files, and it tracks every change you make, so you can undo anything and see what a file looked like last Tuesday. It also lets other people work on the same code with you. GitHub does not put anything on the internet. A repository is storage, not a website.

The host is the part that makes the site public. In this walkthrough that is Vercel. It reads your code out of GitHub, runs whatever build step your project needs, and serves the result on a real URL with a certificate and a global network behind it. It also watches the repository, so when the code changes the live site changes with it.

There are three honest paths to a live URL, and picking the wrong one costs you hours later rather than now.

• Drag a folder onto a host. Fastest possible first URL, no accounts to link. The tell that it is wrong for you: the second you change anything, you have to drag the folder again, and there is no history to roll back to.
• Connect a Git repository to a host. One setup pass, then every future update is automatic. The tell that it is right for you: you expect to change the site more than once, or you want to be able to undo a bad change.
• Rent a server and configure it yourself. Full control, and full responsibility for certificates, updates, and uptime. The tell that you actually need this: your project runs a long-lived process, a database you manage, or software that will not run on a managed platform.

For a site Claude Code built you, take the Git path. It costs about ten extra minutes on day one and removes every deploy decision you would otherwise make for the rest of the project's life. The drag-a-folder route is only worth it for a one-off page you will never touch again, and those are rarer than people think.

You could do all the GitHub work by hand. There is no reason to. Claude Code can create the repository and push the code for you, but first it needs permission to act on your account, and that permission is a personal access token. Think of the token as a key you cut for one specific tool, with only the doors you chose.

In GitHub, the path is profile photo, then settings, then all the way down to developer settings, then personal access tokens, then the fine-grained kind. Generate a new one and you will be asked to verify with two-factor authentication first. Then three decisions matter:

• Name. Call it what it is, something like Claude Code, so that in six months you know what it belongs to and can revoke it without guessing.
• Expiration. A short window like seven days is the safe default and means you will redo this next week. Never-expire is convenient and permanently dangerous. Pick short unless you have a reason.
• Repository access. Granting access to all repositories saves you from creating an empty repository first, which is the whole point of letting Claude create it for you.

Then permissions. Contents is the one that genuinely matters, because it allows reading and writing code. Metadata is selected for you automatically. Pull requests, commit statuses, and issues are useful if you expect to work the way developers work, and harmless if you do not. Generate the token and copy it, because GitHub will not show it to you again.

There are two ways to hand the token over. You can paste it straight into Claude Code and let it finish the setup, which is fast and fine if you are comfortable with the token passing through a conversation. Or you can place it yourself: open your user account settings, go to developer, click edit config, and the configuration file opens. The GitHub connection block already has a placeholder for the personal access token. Paste it in, save, close the file, and never look at it again. Either way, restart Claude Code afterward, because the connection is read at startup and will not appear until you do. Reopen developer settings and you should see GitHub listed and connected.

Once the connection exists, this is one instruction. Ask Claude Code to push the project to a new GitHub repository and say whether it should be private or public. In the walkthrough the whole push took about a minute, and the repository showed up in GitHub with every file already in place.

Private or public is a real decision, not a formality. Private is the right default for client work, anything with a business idea in it, and anything you have not audited for stray credentials. Public is worth choosing when the code is a portfolio piece you want people to read, or when you want the free tiers and integrations that treat public repositories more generously. You can flip a repository from private to public later, but you cannot unpublish what was already seen.

bash# a minimal .gitignore for a site build
.env
.env.local
node_modules/
dist/
.DS_Store

# confirm nothing sensitive is staged before the first push
git status
git ls-files | grep -iE 'env|secret|key' || echo "clean"

In Vercel, create an account. Use the same email address as your GitHub account if you can, because it makes the connection step a single click. Then choose add new project. If the two accounts have never been linked, you will be offered the link here: allow Vercel access to your GitHub, and your repositories appear in the list.

Click import next to the repository, and for a straightforward site change nothing on the settings screen. Vercel detects what kind of project it is and fills in the build command and output directory itself. Click deploy, wait a few seconds, and you get a confirmation screen and a public URL you can send to anyone.

The settings you would touch, on the rarer occasions you have to, are worth recognizing so they do not intimidate you:

• Root directory. Set this when the site is not at the top of the repository, for example when it sits in a folder called web or site.
• Build command and output directory. Only override these when detection guessed wrong, which shows up as a build that finds nothing to publish.
• Environment variables. Anything your site reads from a .env file locally has to be added here as well, because your .env file was correctly never pushed.
• Node version. Set it to match what you build with locally when you hit a build error that mentions an unsupported syntax or package.

This is the part nobody warns beginners about, and it is where most first deploys stall. Your laptop and the build server are not the same computer, and the differences are specific and predictable.

• Case-sensitive filenames. macOS does not care whether you wrote Hero.png or hero.png. The Linux build server does. This is the classic site where every image is broken in production and perfect locally, and it is the most common first-deploy failure.
• Absolute local paths. Anything pointing at /Users/yourname/ works on your machine and nowhere else. Paths have to be relative to the project.
• Missing environment variables. The build cannot see your .env file, so anything it needs must be re-entered in the host's dashboard, then redeployed.
• Files that were never committed. If an image only exists in your folder and was excluded by .gitignore, the build has no idea it ever existed.
• Hardcoded localhost URLs. A link or an API call pointing at localhost:3000 fails silently for every real visitor.
• A missing rewrite for client-side routing. On a single-page app, the home page loads and every deep link returns a 404 until the host is told to serve the app for all paths.
• Heavy assets. Generated video and full-resolution imagery that load instantly from your own drive can take many seconds over a real connection.

The fix loop is the same for all of them, because the build log tells you exactly which file it could not find. Copy the failing part of the log, hand it to Claude Code, and ask it to fix the cause and push again. The push triggers a new deploy automatically, so you watch the same log until it goes green. Most first deploys need one or two of these passes.

The URL you get for free is real and shareable, and it is also obviously a default. Attaching a domain you own takes a few minutes and one decision about where your DNS lives.

Buy the domain wherever you like, then in your project settings add the domain to the project. The host then tells you which records to create at your registrar. There are two ways to satisfy it:

• Point the nameservers at your host. Simplest, because the host then manages every record for you. The tell that this is right: this domain exists only for this site.
• Keep your registrar's DNS and add individual records. Necessary when the domain is already carrying email, a separate mail provider, or other subdomains you cannot disturb. The tell that this is right: you already have MX records you care about.

The individual records take this shape. Copy the exact values from your own project dashboard rather than from any guide, including this one, because a host can change them and the dashboard is always current.

text# apex domain (example.com)
Type: A      Name: @      Value: <the IP your host shows you>

# www subdomain
Type: CNAME  Name: www    Value: <the hostname your host shows you>

# check what the internet currently believes
dig example.com +short
dig www.example.com CNAME +short

Two things about domains surprise people. First, propagation is real but it is usually minutes, not days, and the horror stories about 48 hours mostly come from records that were entered wrong rather than slow. If the dig command still shows the old answer after an hour, check the record, do not wait longer. Second, HTTPS is handled for you. The certificate is issued automatically once the records resolve, and you do not buy, install, or renew anything.

This is the part of the walkthrough worth pulling out, because it generalizes far past one product site. Once the repository is connected, you never deploy again on purpose. You change code, you push, and the live site updates itself. Deploying becomes a consequence of saving your work rather than a separate task you schedule and worry about.

That changes what you can safely do. Three habits open up as soon as the pipeline exists:

• Ship small and often. When a change takes seconds to reach production, there is no reason to batch a month of edits into one terrifying release.
• Use a branch to try things. A push to a branch that is not your main one gets its own private preview URL, so you can see the change on a real device before it touches the public site.
• Roll back instead of debugging under pressure. Every deploy is kept, so a bad change is undone by promoting the previous deploy back to production, in seconds, while you work out the actual fix calmly.

That last one is why the Git path is worth the ten extra minutes. The value is not the first deploy. The value is that the hundredth deploy is just as boring as the first, and that a mistake in production is a button press away from being over.

Read this list before your first deploy rather than after it. Every one of them costs somebody an evening the first time.

• Building the project in a folder that already contains something else. Start in a new, empty folder so the repository maps cleanly to one site.
• Forgetting to restart after connecting GitHub, then concluding the connection failed when it simply had not loaded yet.
• Losing the token. It is shown once. If you did not copy it, generate a new one instead of hunting for the old one.
• Committing a .env file, which is how credentials end up public. Write .gitignore first.
• Setting a token to never expire on an account with access to everything you own.
• Assuming a green build means a working site. Open the production URL yourself, on a phone, and tap through it.
• Only testing the desktop view. Most visitors arrive on a phone, and layout problems that never appear on your monitor appear immediately there.
• Treating the free URL as temporary and never attaching a domain, then sharing a link that undercuts everything the site is trying to say.

The shortest honest sequence from reading this to having a URL you can send someone. Budget about an hour for your first run, and roughly five minutes for every one after it.

1. 1Create a new empty folder for the project and put any reference material you have, such as a product photo, inside it before you start.
2. 2Build the site with Claude Code and open it locally until you are happy with it.
3. 3Generate a fine-grained GitHub personal access token with contents permission, a short expiration, and access to all repositories. Copy it.
4. 4Connect Claude Code to GitHub, place the token in the config, and restart the app. Confirm the connection appears in developer settings.
5. 5Write a .gitignore, check that no keys or .env files are staged, then ask Claude Code to push the project to a new repository and say private or public.
6. 6In your host, add a new project, allow access to GitHub, import the repository, change nothing, and deploy.
7. 7Open the production URL on your phone. Tap every link and submit any form.
8. 8If the build failed or anything is broken, copy the first red line of the log to Claude Code, let it fix and push, and watch the redeploy.
9. 9Add your domain, create the two DNS records the dashboard gives you, and confirm both the apex and www resolve.

Do that once and the knowledge transfers completely. The second site is the same nine steps with the token setup already done, which is why it takes minutes.

This path covers most of what people build with Claude Code: marketing sites, product pages, portfolios, microsites, small apps that talk to an outside service. It has edges, and knowing them saves you from forcing a project into the wrong shape.

• You need a database. That is a separate service you connect to, not something the host stores for you. Add a managed database and keep the deploy pipeline exactly as it is.
• You need a process that runs continuously, such as a bot that stays connected. Serverless functions have time limits, so use a platform built for long-running processes for that piece.
• You are attached to a specific stack that expects a traditional server, such as a classic PHP or WordPress setup. Host it where that stack is native.
• Your traffic and bandwidth are large enough that usage-based pricing matters. Read the pricing before you scale into it rather than after.

None of those change the first half of this guide. The GitHub half is the durable part, and it is the same regardless of who ends up serving your site. Learn the repository and token workflow properly once, and swapping hosts later becomes an afternoon rather than a rebuild.

Every step above is yours to run by hand, and running it by hand once is how the pipeline stops feeling like magic and starts feeling like a habit.