A home for your static site.

1. Getting started

Statiq publishes static HTML, CSS, JavaScript, images and other files from a Git repository. Your build can generate those files, but the published site cannot run a server, database, PHP application or server-side rendering process.

1. Sign in to the console with your email and password. If you are joining someone else’s account, use their invitation email to register instead of creating a separate account.
2. Choose + New site. Enter a slug for your your-site.statiq.page address, select your Git provider, and enter the repository’s web URL.
3. Add the deploy key and webhook, confirm the branch, and choose a framework preset or enter your build settings. Click Create site.
4. Open the site’s Builds tab and click Trigger build. Open the build to follow its log. Once publication succeeds, visit your site’s address.

Site creation alone does not publish files. Your account’s 30-day trial starts with its first successful build, not with signup.

2. Connect a repository

Choose GitHub, GitLab.com or Codeberg for a hosted repository. Choose Forgejo, Gitea or self-hosted GitLab for your own installation. Public and private repositories use the same read-only SSH deploy-key setup; signing in to Statiq does not grant repository access.

1. Paste the repository’s web URL into Repository URL, then leave the field to load its details. Check the Branch: use the branch you want published.
2. Copy the public Deploy key into your repository’s deploy-key settings. Leave write access disabled. After saving the site, its Settings → Deploy key section lets you check access. If you regenerate the key, replace it at your Git provider too.
3. In the provider’s webhook settings, copy the site’s Webhook URL and secret from Statiq. Use the values for this site, including the full URL. Select push events and JSON (application/json); keep HTTPS certificate verification enabled.
4. For Codeberg or Gitea, choose the Gitea webhook type. For Forgejo, choose a Forgejo webhook with POST. For GitLab, put the secret in Secret token; for GitHub, use Secret.
5. Save the webhook, then push a commit to the configured branch. Check Settings → Webhook for the last received delivery and Builds for the new build. Pushes to other branches do not deploy this site.

Self-hosted Git providers

Also fill in SSH clone URL and Pinned SSH host keys. Copy the SSH URL from your repository, including its port if nonstandard. Ask your Git administrator for the public known_hosts lines and verify their SHA256 fingerprints before saving. A nonstandard port uses a host entry such as [ssh.example.eu]:2222.

The Git SSH endpoint must be publicly reachable; private-network addresses are blocked by the build sandbox. Hosted-provider presets manage SSH trust for you and hide these fields. Never paste a private SSH key into the pinned-host-key field.

Keep webhook secrets private. Removing a site from Statiq does not remove its key or webhook at the Git provider; remove both there yourself.

3. Configure and deploy

Open Settings → Build to change the branch, build command and publish directory. The publish directory is relative to the repository root and must contain the files visitors should receive, usually including index.html.

Choose a preset before editing these fields: selecting one replaces both values. For Plain HTML, select only the folder intended for publication so you do not expose other repository files.

Other static generators can use a custom command. For a Next.js project configured for static export, publish out; server rendering and server routes will not run. For Eleventy, the usual output is _site. For Jekyll, install the project’s dependencies with Bundler, build the site, and publish _site. Use your project’s actual command and output directory.

Hugo extended and Go are included for Hugo modules. Dependencies must be accessible to the build. Disable network during build is only suitable when all dependencies are already vendored; enabling it prevents npm and Hugo module downloads.

There is no console editor for environment variables or build secrets yet. Non-secret values can be set in your project configuration or command. Do not put credentials in the build command, committed configuration, logs or published files.

Push to the configured branch to deploy automatically, or use Builds → Trigger build. Open a build’s entry to see its status and live or saved log. After changing build settings, start a new build; an older build cannot publish with an outdated configuration.

Custom 404.html handling and a single-page-app fallback are not currently provided. Generate actual files for your routes; a client-side route alone will not make a direct visit work.

4. Custom domains

1. Open your site’s Settings → Custom domains. Enter a hostname such as www.example.com, without https:// or a path, and click Add domain. Wildcards are not supported.
2. At your DNS provider, create a CNAME for that hostname pointing to endpoint.statiq.page. Use the target displayed in the console if it differs. Do not point it to your site’s Statiq slug or copy an IP address.
3. Wait for verification and automatic HTTPS provisioning. The status changes from pending to active. DNS changes commonly take minutes but can take up to 24 hours.

Cloudflare and apex domains

