Your files.A real place on the web.

Start with the files a browser can use.

A static site is a collection of HTML, CSS, JavaScript and assets that can be served without running a server for every request. A hand-written page is one example. A Vite application, a generated documentation site and a Next.js static export can also be static outputs, even though their source repositories use a package manager.

The useful distinction is the output, not the framework logo. If the build produces an index.html and browser assets, choose the static path. If the app needs request-time server routes or rendering, use a supported server-rendered framework or HTTP application instead.

The archive root matters more than its name.

For a plain HTML upload, index.html belongs at the top of the archive. Zip the contents of the site directory, not an extra parent directory. The console inspects an archive before it uploads it, which gives you a chance to catch an unexpected folder or detected runtime.

site/
├── index.html
├── about.html
├── styles.css
└── assets/
    └── project.webp

For a source build, Fortly looks for an index.html in common output folders: out, dist, build and .output/public. Next.js static exports also honor a configured export directory. An already built upload may also be recognized from _site. Keep your build command responsible for producing a complete, usable output directory.

Do not upload node_modules to a project that needs Fortly to build the source. An archive carrying its dependencies can take the “deploy as received” path. If you want a static build to run consistently, upload source without installed dependencies, or build it elsewhere and upload the finished static site deliberately.

Know which URL should return which page.

A client-side application often has routes such as /projects/launchboard that do not correspond to an HTML file on disk. Fortly gives recognized single-page applications an index.html fallback, so refreshing a client-side route can load the app instead of failing at the server.

A generated multi-page site has a different job: serve real pages and return a real 404 for a path that was never generated. Fortly keeps those cases distinct. The route preview above demonstrates the difference using sample output; it does not send a request to your project.

• Test a nested route by opening it directly in a new tab, not only by clicking an in-app link.
• Test a path that should not exist. A multi-page site should not silently show the homepage for every typo.
• Check links and asset URLs with the final public path, especially if the site was originally built under a subdirectory.

If a route fails, first inspect what the build actually generated and which output directory was published. Adding a server dependency is not a substitute for finding a missing file. The static output reference documents recognition and fallback behavior.

Publish a first page without extra infrastructure.

1. Choose New project → Upload an archive and keep setup open while you prepare the files.
2. Drop the ZIP or tar.gz, confirm its contents and review the source. A plain HTML folder does not need a start command.
3. Choose Create and deploy. For an existing project, use Overview → New deployment and finish with Deploy release.
4. Open the HTTPS address after the release becomes live. For a custom hostname, follow the Domains workspace and verify the DNS record and certificate state.

The console accepts archives up to 256 MB compressed. A release is also checked after unpacking, including its file count and expanded size. A failed or refused release does not replace the current live version. Keep source files and generated artifacts organized so an update can be reproduced.

A static frontend can still use real data.

Your page can call Fortly’s frontend Data API on its own hostname. Create a table in Database, select the role and operations you want to allow, and review the change before applying it. Tables begin closed. A publishable key can appear in frontend code, but its table grants and any row policies determine what the caller can do.

For a static build, public configuration is usually compiled into the output. Give the build the value it needs and rebuild when that embedded configuration changes. Keep an account API token out of generated browser files; it carries account-level authority and belongs only in an appropriate server-side environment.

The next useful step is small: publish one page, verify its routes, then connect one read-only table. You can follow the first-page quickstart and the frontend access guide without changing hosting products halfway through the project.