Package static sites
A local fission site build proves the site can render. Packaging turns that output into a release artifact with a manifest, hashes, MIME metadata, route metadata, and validation checks. Publishing should use that manifest rather than guessing which folder or file belongs to a release.
1. Build and check the site first
fission site check --project-dir documentation --release
fission site build --project-dir documentation --release
check catches broken links and rendering errors. build writes the configured output directory.
2. Package static output
fission package \
--project-dir documentation \
--target static-site \
--format static \
--release
The package command writes target/fission/release/static-site/static/artifact-manifest.json. That manifest lists every generated file, its size, hash, MIME type, target, format, and validation state.
Use it when publishing:
fission publish \
--project-dir documentation \
--provider github-pages \
--artifact target/fission/release/static-site/static/artifact-manifest.json \
--site production
fission publish is the direct publish command. fission distribute publish remains available for workflows that prefer the older action-oriented spelling.
3. Package a static site as a Docker image
A static site can also be packaged into an OCI/Docker image. Fission generates a Docker context containing the rendered site and a small Rust static-file server. The server adapter is configured in fission.toml.
[package.docker]
adapter = "axum"
port = 8080
tags = ["ghcr.io/example/my-docs:1.0.0", "ghcr.io/example/my-docs:latest"]
What you should have working
After this guide, you should be able to explain where Package static sites fits in the Fission lifecycle, identify the file or component you changed, run the relevant fission command, and verify the result in a real target or test.
Common mistakes to check
Symptom | What to check first |
|---|---|
The app compiles but nothing changes | Confirm the component is actually used by the route or shell target you are running. |
An action fires but state does not update | Confirm the reducer is registered with the same action value that the UI dispatches. |
A platform feature reports unsupported | Confirm the target has the capability in fission.toml and the shell registered the provider. |
The page works on one target but not another | Run fission doctor, then inspect target-specific configuration and feature flags. |
Tests are hard to write | Split the product rule into a reducer test first, then add a UI or shell smoke test for the integration. |
Then package the image:
fission package \
--project-dir documentation \
--target static-site \
--format docker-image \
--release
By default, Fission runs docker build with the configured tags. Set build = false under [package.docker] if you only want the generated Docker context for CI to build later.
4. Publish image tags to a registry
Configure the registry tags under distribution.docker_registry when the publish destination differs from the local package tags or when you want an explicit release profile.
[distribution.docker_registry.production]
tags = ["ghcr.io/example/my-docs:1.0.0", "ghcr.io/example/my-docs:latest"]
Authenticate with the Docker CLI, then publish:
docker login ghcr.io
fission publish \
--project-dir documentation \
--provider docker-registry \
--artifact target/fission/release/static-site/docker-image/artifact-manifest.json \
--site production
Fission uses the Docker CLI for registry login, tagging, and pushing. That keeps authentication consistent with the tools most registries already document and avoids storing registry passwords in fission.toml.
5. Choose static hosting or image hosting deliberately
Use a static hosting provider when you want a public documentation or marketing site with no server process to run. Use a Docker image when the deployment platform expects containers, when you need the same static site artifact to run in several environments, or when your organization standardizes on container deployment for review apps.
Both flows begin with the same Fission site project. The difference is only the package format and publish provider.
Fission
A cross-platform, GPU-accelerated user interface framework for Rust. MIT licensed.
Copyright (c) 2026 Fission
Ready to use today. Widget APIs are expected to remain stable; some runtime and shell APIs may change before 1.0.0.
Fission 0.7.0