Claude Code guide

How to host a Claude Code website.

Claude Code can help you build a website; the hosting decision depends on the finished project. This guide shows how to check that a Claude Code project can publish as a supported static website through GitHub and Host Luma.

First, set the boundary

Claude Code is how the site was made, not the runtime it needs.

Host Luma does not rely on a special Claude Code integration. It publishes the static output of a supported website project. That means a Claude Code project is a good candidate when it builds into finished HTML, CSS, JavaScript and assets that work without an always-on application process.

Pause before choosing static hosting if the generated project needs a private API key at request time, a database, user sessions, server-side rendering, a custom Node server, PHP, Docker or background workers. Those are application-runtime requirements, not a problem with Claude Code.

Pre-flight check

Ask Claude Code the useful questions, then verify the answers.

01Find the project root

Use the folder containing the actual website, its package.json if it has one, and its intended source files—not a parent folder full of experiments.

02Run the production build

Ask which command creates the finished website, then run it yourself. A development server is not proof of static output.

03Inspect the output

Check that the result contains the pages and assets visitors need. Common folders are dist, build and out.

04Keep secrets out

Do not commit private API keys, passwords or server credentials. Browser-visible configuration is different from a server secret.

05Commit to GitHub

Push the intended website source to GitHub so the publishing history stays connected to the actual project.

Publish

Use GitHub as the release source for your Claude Code website.

Create an AI Hosting project, choose the repository and confirm the branch that contains the website you tested. Host Luma publishes supported static output and gives the project a permanent HTTPS preview URL. Review the first deployment, the main pages and browser-side integrations before sharing it.

For the next change, make the correction in the repository and publish through the same workflow. This is more reliable than copying files manually because the source, build result and deployment history remain connected.

Common mistakes

Do not let generated code hide a project-fit issue.

If Claude Code created a Next.js, Nuxt or SvelteKit project, check whether it produces a genuine static export. A framework can look like a normal website locally while still requiring server-side rendering after deployment. The supported frameworks reference explains the current static boundaries.

When a build fails, start with the first useful build-log error, reproduce the production build locally and make one focused GitHub change. If the fix requires an always-on server or a private runtime secret, choose a platform that explicitly supports that architecture instead of repeatedly retrying a static deploy.