Static sites
Publish a frontend or content site as versioned HTML, CSS, JavaScript, and other assets.
A static site serves files produced by your build. Use it for a Vite frontend, a Next.js static export, a documentation site, or plain HTML. Server-side code, database drivers, and background processes belong in a web service or worker.
Deploy a static site
- Create a Static Site in your project.
- Connect the repository and select its branch and root directory.
- Confirm the build command and Publish directory.
- Add any public build-time configuration, then deploy.
- Open the service URL and test both the homepage and a nested route.
| Project | Typical build command | Publish directory |
|---|---|---|
| Vite | npm run build | dist |
Next.js with output: 'export' | npm run build | out |
| Astro with static output | npm run build | dist |
| Create React App | npm run build | build |
| Plain HTML | Leave empty if no compilation is needed | . or the directory containing your site |
Use the package manager recorded by your project. The publish directory is relative to the selected application root for Railpack builds. For Dockerfile builds, it is extracted relative to the final image's working directory.
Handle client-side routes
A frontend router can make /account work after clicking a link while a direct visit still returns 404. If your build uses client-side routing, add a rule under Redirects & rewrites:
| Setting | Value |
|---|---|
| Source path | /* |
| Destination | /index.html |
| Action | Rewrite (200) |
Deploy again to publish the rule. Confirm that JavaScript, CSS, image, and favicon URLs still return the correct files. Do not add a blanket SPA fallback to a site that needs real page-level 404 responses or has no client router.
Configure response headers and domains
Use Custom HTTP headers for path-specific response headers, then deploy those changes. Be cautious with caching HTML: hashed JavaScript and CSS assets can be cached longer than the HTML that references them.
See HTTP caching for response-header examples and the difference between a saved preference and an effective caching policy.
Add your own hostname through Custom domains. Both the Openstead URL and verified custom domains use HTTPS.
Understand configuration and releases
Static configuration is compiled into files. Changing a variable in Openstead requires a new deployment to change the served site. Any variable exposed through mechanisms such as VITE_* or NEXT_PUBLIC_* must be safe for visitors to read.
Openstead publishes versioned static artifacts and retains successful releases for rollback. Static delivery does not require a dedicated application container, so there is no application shell or per-container CPU and memory chart. Openstead's static delivery should not be treated as a promise of a globally distributed CDN.
For a guided example, see Deploy a Vite frontend.