A static site hosts prebuilt HTML, CSS, and JavaScript from object storage. It is not an application: there is no compute Resource to assign, no replicas, no ports, and nothing running between requests. Static hosting is free and does not consume your plan’s capacity. Every site is served at:
Create one from Static Sites → New Static Site in the dashboard, or over the API at POST /api/v1/static.
Three rules differ from applications and are easiest to learn before you start:
  • The name is exact and globally unique. No random suffix is appended, so the name you choose is the hostname the site is served under. A name that is already taken is rejected - it is not silently renamed.
  • The content source is fixed at creation. It decides what gets provisioned for the site, so it cannot be changed later. To switch sources, create another site.
  • Content is stored in eu-east-1. That is currently the only supported region for static sites. Serving is region-less, so a site is equally fast everywhere regardless of where its content lives.

​
Content Sources

Pick one of four sources when you create the site: The two Git sources are built on Miget. The two upload sources take already-built output - uploading a Hugo or Astro project publishes its source files, not a rendered site. Build first, then upload the output directory.

​
Deploy from GitHub

  1. Connect GitHub to your workspace if you haven’t already (see GitHub Integration).
  2. Create the site with the GitHub source, then choose the repository and branch.
  3. Enable auto-deploy to rebuild and publish on every push to that branch.
Deploy manually at any time from the site page. A GitHub-sourced site is also the only source that supports rollback: because a static site produces no image, rolling back rebuilds and republishes the commit that deployment shipped.

​
Deploy with Git Push

  1. Create the site with the Git Push source.
  2. Add an SSH key to your Miget account - the Git remote authenticates with it, and there is no password fallback.
  3. Wait a few seconds for the remote to be provisioned, then copy it from the site’s Deploy panel and push:
Every push builds the site and publishes the output. Pushing is the deploy - there is no separate deploy action for this source.

​
Upload a Zip

  1. Create the site with the Zip source.
  2. Build the site locally.
  3. Zip the contents of the output directory - index.html must sit at the root of the archive, not inside a dist/ folder.
  4. Drop the archive on the site’s Deploy panel, or upload it over the API:
Archives are capped at 1 GB. Each upload replaces the whole site: files from the previous deploy that are absent from the new archive are removed.

​
Deploy over SFTP

  1. Create the site with the SFTP source.
  2. Add an SSH key to your Miget account - the gateway authenticates with it, and there is no password.
  3. Copy the SFTP target from the site’s Deploy panel and connect:
  1. Upload the built site into the session root - put -r ./dist/*, not put -r ./dist, so that index.html lands at the top level.
  2. Disconnect. Closing the session is what triggers the deploy; nothing is published while you are still connected.

​
Build Settings

Git-based sources are built with automatic framework detection across 30+ generators - Next.js, Nuxt, Astro, SvelteKit, Hugo, Jekyll, Eleventy, Docusaurus, VitePress, Gatsby, Vite, Angular, Ember, Zola, and more. Each detected generator brings its own default build command and output directory. Override them in Settings → Deployment when detection gets it wrong: Zip and SFTP sites have no build step, so these settings do not apply to them.

​
Single-Page Applications

Turn on SPA mode for a client-side router (React Router, Vue Router, and friends). Unknown paths then serve /index.html instead of returning a 404, so deep links work on a refresh. It is off by default and can be changed at any time.

​
Deployments, Logs, and Rollback

The site page shows recent deployments and links to the full history, with live and stored build logs for Git-based sources.
  • Cancel stops a running build. Only Git Push and GitHub sites have a build to cancel - a zip or SFTP deploy is a direct sync with nothing to stop.
  • Rollback is available for GitHub sites only, and rebuilds the commit that deployment shipped. Rebuild a Git Push site by pushing again; zip and SFTP deploys carry no commit to roll back to.

​
Files

Each site page includes a file browser showing the content currently deployed, so you can confirm what actually landed in storage after a deploy.

​
Custom Domains

Static sites support custom domains exactly like applications: add the domain under Settings → Domains, point DNS at Miget, and verify it. See Custom Domains for the DNS records and the provider walkthroughs.

​
Managing Static Sites via the API

Static sites are separate from applications: a site never appears in GET /api/v1/apps and cannot be created there.
  • GET /api/v1/static - list static sites
  • POST /api/v1/static - create a site (label, name, and deployment_config.source_type are required)
  • GET /api/v1/static/{uuid} - get a site, including its url and deployment_config
  • PUT /api/v1/static/{uuid} - update the label, or move the site to another project
  • DELETE /api/v1/static/{uuid} - delete the site, its content, and its domains
  • PUT /api/v1/static/{uuid}/deployment - update build and routing settings (a patch: omitted fields keep their value; the source cannot be changed)
  • POST /api/v1/static/{uuid}/deployments - deploy (multipart archive for a zip site; no body to rebuild a GitHub site)
  • GET /api/v1/static/{uuid}/deployments - deployment history
  • POST /api/v1/static/{uuid}/deployments/{id}/cancel - cancel a running build
  • POST /api/v1/static/{uuid}/deployments/{id}/rollback - rebuild and republish the commit a deployment shipped (GitHub only)
  • GET /api/v1/static/{uuid}/files - browse the deployed content, one directory level per call
  • GET|POST /api/v1/static/{uuid}/domains and PUT|DELETE|POST .../domains/{domain_uuid} - custom domains
Creating and configuring a site needs apps:manage; deploying needs apps:deploy.
A site stays in the pending state until content has been deployed to it - that is expected, and not a sign that provisioning failed. What you wait for before the first deploy is the field your source needs: deployment_config.bucket_name for zip and SFTP, deployment_config.git_ssh_url for Git Push. A GitHub site can be deployed as soon as it is created. Read the Git remote and the SFTP target back from deployment_config rather than building them from the site name.
Build-time environment variables can be supplied at creation as app_vars_attributes; they are exposed to the build as BUILD_VAR_*. They are baked into the built output, so never put secrets in them.

​
Limitations

  • No server-side rendering. There is nothing running behind a static site - if your framework needs a Node server at request time, deploy it as an application instead.
  • One source per site. The content source is fixed at creation.
  • Zip and SFTP publish what you upload. No build runs for these sources.
  • Content is stored in eu-east-1. Other regions are not accepted for static sites.

​
Next Steps

Custom Domains

Serve the site on your own domain

GitHub Integration

Connect a repository and deploy on push

Webhooks

Get notified when a deploy starts and finishes

Deployment Methods

Deploy a full application instead