Deploy a Static Site

If you already have a folder of static files, Flash Launch can get it online with the smallest possible workflow: upload the site, publish it, open the generated URL, and roll back if a later upload breaks something.

This is the cleanest user path in the current MVP, so it is the best place to start if you want to understand how Flash Launch thinks about shipping.

If you have not read the product overview yet, start with What Flash Launch Is.

What counts as a static site

In Flash Launch, a static site means a project that can be served as files.

Typical examples:

• a landing page
• a waitlist page
• a marketing site
• a portfolio site
• exported docs
• a frontend build that does not need server-side rendering at request time

The current flow assumes you already have the output files. Flash Launch is not yet acting as a full build system for static frameworks in this path. It is publishing the files you upload.

What you need before you deploy

The current MVP expects a folder that contains a valid static site bundle somewhere inside it. Flash Launch now analyzes the uploaded directory first and then decides what should actually be published.

The upload flow also filters obvious files that should not be published:

• .git contents
• node_modules
• .env files
• .DS_Store
• lockfiles and log files

It also keeps a small allowlist for real site files that often look suspicious at first glance, such as:

• .well-known/...
• _headers
• _redirects
• CNAME
• robots.txt
• sitemap.xml
• manifest.webmanifest

That keeps the deployment focused on the actual site output rather than your local project noise.

The current deployment workflow

From the dashboard, the workflow is now a preflight flow instead of a blind upload:

1. Open a project.
2. Go to the Static Site tab.
3. Drag in a folder, or use Select Folder.
4. Review the upload analysis.
5. Confirm the detected publish root, entry point, routing mode, included files, ignored files, and warnings.
6. If more than one site root is detected, choose the one you want to publish.
7. Click Deploy.
8. Open the generated site URL.

That is the product idea in miniature: fewer infrastructure concepts exposed, more direct path from artifact to public result.

What the upload UI does for you

The current static upload flow is opinionated in useful ways:

• It detects whether the uploaded directory contains a publishable static bundle.
• It can recognize common built output folders like dist, build, out, docs, and storybook-static.
• It validates whether the selected publish root contains index.html.
• It blocks deployment if the bundle is too large.
• It blocks deployment if the file count is too high.
• It shows Published, Ignored, and Issues views before publishing.
• It highlights missing local asset references before deploy.
• It tracks upload progress.

These checks are small, but they matter. A launch flow is much easier to trust when the platform catches the most common mistakes before publication instead of after.

What URL gets created

Today, the public URL shape depends on environment.

That means the deployed site is publicly accessible through the Flash Launch dashboard host using a path-based route.

This is an important product detail: in the current MVP, the static site does not yet default to its own wildcard product subdomain. It is published through the dashboard host and routed by project slug.

That is a deliberate step in the evolution of the product. It gives Flash Launch a real public publishing path without requiring the full future DNS and wildcard domain system to be complete first.

What happens after deploy

A successful deploy creates a new static deployment version and makes it the active version for the project.

From there, the current product gives you three useful operating actions:

• open the active site URL
• inspect the deployed file tree
• switch back to a previous version

This is what makes the flow more than simple file hosting. Flash Launch keeps a deployment history and treats each publish as a versioned release.

Version history and rollback

Every upload creates a deployment record. In the UI, you can:

• see previous deployments
• inspect how many files were in each deployment
• view when each version was created
• open the file tree for a given version
• roll back to an earlier deployment

Rollback matters because publishing is not only about getting online. It is also about recovering quickly when an update goes wrong.

In practical terms, the current static site flow is good for builders who want confidence that:

• a bad upload does not permanently break the project
• the last working version is still available
• the platform remembers what was shipped

How to prepare a good first deployment

If you are publishing a site for the first time on Flash Launch, use this checklist:

• Make sure the bundle contains index.html
• Upload the built output folder if you already know it, but it is also acceptable to upload the full repo when the built output is clearly present inside it
• Check that asset paths inside the site work after being served from a public URL
• Keep the first deployment small and simple
• Open the generated URL immediately after deploy and verify the real output

The most common mistake is uploading the wrong folder. For example:

• uploading the source project instead of dist, out, or your export folder
• forgetting that index.html must exist in the publishable output
• assuming server-only behavior in a path that currently serves static files
• ignoring a warning that multiple publish roots were detected and deploying the wrong bundle

What this path is best for

The current static site workflow is an especially good fit for:

If your product already needs a runtime backend, auth workflows, or request-time server logic, static site deployment may still be useful for the public-facing part of the product, but not for the entire app architecture.

Current limitations to understand

This page is about the real product as it exists now, so the limitations matter:

• The current path is upload-based, not full Git-driven auto-build publishing
• Flash Launch does not build the project for you in this flow; it only publishes already-built assets
• Public static site URLs are currently path-based on the dashboard host
• Wildcard product subdomains are a future step, not the current default
• Custom domains for static sites are part of the broader domain vision, but not the primary static-site path described here
• This flow is for static output, not full server-side app deployment at request time

These are not flaws in the concept. They are useful boundaries in the MVP.

The right way to think about them is: Flash Launch already gives you a real shipping loop for static projects, and that loop can later evolve into a fuller product publishing path.

A good mental model for this feature

Static site deployment in Flash Launch is not just "upload some files."

It is:

• artifact validation
• publish-root detection
• versioned release creation
• public route generation
• file visibility
• rollback support

That bundle of capabilities is why this feature matters. It turns a simple static upload into a small but real release workflow.

When to use this before anything else

If you are new to Flash Launch, this is often the best first feature to try.

Use static site deployment first when:

• you want to understand the product quickly
• your project can already be exported as files
• you need a public URL today, not after backend work
• you want the lowest-risk path to a first launch

This path lets you experience the platform's core value without waiting for the entire backend surface of your product to be production-ready.

Related docs

• What Flash Launch Is
• Publishing Fundamentals Handbook