Static sites

The Static Site panel shows the default URL, storage used and the active release. Below it, Static Site Pod Space splits storage into CDN Storage (Live Site), the files currently serving traffic, and Release Storage (Version History), the archives kept for rollback, and shows this month's bandwidth against the plan.

The page also has the Domains and Add-ons sections, the Mage Stats and Mage SEO panels when those add-ons are on, and the site's Maintenance Log (see Maintenance).

Deployment Source

Choose how the site is published: Upload ZIP, GitHub or Bitbucket. Only the selected source can deploy; a push to a repository that is connected but not selected is ignored. Connected providers keep their credentials when you switch and are marked connected. Selecting a provider you have not connected yet shows its connect form, and connecting it makes it the active source. Disconnecting the active provider switches the site back to Upload ZIP.

Uploading a ZIP

The archive must have an index.html at its root.

• Standard (≤512 MB). Choose the file and click Deploy. The upload is refused if the file is not a valid ZIP, has no index.html at the root, or would take the site over its storage quota.
• Large File (>512 MB). Choose the file and click Upload & Deploy. Your browser uploads it straight to storage with a progress bar, then the deployment starts. Very large archives can take several minutes.

Connecting a repository

• GitHub. Enter the Repository as owner/repository, the Production branch (main by default) and a Personal Access Token. The token needs repository read access; for a fine-grained token, Contents read and Webhooks write. Click Connect GitHub.
• Bitbucket. Enter the Repository as workspace/repo-slug, the Production branch, your Atlassian account email and an API token created at id.atlassian.com → Security → API tokens (classic, or scoped with Bitbucket read and webhook permissions). Click Connect Bitbucket.

The portal checks that it can reach the repository before saving anything; if it cannot, it says so and your existing settings are kept. Credentials are stored encrypted. Connecting also adds a push webhook to the repository so that pushes can deploy automatically. If your token is not allowed to create webhooks, the repository still connects, but pushes will not start deployments. If pushes never deploy, look in the repository's webhook settings for the Press Mage webhook; if it is missing, click Disconnect and connect again with a token that has the webhook permission listed above. Deploy now works either way.

Once connected, the panel shows the repository, branch, whether auto-deploy is on, and either the build command and publish directory or No build step (prebuilt site). Deploy now deploys the current head of the branch. Disconnect stops automatic deployments and removes the stored credentials; the live site is not affected.

Deploy on push

With Deploy automatically on push ticked (the default), every push to the production branch deploys that exact commit. Pushes to other branches are ignored. If several pushes arrive while an earlier one is still waiting, only the newest is deployed and the older waiting ones are marked Superseded. Deployments started with Deploy now or Redeploy are never superseded. Deployments wait their turn as Queued while other deployments on your account, including those of your other static sites, are running.

Build settings

The settings form under a connected repository holds:

• Production branch.
• Framework preset, which fills in the install command, build command and publish directory:

• Root directory: the folder in the repository that holds the site, if it is not the root.
• Install command, Build command and Publish directory. With a named preset these follow the preset; choose Custom to set your own.
• Build environment variables: click + Add variable and enter a key and value. Values are encrypted, passed only to the build and masked in the build log. Leave a value blank to keep it unchanged; Remove deletes the variable.

Click Save settings.

Leave the install and build commands empty for a prebuilt site: the files in the publish directory are published as they are. With a build command, each deployment first runs your build in an isolated build environment with Node.js (Astro, Vite, Gatsby and Next.js) or Hugo, then publishes the publish directory. Custom keeps the build environment of the preset that was selected before it, and a site that has only ever used Custom builds in the plain no-build environment. To run your own commands with Node.js or Hugo, first choose and save the closest preset (for example Vite for a Node.js build, or Hugo), then switch to Custom and enter your commands. The publish directory must contain an index.html. A build that fails or runs past the time limit is stopped and marked Failed, and the live site is not touched.

Deployment History

Every release with its Release ID (and commit), Method, Trigger (such as manual, push or redeploy), Status, Size, Duration and Created date. While a release is in progress its status shows the current step, such as Queued, Fetching, Building or Validating. It then ends as Live, Previous (an earlier live release), Superseded or Failed.

Actions:

• View log opens the build log in a new tab, on releases that ran a build: the plain-text output of fetching the commit and running your install and build commands, with build variable values masked. Use it to see why a build failed.
• Redeploy fetches the same commit from the repository again, builds it and publishes it as a new release. It is offered when that repository is the active source.
• Promote on a Previous release rolls the site back to it: the portal confirms Rollback queued and the current live site is replaced by that release, which appears in the history as a new release.
• Delete permanently removes a release that is not live.

Only the most recent published releases are kept for rollback; older ones are removed automatically.