Connect GitHub
Keep the project source in GitHub. This is the connected provider available in the public workflow.
Static website compatibility reference
Supported frameworks for AI website hosting.
Check whether a website built with Claude Code, Codex, Cursor or another tool can publish as static output through Host Luma. This guide explains the current GitHub workflow, recognised build patterns, output folders and the frameworks that need a different runtime.
Quick answer
Will my project work on Host Luma?
It is a good candidate when it can produce static files: HTML, CSS, JavaScript, images, fonts and browser assets. The framework name alone is not the answer. A Next.js static export can fit; a Next.js application requiring server-side rendering cannot.
Available today: GitHub-connected publishing for supported static projects, supported build-time Node workflows, permanent preview URLs with HTTPS, custom domains, CDN delivery, deployment history and build logs. Planned, not live: rollback, additional Git providers and dynamic runtimes.
Compatibility table
Framework support is about static output, not a logo in package.json.
Fully supported projects match an explicit current build pattern. Usually supported projects have a common static configuration. Requires review means the build output, toolchain or configuration needs checking. Not currently supported projects normally require a server runtime or toolchain outside the public workflow.
| Framework | Supported? | Build output | Typical build command | Notes | Recommended? |
|---|---|---|---|---|---|
| Plain HTML | Fully supported | Repository files | No build required | HTML, CSS, JavaScript and assets publish as static files. | Yes |
| Bootstrap | Usually supported | Static files | None or project build | Fits when the finished site is static. | Yes |
| Tailwind CSS | Usually supported | Static files or dist | npm run build | Generated CSS must be in the publishable output. | Yes, when static |
| Alpine.js | Usually supported | Static files | None or project build | Fits when no server-side application is required. | Yes |
| Vite | Fully supported | dist | npm run build | Recognised by the current build registry. | Yes |
| React with Vite | Fully supported | dist | npm run build | A Vite static build is the relevant supported path. | Yes |
| Create React App | Fully supported | build | npm run build | The registry recognises the react-scripts pattern. | Yes, for existing static projects |
| React, other setups | Usually supported | Usually dist, build, out or public | npm run build | The project must build to a complete static site. | Usually |
| Astro | Fully supported | dist | npm run build | Supported when configured for static output. | Yes |
| Vue CLI | Fully supported | dist | npm run build | The Vue CLI static build pattern is recognised. | Yes |
| Vue + Vite | Fully supported | dist | npm run build | Vite detection covers this static build pattern. | Yes |
| Vue, other setups | Requires review | Varies | Usually npm run build | Confirm static output and actual publish folder. | Review first |
| Next.js static export | Fully supported | out | npm run build | Use static export; server-only features must not be required. | Yes, when exported |
| Next.js SSR | Not currently supported | Server runtime | Not applicable | SSR needs a running Node environment. | No |
| Nuxt static generation | Requires review | Configured static output | Project command | Its output and command need checking first. | Review first |
| Nuxt SSR | Not currently supported | Server runtime | Not applicable | SSR requires a running application runtime. | No |
| Svelte | Requires review | Often dist or build | npm run build | A client-side static build can fit; check output and adapter. | Review first |
| SvelteKit static | Requires review | Often build | npm run build | It must use a static adapter and generate complete files. | Review first |
| SvelteKit SSR | Not currently supported | Server runtime | Not applicable | Server adapters are outside the current workflow. | No |
| Solid with Vite | Fully supported | dist | npm run build | The Vite static pattern is supported. | Yes, when Vite static |
| SolidStart | Not currently supported | Usually server runtime | Not applicable | Treat runtime-dependent SolidStart as dynamic. | No |
| Angular | Requires review | Often nested dist | npm run build | Output structure varies by project. | Review first |
| Eleventy | Requires review | Commonly _site | Project command | Default output is not an explicit current detection path. | Review first |
| Hugo | Requires review | Commonly public | hugo | Public build path is npm-based; use reviewed/prebuilt output. | Review first |
| Jekyll | Not currently supported | Commonly _site | jekyll build | Jekyll normally needs a Ruby toolchain. | No |
| MkDocs | Not currently supported | Commonly site | mkdocs build | MkDocs normally needs a Python toolchain. | No |
| Docusaurus | Requires review | Commonly build | npm run build | It can produce static output but needs dependency/output review. | Review first |
| Gatsby | Requires review | Commonly public | npm run build | Static output is possible; review dependencies and output. | Review first |
Warning: Next.js, Nuxt, SvelteKit and SolidStart are not support answers by themselves. If the project needs request-time code, cookies, server actions, a database or an always-on process, it is not a current AI Hosting fit.
How publishing works
How Host Luma detects your project.
GitHub is the connected project route available today. Host Luma checks whether a repository can publish as static source or follows a recognised frontend build pattern, then validates the output before it is published.
Check the project
Static files can publish directly. Package files, dependencies and configuration help identify recognised frontend builds.
Build static output
Recognised projects use the current npm build path, then need a non-empty static output folder.
Publish and preview
Successful output receives a permanent HTTPS preview URL. Deployment history and build logs remain visible.
Review and iterate
Correct the project in GitHub and use the same route for the next publish.
Choose the right runtime
When a project needs a server process or database, choose hosting that explicitly supports that model.
Private repositories: they can be configured through a per-application deploy-key flow after required access is set up and verified. Organisation-owned repository access needs review and authorisation; it is not a blanket self-service promise.
Before connecting GitHub
Prepare the project before you publish.
A short pre-flight check avoids treating a project-fit problem as a hosting problem after deployment has begun.
- Use a GitHub repositoryKnow which branch contains the version you intend to publish.
- Confirm static outputCheck that the completed site works without an always-on server process.
- Run the production buildFor a framework project, use its normal build command before connecting it.
- Know the output folderCommon names include
dist,build,outandpublic; check rather than assume. - Keep secrets out of sourceDo not commit private keys, passwords or `.env` values that should remain private.
- Test the finished siteCheck key pages, assets, external forms and navigation in the production build.
Tip: test the production build, not only the development server. A development server can hide problems that appear after static output is created. The final static files are the artefact this hosting model needs.
Why some frameworks work
A framework is a fit when it produces files, not when it has a fashionable name.
Plain HTML, Bootstrap and Alpine.js can be excellent fits when the repository already contains a finished static site. There is no application server to keep running.
These commonly use an npm build to create a `dist` directory. The current build registry recognises the Vite, Astro and Vue CLI patterns and uses their static output.
Next.js can be a strong fit when configured to export static files. A project that needs server-side rendering, request-time data or server actions has a different runtime requirement.
Some projects have a build script but are not named framework patterns. Common static output directories can be assessed, but generic does not mean automatically compatible.
A static site can link to a booking tool, form provider or browser-side API. That does not mean Host Luma is hosting the service, API or database behind it.
Long-running Node, PHP, Laravel, WordPress, Docker, queues and databases need a hosting model designed for persistent application services.
Troubleshooting starts with fit
Common build mistakes.
A build can succeed while its files sit in a folder the publishing path does not expect. Do not assume `dist`, `build`, `out`, `public`, `_site` and `site` mean the same thing.
Next.js, Nuxt and SvelteKit can look static while still requiring server-side rendering. Configure and test a real static export before choosing static hosting.
Recognised frontend projects need a usable npm build script. Fix missing dependencies and failed build steps in GitHub before publishing again.
Static output can safely contain only values intended to be public in the browser. A secret needed at request time means the project needs a server-side component.
Test the production build locally. A failed dependency install or unsupported native dependency is a project issue, not a reason to edit server files manually.
Test relative/base paths in the built site. If images, fonts or scripts are missing, inspect the project build and deployment result first.
When a build fails: begin with the framework fit, local production build, expected output directory and deployment result. Make the correction in GitHub, then use the same connected route for the next publish. This keeps source and publishing history connected.
Choose the correct product
When AI Hosting is not the right runtime.
Host Luma AI Hosting is not a general application platform. It is intentionally designed around supported static publishing. The following needs require a different hosting model today.
These need an always-on application runtime and process management.
These need a PHP application runtime and often supporting services.
Use Host Luma Managed WordPress Hosting for WordPress and its PHP/database requirements.
Persistent processes and containers are outside the public static workflow.
Request-time rendering needs a suitable server runtime.
Applications requiring a database service need an appropriate application environment.
Do not force an application into static hosting. A simple interface can still depend on an API, database or server process. For WordPress, choose the Managed WordPress product; for a dynamic application, use hosting that explicitly supports the required services.
Preparing common projects
How to prepare a static site for publishing.
The safe route is to make the production output explicit before you connect GitHub. A project that starts easily in development can still need a different hosting model after you inspect its real build.
Run the project’s normal production build and inspect the generated dist directory. Check that your main pages, images and browser-side navigation work from the built result. Vite is a recognised current static pattern, but your own base-path and asset settings are still part of the project.
Astro is a good fit when it generates static output. Build the project, inspect dist, and check that any integrations do not change the site into a request-time server application. A fast static site can still include external forms or analytics; those services remain separate from the static host.
Use a real static-export configuration, not a development server as a stand-in for production. Next.js documents static export with output: 'export'; a successful build creates an out directory containing static assets. Server actions, dynamic request behaviour and other server-only features do not fit this route.
For Vite-based projects, use the normal build command and inspect dist. For an older Create React App project, inspect build. If a React or Vue project uses a custom server, protected API or process at request time, separate that runtime requirement from the static front end.
Docusaurus, Eleventy, Hugo, Jekyll and MkDocs are all capable of producing static pages, but their normal tools and output folders differ. A framework that produces files is not automatically a supported build contract. Review whether your project needs npm, Ruby, Python, Go or a non-standard output location before treating it as ready.
Claude Code, Cursor, Lovable, Bolt, v0, ChatGPT and Gemini can help create a website. They are not by themselves a hosting compatibility signal or a Host Luma integration. Open the repository, identify the framework, run the production build and check whether the published result can be static.
A useful decision test: if the project can build today, produce a non-empty output directory and work without an application process listening for web requests, it is a sensible static-hosting candidate. If it needs an always-on service, database or private server value, pause and choose the correct runtime instead.
Static versus dynamic
Why the output matters more than the framework name.
A static website is a set of finished files. A dynamic application runs code after a visitor makes a request. Both can use the same front-end framework, which is why compatibility needs more than a framework label.
A landing page built with React can be static when the build creates browser files and all visitor interaction happens in the browser or through an external service. Host Luma can assess that static output.
The same React interface becomes a different hosting requirement if it depends on a custom API, session server, database query or request-time authentication controlled by the application.
Next.js, Nuxt and SvelteKit can all generate static pages in one configuration and require an application runtime in another. Check the real production output, not the development command.
The current workflow gives a successful supported project a permanent HTTPS preview URL. It is useful for review and sharing; it does not turn a server-dependent application into a static site.
Before you choose a host, ask: does a visitor’s request need my own server code to run? If the answer is yes, static publishing is not the complete hosting solution. If the answer is no and the build produces finished files, the project is a strong candidate for this workflow.
Developer FAQ
Answers before you connect a project.
Can I use npm?
Yes. The current supported frontend build path uses npm to install dependencies and run the project build script for recognised projects.
Can I use pnpm or yarn?
They are not currently presented as supported package-manager contracts. Use an npm-compatible project or contact support before relying on pnpm or yarn.
Can I use monorepos?
Monorepos are not a public self-service support promise. The current build starts from the connected repository root, so contact support with the project layout and intended static application before depending on a monorepo workflow.
Can I use private repositories?
Yes, when the application’s deploy-key access is configured and verified. Do not assume a private repository will publish without that access setup.
Can I reconnect GitHub?
Do not assume a self-service reconnect control. Contact support if a repository connection needs to change so access and deployment configuration can be reviewed safely.
Can I redeploy?
The normal re-publish route is to correct or update the project in GitHub and publish the next change. A separate customer-facing manual redeploy control is not part of the public product promise.
Can I delete deployments?
Host Luma does not currently present a customer-facing deployment-deletion control as part of the public workflow. Contact support if you need help with a published project.
Do I get a custom domain or CDN?
Yes. Every AI Hosting project receives a permanent HTTPS preview URL, and you can attach one custom domain per project from the portal with global CDN delivery included.
Accuracy and review
A compatibility reference tied to the live product.
This page describes the public AI Hosting workflow for supported static website projects. It does not claim that AI tools are Host Luma integrations, and it does not present roadmap work as available. Framework statuses follow the current build registry and public product boundaries.
Host Luma support can help with the hosting-side publishing workflow, preview URLs, HTTPS, account access and deployment state. Your code, project configuration, external services and content remain your responsibility. Read the content standards for how public claims are reviewed.
When to ask for help
Contact support before a wrong-fit deployment.
Ask for a review when the project uses a non-npm toolchain, has a non-standard output folder, depends on a monorepo, needs private-repository access or might use server-side rendering. Sharing the framework, build command, output folder and intended published application gives support the information needed to discuss the hosting-side fit clearly.