Prepare the built files your browser needs.
Upload the output of a production build, containing index.html and the files it references. DeployBeacon serves static browser files; it does not run package installation, build commands or a customer server process.
Choose your output directory
| Project | What to upload |
|---|---|
| Plain HTML, CSS and JavaScript | index.html, stylesheets, browser scripts and referenced assets. |
| Vite or a typical React frontend | The production output directory, commonly dist, after running your project's build command. |
| Next.js | A static export, commonly out. Server-rendered pages and API routes need another runtime. |
| Other static site generators | The generated browser files, using the output directory specified by that project. |
Directory names and commands vary by project. Use your build configuration as the source of truth. Put the output files in a ZIP, select it in the dashboard and review the detected document root.
Check asset paths and navigation
Ensure the ZIP contains every local stylesheet, browser script, image and font referenced by its pages. Avoid development-only links such as localhost, file URLs or a local development server. Inspection reports recognized local-reference problems and compatible static-output findings.
Shared platform URLs include a path prefix and use restricted browser storage. Simple HTML asset references are adjusted for that prefix, but a framework router can still assume it lives at the website root. Exercise navigation on the private preview. A verified customer-owned custom domain provides root routing and a normal browser origin.
Next.js static export compatibility
DeployBeacon checks for a known malformed segment-path pattern in Windows-generated Next.js exports and blocks that pattern with a specific finding. It keeps the original uploaded ZIP unchanged. Regenerate the export with a compatible build environment and inspect the replacement; passing that check is not a guarantee that every Next.js feature works as static files.
If your project requires request-time server rendering, middleware, server actions or API routes, export the supported static pages or host the server elsewhere.
Leave private files out
Do not package node_modules, .git, .env, private keys, database dumps or server secrets. Browser JavaScript is public. Public client keys belong in frontend code only when the upstream service explicitly treats them as public and enforces access permissions on its backend.
A recognizable credential finding should be resolved by removing and rotating the exposed credential, then rebuilding. Read what inspection can and cannot prove.
Use static redirects and response headers
Place an optional _redirects or _headers file beside index.html in the selected build output. DeployBeacon inspects a bounded subset of this common static-hosting format before publication. Unsupported or unsafe rules produce a finding to correct; the configuration files themselves are not served as public URLs.
For example, an _redirects file can contain:
# Move an old page /old /new 301 # Carry a named path segment into the destination /blog/:slug /articles/:slug 308 # Serve a browser application under /app /app/* /index.html 200
The first matching redirect rule wins. Supported statuses are 200, 301, 302, 303, 307 and 308; an omitted status means 302. A 200 rule rewrites to a local static file, without running a server or fetching a backend. Existing files and directory indexes take precedence over 200 rewrites, so a final /* /index.html 200 can provide a root-level browser-app fallback while keeping its JavaScript, stylesheets and downloads intact. Local destinations keep the current site's address prefix. External redirects require a fixed HTTPS hostname. A request query is preserved unless the redirect destination supplies its own query.
An _headers file uses a path followed by indented response fields:
/assets/* Cache-Control: public, max-age=86400 X-Build: static /* Content-Language: en-GB
Supported fields include Cache-Control, Content-Language, Content-Disposition, Link, X-Robots-Tag and ordinary custom X-* headers. Project rules cannot change platform cookies, CORS, framing or other protected security headers. Private previews keep their no-store and noindex protections.
Use one named parameter per path segment or a final /* wildcard. Limits include 64 KiB per file, 2,000 bytes per line, 100 redirect rules and 50 header patterns. Host-matching rules, forced ! redirects, backend proxies and paths outside the selected website are unsupported. Test the site's pages and assets on a preview after changing rules.
Can I import a GitHub repository?
Public GitHub import downloads a bounded archive at a resolved commit and applies the same inspection checks. The repository must already contain built browser files. DeployBeacon does not execute its build commands, fetch submodules or Git LFS, or automatically publish later pushes. Build source projects locally and upload the output when needed.
Explore the product and guides
Access is invitation-only. No payments are collected during the private beta. Sign in to your invited workspace.