How to deploy an AI-generated React or Vite site
A working project preview is one step before a publishable site. Ask the assistant for the built files, then test what visitors will receive.
On this page
TL;DR
To deploy an AI-generated React or Vite site on static hosting, build the project into finished browser files and publish the output folder, usually called dist. SayLive needs those built files too: it serves the static result, while server code needs a different host. Check direct page links and refreshes before calling the deployment finished.
Why can the preview work before the site is ready?
The assistant has built a site that looks right in its preview. That confirms progress, but the project folder may still need preparing before an ordinary browser can use its files on a static host.
A build is that preparation step. It turns the source, the files used to develop the site, into HTML, CSS, browser JavaScript and supporting assets. The output is the deliverable for static hosting. Keep the source for later edits, but ask the assistant to identify the output folder separately.
For the React/Vite project in this guide, look for dist and have the assistant confirm the configured output location. The name alone proves nothing: a folder can contain old files from an earlier build. What matters is that the current approved source produced the files you are about to publish.
What should you ask the assistant to do?
Prepare this React/Vite project for static hosting. Inspect its build instructions, identify any server dependencies, run the production build if you can, and confirm the output folder. Check the built output, including images and direct links to inner pages. Keep the approved design. If you cannot run commands, tell me exactly what I must run and do not report an untested build as successful.
A production build means the finished version intended for visitors. Let the assistant read the project instructions instead of guessing a command from the folder name. If it reports an error, ask for the cause and a corrected build before publishing. Uploading half a result makes the next problem harder to diagnose.
Ask whether the assistant executed the build or only described the steps. A suggested command and a completed command are different evidence. You need to know which supports the claim that the files are ready.
How do you get from the project to a live address?
- Confirm the approved pages, images and interactions. Ask the assistant to list anything that requires a server or still uses sample data.
- Have the assistant follow the project’s build instructions. Resolve errors and confirm that the final build completed successfully.
- Identify the output folder, usually dist. Check that it contains the entry page and the scripts, styles and images that page needs.
- Preview that built folder through a local web server, a program that serves the files on your computer. Test it independently of the development preview.
- Publish the contents of the output folder with their folder relationships intact. For SayLive, ask the connected assistant to send those static files.
- Open the live address on a phone and a computer. Follow links, refresh an inner page and test the main contact action.
The publishing guides cover connecting your assistant. If you are working in Cursor, use its publishing guide. The extra step for this project is the build: the assistant must send its finished output, with the entry page at the site root, rather than treat the whole development folder as the website.
Why do inner pages sometimes fail on refresh?
A client-side route is a page address handled by JavaScript in the visitor’s browser. Clicking About might change the address to /about while the same application stays open. But someone opening /about directly asks the host for that address before the application has started. Without a matching file or routing rule, they can get a missing-page error.
These routes need a fallback: an instruction to serve the application’s entry page for its page addresses so the browser can finish opening the right view. Ask the assistant to check the destination’s documented support and configuration. This guide does not assume that SayLive supplies that fallback.
If the destination cannot support the required rule, ask the assistant to adapt navigation or produce actual static pages at those addresses. Then repeat the direct-link and refresh tests. A successful click from the homepage does not test the same path as a visitor arriving through a saved link.
| What you see | What to investigate |
|---|---|
| Homepage works; an inner page fails on refresh | Client-side routing and the host’s fallback support |
| Page opens without images or styling | Missing files or paths that do not match the published folder |
| Live site still shows yesterday’s content | Whether the uploaded output came from the latest build |
| Interface opens; a data action fails | A server dependency or unfinished interaction |
What cannot run on a static host?
Static hosting serves prepared files. JavaScript in those files can still run in the visitor’s browser, so menus and other browser interactions can work. Code that must execute on a server is a separate requirement. Building the visible pages does not turn password checks, database operations or server functions into static files.
SayLive supports HTML, CSS, browser JavaScript and images, with no accounts, databases or server code. Ask the assistant to identify what every important button actually does. If a central feature needs a server, choose a suitable host for the application instead of delivering a working-looking interface with that feature missing.
A completed build confirms that output was produced. It does not establish that every feature will work on the chosen host. Test the built site and the published site.
What should you keep for the next update?
Keep the source project, the build instructions and the approved output together. For the next edit, change the source, build again and publish the new output. Editing only the finished files can leave the source behind, so a later build may replace your correction.
SayLive provides versions and rollback, and any version can be downloaded as a ZIP. Use the documentation for that workflow. An archive of the published files is useful alongside the source project; it does not replace the material needed to rebuild it.
Once the technical checks pass, run the content review. Confirm names, contact details and images as carefully as routes. Visitors receive that published version.
Frequently asked
Can I publish the React source files directly to SayLive?
Build the project first and publish its static output. SayLive serves the finished browser files, not a development environment that builds or runs the source project.
Is the output always called dist?
Confirm the configured output folder with the assistant. Dist is the folder to look for in this workflow, but the project configuration determines what you should publish.
Why does /about work when clicked but fail on refresh?
The browser may handle navigation after the application opens, while the host cannot resolve a direct request for /about. Check the routing fallback or generate a static page for that address.
Does static mean the page cannot be interactive?
No. Browser JavaScript can handle interactions. The limit is code that must run on a server, which static file hosting does not execute.
Do I need to build again after a change?
Yes, when you change the source project. Rebuild and publish the new output so the live files contain the approved edit.