CI-friendly releases
StaticX works from GitHub Actions without browser sessions. Store a scoped token as a repository secret, build your static output, validate index.html and 404.html, then deploy the build folder through the CLI or API.
Features
Deploy static sites from GitHub Actions
Use StaticX from CI by calling the API or CLI with a scoped token, so every successful build can publish an immutable release.
Safe automation
Tokens can be site-scoped, workspace-scoped, or account-scoped. Use the narrowest token for CI so a single repository can only publish the site it owns.
Version history stays intact
Every CI publish creates a rollback-ready release. You can inspect it in the dashboard, compare analytics, and return to a previous version without rebuilding.
Set up GitHub deployment in three steps
Use GitHub Actions when the repository should be the source of truth and every successful build should become a StaticX release.
Create a scoped token
Generate a site-scoped StaticX API token and store it as STATICX_API_TOKEN in GitHub repository secrets.
Build the output
Run your normal build command, then verify that index.html and 404.html exist at the deployment root.
Publish the release
Call the StaticX CLI or API from the workflow so the build becomes a rollback-ready deployment version.
Why automate static-site deployment from GitHub?
Manual uploads are easy at the beginning, but they become fragile once a team, client, or AI agent is changing the site. A missing asset, nested ZIP folder, or forgotten 404 page can put a broken release online.
With StaticX, CI deploys use the same versioning system as dashboard and CLI deploys. Each successful workflow creates an immutable release, keeps the previous release available for rollback, and records the deployment in site history.
Not just a deploy command
Release logs stay visible
The dashboard shows which deployment was created, when it went live, and whether it is the active version.
No broad account token needed
Use narrow token scopes so one repository can publish one site without access to unrelated projects.
Works with agents and CI
The same API contract can be used by GitHub Actions, Codex, Claude, Cursor, or any automation runner.
Questions about GitHub Action
Short, practical answers for using this page safely.
Do I need a dedicated StaticX GitHub Action?
No. Use the StaticX CLI or API inside a normal GitHub Actions workflow. This keeps the deployment step transparent and easy to inspect.
What happens if the build fails?
The workflow should stop before publishing. The active StaticX deployment remains unchanged until a valid build is uploaded and deployed.
Can different branches publish different sites?
Yes. Use separate site-scoped tokens or project IDs per environment so staging, client previews, and production remain isolated.
Can GitHub Actions create rollback-ready versions?
Yes. A successful deploy creates the same immutable version as a dashboard or CLI deploy. Rollback changes the active pointer, not the files.