Quickstart | STATICX

Fast path

Create a site visually, then automate the next release.

The simplest path is to create the first site in the dashboard, confirm it works, then create the smallest token that fits the next release job.

Dashboard quickstart

Use the interface first.

Open Sites. Click New site.
Choose a source. Upload a ZIP, import a public URL, or start with an empty workspace.
Open the project. Use Pages for rendered pages, Files for workspace contents, and Settings for domains, agent deployment, and deletion.
Create a token. Use Settings for a global token, the project Agent deploy tab for a one-site token, or the workspace page for a multi-site token.
Automate future releases. Give the API instruction or MCP config to your agent or CI job.

ZIP archives should contain the built site files directly at the archive root, including index.html or index.htm and 404.html. In most frontend frameworks that means zipping the contents of dist, build, or public, not the folder itself.

Recommended defaults: a Site token with Full access for one-site release jobs, a Workspace token with Full access for multi-site tools, and a Global token with Read only for dashboards that only inspect state.

CLI quickstart

Log in once, then run the same workflow from your terminal.

STATICX uses the same token-protected /api/v1 contract for the dashboard, agents, MCP tools, and the public npm CLI. Choose the smallest token scope that matches the job.

npm install -g staticx

staticx login --base-url "https://staticx.site/api/v1" --token "STATICX_API_TOKEN"
staticx guide
staticx whoami

# Global token
staticx workspaces
staticx create --workspace-id WORKSPACE_ID --name "Marketing Site"

# Site token
staticx deploy --site-id SITE_ID --dir dist
staticx logs --site-id SITE_ID

# Workspace token
staticx sites --workspace-id WORKSPACE_ID
staticx create --workspace-id WORKSPACE_ID --name "Client Site"

Create a Global token from Settings → API tokens, a Site token from Project Settings → Agent deploy, and a Workspace token from Workspace → Agent deploy. Each screen now includes a ready-made CLI block.

Scope still matters after login: a Global token can list workspaces broadly, a Workspace token should stay inside one workspace, and a Site token should be used for one-site deploys and logs.

API quickstart

Deploy a local build with curl.

export STATICX_API_TOKEN="paste-token-here"
export STATICX_API_BASE_URL="https://staticx.site/api/v1"

# 1. Create a site
curl -X POST "$STATICX_API_BASE_URL/projects" \
  -H "Authorization: Bearer $STATICX_API_TOKEN" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{"name":"Marketing Site"}'

# 2. Confirm index.html or index.htm and 404.html are at the output root
test -f dist/index.html -o -f dist/index.htm
test -f dist/404.html

# 3. Zip the build output so those files are at the ZIP root
cd dist
zip -qr ../site.zip .
cd ..

# 4. Upload and deploy
curl -X POST "$STATICX_API_BASE_URL/projects/{project}/files" \
  -H "Authorization: Bearer $STATICX_API_TOKEN" \
  -H "Accept: application/json" \
  -F "mode=zip" \
  -F "overwrite_confirmed=1" \
  -F "[email protected]"

curl -X POST "$STATICX_API_BASE_URL/projects/{project}/deployments" \
  -H "Authorization: Bearer $STATICX_API_TOKEN" \
  -H "Accept: application/json"

Verify

Read state and logs after deploy.

curl "$STATICX_API_BASE_URL/projects/{project}" \
  -H "Authorization: Bearer $STATICX_API_TOKEN" \
  -H "Accept: application/json"

curl "$STATICX_API_BASE_URL/projects/{project}/deployments" \
  -H "Authorization: Bearer $STATICX_API_TOKEN" \
  -H "Accept: application/json"

curl "$STATICX_API_BASE_URL/projects/{project}/logs" \
  -H "Authorization: Bearer $STATICX_API_TOKEN" \
  -H "Accept: application/json"

If an upload or deployment fails, use the API error message and project logs. Do not assume a release succeeded unless the API returns a successful response.