With Cloudflare, use DNS only (gray cloud), not Proxied. Avoid CNAME flattening for the hostname: Statiq checks for a visible CNAME, and a record returning only A/AAAA addresses will not pass that check.

A www or other subdomain is the straightforward setup. Apex domains such as example.com commonly use flattened ALIAS/ANAME records, which may not satisfy verification. If your provider cannot expose the required CNAME, use www.example.com and arrange an HTTPS redirect from the apex through your DNS or domain provider.

Once a custom domain is active, your built-in Statiq address redirects to the oldest active custom domain, preserving paths and query strings. Removing the last active custom domain restores the built-in address. Update your generator’s base URL and canonical URLs to match your chosen public hostname.

5. Usage and limits

Open Account Management → Usage to see your balance and account-wide usage. All sites and members share the allowances; adding a site or member does not create another allowance.

Deployment time — 100 minutes included

Measured in seconds from a build’s recorded start to completion, excluding queue wait. Failed builds count too. An abandoned build can consume a bounded ten-minute allowance estimate, but that estimate does not become paid overage.

Storage — 20 GB included

The size of published artifacts across your sites. Storage is a current footprint, not a fresh allocation to fill every month. Paid storage above the allowance uses daily snapshots and complete eligible UTC days; partial days are not charged.

Bandwidth — 10 GB per month included

Bytes served to visitors, including cached delivery. Requests to a site’s built-in and custom hostnames are attributed to the same account.

HTTP requests — 1 million per month included

Attributed CDN requests, including responses with no body. A page loading several assets can make several requests; this is not a count of people or page views.

Monthly counters reset on the first day of each month at 00:00 UTC, including during a trial. This does not reset the trial clock or erase stored files. GB is decimal: 1 GB = 1,000,000,000 bytes.

Paid overages are proportional: €1 per 10 GB bandwidth, €1 per 100 minutes, €1 per 20 GB-month, and €1 per million requests. For example, 1 GB of eligible bandwidth above the allowance costs €0.10, not a whole €1 block. See pricing for the plan summary.

Without paid overage consent, compute or storage limits block builds or publication; bandwidth or request limits pause delivery. Trial expiry and exhausted paid credit block both builds and hosting. Adding credit does not by itself enable overages.

Traffic reporting is delayed, so usage and charges may appear after the requests occurred. Limits are checked against observed usage; a balance can become negative when earlier eligible usage arrives. Deleting a site does not erase usage already incurred.

6. Trial and billing

Your account gets one 30-day trial, starting with its first successful build. Signup, failed builds and new sites do not start or restart it. The trial has full included allowances and hard limits. At expiry, builds and hosting stop; you can still sign in.

Before the first confirmed payment, your account can have up to two existing sites, including undeployed and suspended sites. This also applies before the trial clock starts. All members share a limit of ten successful site creations per rolling 24 hours, including after payment. Deleting a site frees a trial capacity slot but does not reset the rolling limit. Starting checkout or setting up payment authority does not lift the two-site cap; the initial payment must be confirmed.

The Owner manages Account Management → Billing. When checkout is available, Set up payment — €10 buys €10 of prepaid service credit, including applicable tax. Paid service activates after payment is confirmed. The first €1 account fee is prorated for the remainder of the UTC calendar month; subsequent months deduct €1, including tax, from the wallet. Converting early does not grant another monthly allowance.

To fund an already-paid account, choose a top-up amount of at least €10, save it, then use Add credit. If payment is pending, use Continue payment or Check payment to recover its status. Closing a checkout window is not proof that a payment failed.

The separate Allow usage above included allowances while credit is available checkbox controls paid overages. Saving a top-up amount does not purchase credit or authorize automatic charges.

Automatic top-up is not currently enabled for the service. If it becomes available in your console, it requires separate payment-method setup and explicit consent; adding a payment method alone neither buys credit nor enables automatic charges.

If checkout says it is unavailable, payment setup is not ready for your account. The service is still pre-launch; a test checkout is not a live payment. Consult the refund policy for refunds and purchase rights.

7. Accounts and members

Your user is your login. Your account owns the sites, allowances and wallet. Each user belongs to exactly one account, and each active account has exactly one Owner. The account price includes unlimited members.

• Owner: manages sites, members, billing, overage consent and hosting cancellation; can transfer ownership.
• Admin: manages sites and non-owner members, including invitations and Admin/Editor roles; cannot manage billing.
• Editor: can create, configure, deploy and delete account sites; cannot manage members or billing. Editor access is not limited to sites they created.

