Static Sites
Static Sites on Runsite Platform host pre-built front-ends — static HTML, CSS, JavaScript and assets — directly from a Git repository. Every deploy is atomic and served from a global edge network for low-latency delivery worldwide.
Static Sites are the right choice for marketing pages, documentation, single-page applications (SPA), JAMstack sites and any front-end built with frameworks like Astro, Next.js (static export), Vite, Nuxt, SvelteKit, Hugo, Jekyll or plain HTML.
How it differs from Web Services
Section titled “How it differs from Web Services”| Web Services | Static Sites | |
|---|---|---|
| Runtime | Long-running container with CPU and memory | No runtime — files served from edge |
| Scales to | Multiple instances | Global edge automatically |
| Suited for | APIs, full-stack apps, services that need a process | Static front-ends, SPAs, docs |
| Sleep on idle | Yes | Not applicable — always available |
Supported sources
Section titled “Supported sources”- GitHub
- GitLab
- Bitbucket
Direct upload (drag-and-drop a build folder from the dashboard) is also supported when you do not want to connect a repository.
Build configuration
Section titled “Build configuration”| Field | Description |
|---|---|
build_command | Command run during build, e.g. npm run build |
publish_directory | Folder containing the built files, e.g. dist, build, public |
root_directory | Optional sub-folder to use as the project root for monorepos |
node_version | Node.js version used during build |
Common framework presets:
| Framework | Build command | Publish directory |
|---|---|---|
| Astro | npm run build | dist |
| Next.js (static export) | next build && next export | out |
| Vite | npm run build | dist |
| Nuxt 3 (static) | npm run generate | .output/public |
| SvelteKit (adapter-static) | npm run build | build |
| Hugo | hugo | public |
| Jekyll | bundle exec jekyll build | _site |
Environment variables
Section titled “Environment variables”Static Sites accept build-time environment variables. They are injected into the build process — they are not available at runtime, since there is no runtime. Use them for VITE_*, NEXT_PUBLIC_* or similar build-time configuration.
Auto-deploy on push
Section titled “Auto-deploy on push”When connected to a Git repository, every push to the configured branch triggers a new build and atomic deploy. Pull requests can optionally generate preview deployments on a unique URL.
URLs and custom domains
Section titled “URLs and custom domains”Every static site gets a default URL on the runsite.site domain:
https://my-site.runsite.siteIf the desired subdomain is already taken, Runsite appends a short numeric suffix automatically — for example my-site-2.runsite.site.
A small set of subdomains is reserved for the platform itself and cannot be used: docs, api, app, auth, status, cdn and a few others. The dashboard will tell you when a name cannot be used.
To use your own domain, add a custom domain from the service settings. See Custom Domains for the full DNS setup guide.
Global edge delivery
Section titled “Global edge delivery”Every static deploy is replicated to edge locations around the world. Visitors are served from the closest location automatically, and assets are cached aggressively with sensible defaults that you can override per-path.
Cache control
Section titled “Cache control”| File type | Default behavior |
|---|---|
| HTML | Always revalidated |
Hashed assets (*.[hash].js, *.[hash].css) | Cached long-term |
| Other static assets | Cached with revalidation |
You can override cache headers per path through redirects/headers configuration in the project settings.
Limits
Section titled “Limits”| Limit | |
|---|---|
| Maximum upload size per deploy | 1 GB |
| Maximum number of files per deploy | 50,000 |
| Build duration | 30 minutes |
Need a backend with your static site?
Static Sites are pure front-end. If you need APIs, dynamic rendering or background work, deploy them as a Web Service and call it from your static site over HTTPS.