How to Deploy a Website with Claude Code (No GitHub)

Build the site, connect Birta as a remote MCP server, authorize it with /mcp, then ask the AI coding agent to publish the built files. A static website can reach a live URL without a GitHub handoff or a second hosting dashboard.

1. Step 1BuildCreate index.html
2. Step 2ConnectAuthorize the Birta MCP
3. Step 3DeployPublish and check the URL

Before you deploy: make sure it is a static site

Claude Code is an AI coding agent, not a hosting service. You can use it to build a website, a React frontend or a full-stack application, and the tool name does not decide which hosting model the result needs. The output does. The same applies to a page built in a Claude conversation, where what a Claude artifact is and is not is worth settling before you treat the preview as a deployment.

A static website works from files a browser can download: a landing page, portfolio, documentation site or client-side calculator usually fits. A web application needs application hosting when it owns authentication, a database, server routes, background jobs or private API keys.

This guide assumes a project. If the folder holds material rather than code, notes and drafts and images with no index.html anywhere, the route is asking the agent to build the pages first.

Ask Claude Code to classify the project before it changes anything:

Inspect this project without changing it. Tell me whether it can run entirely as a static site after a production build. Check for server routes, a database, background jobs, authentication logic, and private server-side environment variables. Also list any local video or PDF the built site needs. End with either "Ready for the Birta static publish workflow" or a clear explanation of what blocks it.

Never copy private keys into JavaScript, because anything shipped to a browser is public. For the full decision rule, read the difference between a simple site and an application.

Step 1: Build the static site

If the site does not exist yet, start from one of the website prompts and come back with the files it produces.

Birta receives finished browser files, not the dev server or the source repo. Run the production build and note the folder it writes into, dist, build, out, whatever the framework uses. That folder needs index.html at its root, with CSS and JavaScript beside it and relative paths preserved. The folder's name means nothing to Birta: what you publish is addressed from the site root.

You do not need to remember whether the project uses npm run build, Vite or Astro. Tell Claude to inspect the package and run its real production command:

Prepare this project for a Birta deployment. First inspect the existing package scripts and framework configuration. Run the correct production build without changing frameworks. Tell me which folder the build writes into and make sure it has index.html at its root. Check that asset and internal-link paths will work from a hosted URL, not only the local dev server. Do not publish yet. Report the build command, the files in the build folder, and any static-hosting blocker.

A working dev server is not proof that the production bundle exists. Check the build folder.

Step 2: Connect Birta to Claude Code

Add the Birta connector as a remote HTTP MCP server from the CLI. Run this inside the project folder for project-only scope:

claude mcp add --transport http birta https://birta.dev/mcp

Use user scope to make the connector available in every project:

claude mcp add --transport http --scope user birta https://birta.dev/mcp

Start the CLI with claude, run /mcp, choose birta and select Authenticate. OAuth opens in a browser: sign in with the emailed one-time code and allow access. There is no key to paste into the repository.

Verify with claude mcp list, or ask Claude to list your projects. Anthropic's Claude Code MCP documentation explains remote HTTP and OAuth, and Birta's Claude Code connection guide is the current command reference. If the acronym is new, here is what MCP is and why it matters. Claude Code can also find the connector itself, by reading the llms.txt file the agent reads first.

Step 3: Publish the Claude Code website

Create a project in the dashboard if needed, then ask the agent to list projects and use the exact name. Every successful publish creates a new version at the same live address.

Use the connected Birta tools to list my projects. Ask me to choose if there is more than one plausible project. Re-check that the build folder has index.html at its root. Publish the built files to the chosen project, images and fonts included with the version description "Initial website publish", addressing every path from the site root: index.html at the root, and nested CSS or JavaScript under the same relative paths as in the build folder. Do not send the build folder name as part of the paths, and do not omit nested files. Return the live URL, version number, preview URL, and every warning exactly as Birta reports them.

Birta validates the package before it changes the live site. A missing entry point or other blocking violation rejects the files and leaves the current version unchanged. Success returns a public URL, a version number and a preview.

Check the live site before sharing it

Publishing does not prove the design, the generated client code, the links and the browser behaviour are correct. Test the live site like a visitor, without your local files or sessions.

1. Open the live site in a private browser window and hard-refresh it.
2. Check the home page and every internal route on desktop and mobile.
3. Click navigation, buttons, mail links, and external links.
4. Confirm that CSS, JavaScript, images, and fonts load without 404 errors.
5. Inspect the browser console and network panel for failed requests.
6. Make sure no private API key or secret appears in the built files.

A missing image or font is usually a path or filename-case problem rather than a transfer problem. A missing video or PDF is expected: those are not served and need a public URL.

Add a custom domain

The first publish is live at the standard project address, which you can share immediately or keep while a branded domain is set up. In the project dashboard, enter a root domain such as example.com or a subdomain such as www.example.com, add the exact DNS record shown, then click Verify.

A root domain uses the displayed A record, a subdomain the displayed CNAME, and with Cloudflare you switch the record to DNS only for verification. The custom-domain guide covers the steps, and what each DNS record does, and why Verify fails covers the part that goes wrong.

Update or roll back without rebuilding the workflow

Iterate in the same local folder. After an edit, build again and publish the built files to the same project, with a description that explains what changed.

Rebuild the static site and verify that the build folder has index.html at its root. Review the diff in the built output. Publish the built files to the same Birta project, addressed from the site root, with the description "Update: [summarize the visible change]". Return the live URL, new version number, preview URL, and warnings. Then list the latest versions so I can see the rollback point.

If the result is wrong, list versions and roll back to the known-good one. That changes which stored version is live without deleting the newer one or touching your local repository.

List the versions of my Birta project, including which one is live. Do not roll back until you show me the choices. After I choose a version, roll back to it and return the live URL and restored version number.

For a small change there is a shorter path: the connected agent can update a live site without redeploying it, editing the one file inside a new version.

Do you still need GitHub, Vercel, or Cloudflare?

You do not need them to move a compatible static website from the coding tool to Birta: no repository connection or build settings screen stands between the finished directory and the live site.

GitHub stays useful for source history, pull requests, backups and team review. Vercel, Netlify and Cloudflare Pages fit when repository-based continuous deployment or wider platform features matter. A server-backed application needs real backend hosting.

Choose from the output: a small static site can use this direct path, while an application or a team-owned repository may need conventional Git and cloud infrastructure. On why the repository path became the default answer for both, see I just want to push index.html.

Common Claude Code deployment problems

Birta reports a missing entry point

The published site has no index.html at its root. Build from the project root, check the folder the build wrote into, and publish its files with the paths taken from that folder rather than with the folder name in front of them.

The development server works, but the build fails

Local development can hide server-only routes or broken production imports. Ask Claude Code to fix the build. If it still needs a runtime, use application hosting.

Images or fonts are missing on the live site

Check paths and filename case. That is almost always the cause. PNG, JPEG, WebP, WOFF and WOFF2 files are published and served like any other asset. PDFs are not served from the site, so link those from a public URL.

Claude cannot see the Birta tools

Run claude mcp list. If birta is disconnected, open /mcp and authenticate again. Confirm that the endpoint matches the current guide and its scope includes this project.

Claude selected the wrong project

Stop before publishing. Run list_projects, compare the names and the addresses, and pass the exact address of the project you meant, because every operation addresses a project by its address, not by its name.

Frequently asked questions