Owners and Admins invite people from Account Management → Members → Invite. The recipient registers using the invitation email. Existing Statiq users cannot accept invitations or switch accounts. Before deleting an existing login to join another account, read the consequences below—a last-user deletion closes the original account.

To transfer ownership, the Owner opens Account Management → User → Danger zone, selects an existing member, and confirms Transfer ownership. The previous Owner becomes an Admin. Account resources and billing remain with the account.

8. Stopping or leaving

• Temporary suspension: sites remain retained when a trial, credit or traffic limit stops delivery. Resolve every blocking condition—such as funding an expired trial or enabling paid overages—to restore retained sites without redeploying.
• Delete a site: use the site’s Settings → Danger zone. Its published files are removed. Other account sites remain. Remove its webhook and deploy key at your Git provider yourself.
• Cancel hosting: the Owner uses Billing → Cancel hosting. This stops hosting for every account site, new builds, credit purchases and new monthly fees. Sites and financial history remain; earlier usage and submitted payments still settle. This does not issue a refund, and there is no self-service reactivation.
• Remove a member or delete your login: the login and sessions are deleted permanently; account sites and billing stay with the remaining members. An Owner with other members must transfer ownership before leaving.
• Close the account: the last user’s User → Danger zone offers Close account and delete my login. This immediately revokes access and stops hosting and funding. Sites, domains, files and build logs are queued for deletion after outstanding activity settles. Required billing records remain.

After account closure and final reconciliation, positive unused purchased credit is automatically refunded to the original payment methods, capped at the remaining refundable purchase amounts. Complimentary credit is not a refundable purchase. Closure cannot be undone.

Save any files and logs you need before deletion. There is no self-service account export yet; use the contact details in the privacy policy for a data request.

9. Search visibility

New sites start with indexing disabled. In Settings → Indexing, enable Allow search-engine indexing and save. Wait for synchronization; no new build is required for this setting.

This removes Statiq’s indexing restriction, but your own robots.txt and page-level noindex directives still apply. Disabling indexing asks search engines to omit your site; it does not make the site private.

Configure your generator’s base URL and sitemap for the public hostname. To verify ownership with a search engine, publish its supplied verification file at the required path or add its meta tag to your HTML. For a custom domain, DNS TXT verification is another option. Submit the sitemap through the search engine’s webmaster tools. Verification and appearing in search results are separate; indexing is not immediate or guaranteed.

10. Troubleshooting and help

My push did not trigger a build

Check the configured branch, the provider’s webhook delivery history, and Statiq’s last-received webhook time. Compare the complete URL and secret with this site’s settings, enable push events, and check that the provider can reach the endpoint. Use Trigger build to check the build independently of webhook delivery.

My build failed

Open the build log and find the first error. For clone failures, check the read-only deploy key, repository URL, branch and self-hosted SSH pins. For dependency failures, check access and the offline-build setting. For output errors, check the build command and publish directory. Check account usage and credit if the build was blocked before it ran.

My domain is pending or has an error

Check the public DNS answer for the exact hostname, for example with dig CNAME www.example.com. Verify the target shown in the console, disable proxying and flattening, and allow DNS changes to propagate. If the console shows error, correct DNS, then remove and re-add the domain. If it still fails, report the hostname and status.

My page is blank, missing or outdated

Check that the latest build succeeded and that its publish directory contains index.html and the expected assets. Inspect failed asset requests in your browser, and check the generator’s base URL and static-export settings. Direct links need generated files; there is no automatic application-route fallback. Confirm that the commit you changed is on the configured branch.

My site says “Hosting paused”

Ask the Owner to check Account Management → Usage and Billing for trial expiry, depleted credit, bandwidth/request limits or hosting cancellation. A payment must be confirmed before it restores paid service, and other restrictions can still apply.

I cannot sign in

Use the password-reset link on the sign-in page and check your spam folder for the email. If a member was removed, their login no longer exists. Invitation recipients should use their invitation email to register.

Still stuck, or was something in this guide unclear? Email statiq@doublearches.com with your site address, build ID if relevant, the approximate UTC time, and the error text. Remove credentials and private content from logs before sharing. Never send passwords, private keys, webhook secrets, payment details, or invitation/reset links.

Back to top