Static sites
Give your marketing site, documentation, or frontend a public home. Ship the output of your build with the same simple workflow as the rest of your app.
Publish what your build produces
Point Shipped at the directory containing your finished HTML, CSS, JavaScript, and other public assets. Keep source files and private configuration outside that output directory. Whether your site is hand-written or generated by a frontend framework, the deployment publishes the files your visitors need without running an application server for every page.
Choose routing that fits the site
A site with a generated HTML file for each route needs different behavior from a browser-rendered single-page application. Configure the appropriate routing so direct links and refreshes work as expected. Preserve real not-found responses for missing pages, and use an application fallback only where the frontend router is meant to handle the request.
Release assets together
Deploy the site’s pages and assets as a versioned release, connect your domain, and serve public files through CDN delivery. Release history gives you a way to restore an earlier compatible site build. If the frontend also calls an API, keep that API’s compatibility and configuration in mind when changing or restoring the frontend.
A little more detail
Questions about Static sites?
Can a static frontend still use a database?
Yes, through an API or another appropriately secured backend. Do not include private database credentials in frontend files: anything delivered to the browser is visible to the visitor.
Should every missing URL return my homepage?
Only if that behavior is required by your single-page application’s router. Generated multipage sites should serve their actual page files and return a not-found response for URLs that do not exist.
From your workspace to the web