The official [Deploy Walrus Site action](https://github.com/MystenLabs/walrus-sites-github-actions) targets GitHub Actions only. On any other CI/CD platform, such as GitLab CI/CD, CircleCI, or Bitbucket Pipelines, you drive deployment directly through the [`site-builder` CLI](/docs/sites/getting-started/using-the-site-builder). Because `site-builder` is a standard Linux binary, the deployment steps are identical on every platform. Only the pipeline syntax differs. - [x] A Sui address funded with SUI (gas fees) and WAL (storage). See [Preparing Deployment Credentials](/docs/sites/ci-cd/preparing-deployment-credentials). - [x] The private key in `base64WithFlag` format and the corresponding Sui address. See [Exporting your private key](/docs/sites/ci-cd/preparing-deployment-credentials#exporting-your-private-key). - [x] A CI/CD platform with access to a Linux runner. ## How platform-based deployment works Because there is no pre-built action for non-GitHub platforms, each pipeline must perform the same steps that the GitHub Action handles automatically: 1. **Reconstruct the Sui configuration:** Write the keystore secret from the CI environment to disk so `site-builder` can read it. 2. **Download `site-builder`:** Fetch the binary for the runner's architecture from the [Mysten Labs GCS bucket](/docs/sites/getting-started/installing-the-site-builder#using-a-pre-built-binary). 3. **Download `sites-config.yaml`:** Fetch the network configuration from the [walrus-sites repository](https://github.com/MystenLabs/walrus-sites). 4. **Build the site:** Compile or bundle your site output (skip for repositories that already contain deployable static files). 5. **Run `site-builder deploy`:** Upload the static output directory to Walrus. ## Storing credentials on your platform Every platform stores secrets differently. In all cases, you need 2 values: - `SUI_KEYSTORE`: The `base64WithFlag` private key string wrapped as a JSON array: `["AXXXXXXXXXX..."]`. Store this as a masked or protected secret. Never expose it in logs. - `SUI_ADDRESS`: The corresponding Sui address. This is not sensitive, but masking it is acceptable. | Platform | Secret location | |---|---| | GitLab | Settings → CI/CD → Variables (set visibility to **Masked**) | | CircleCI | Project Settings → Environment Variables, or a shared **Context** | | Bitbucket | Repository settings → Repository variables (enable **Secured**) | > **Danger** > > Never paste `SUI_KEYSTORE` or any private key directly into a pipeline configuration file. Configuration files are committed to version control and visible to anyone with repository access. ## The deploy script The following shell commands contain all setup and deployment logic. Each platform example below inlines these steps in its own syntax. ```sh #!/usr/bin/env bash set -euo pipefail # 1. Reconstruct Sui client configuration from CI secrets. # SUI_KEYSTORE must be a JSON array string, for example: ["AXXXXX..."] # Replace 'mainnet' with 'testnet' throughout if targeting Testnet. WALRUS_NETWORK="${WALRUS_NETWORK:-mainnet}" mkdir -p ~/.sui/sui_config echo "$SUI_KEYSTORE" > ~/.sui/sui_config/sui.keystore cat > ~/.sui/sui_config/client.yaml < **Caution** > > Always point `site-builder deploy` at your build output directory, not your repository root. Uploading the project root includes source files, `node_modules/`, and other artifacts that significantly increase upload time and storage costs. ## Understanding `ws-resources.json` in pipelines The `site-builder deploy` command writes a [`ws-resources.json`](/docs/sites/configuration/site-configuration) file to your `DIST` directory after the first deployment. This file stores the Sui object ID of your deployed site. On subsequent runs, `site-builder` reads that ID to update the same site rather than creating a new one. In a CI/CD pipeline, the build output directory is recreated on every run, so `ws-resources.json` is lost unless you take one of the following approaches: - **Commit the file to your repository** (recommended): Place `ws-resources.json` in your framework's `public/` directory (or equivalent). Most build tools copy everything in `public/` into `DIST` automatically, making the file available at `DIST/ws-resources.json` on every run without extra configuration. - **Pass the object ID explicitly:** After the first deployment, copy the `object_id` value from `ws-resources.json` and store it as a CI variable named `SITE_OBJECT_ID`. Then add `--object-id "$SITE_OBJECT_ID"` to the deploy command: `site-builder deploy --object-id "$SITE_OBJECT_ID" --epochs "$EPOCHS" "$DIST"`. If neither approach is in place, each pipeline run creates a new site object and incurs additional WAL storage costs. ## Platform examples Store your credentials before adding the pipeline file. Then create the configuration file shown for your platform in your repository root. Store `SUI_KEYSTORE` and `SUI_ADDRESS` as masked CI/CD variables under **Settings** → **CI/CD** → **Variables**. Create `.gitlab-ci.yml`: ```yaml stages: - build - deploy variables: WALRUS_NETWORK: mainnet EPOCHS: "5" DIST: dist build: stage: build image: node:lts script: - npm ci - npm run build artifacts: paths: - dist/ expire_in: 1 hour rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH deploy-walrus: stage: deploy image: ubuntu:24.04 needs: - build before_script: - apt-get update -qq && apt-get install -y -qq curl ca-certificates script: - mkdir -p ~/.sui/sui_config - echo "$SUI_KEYSTORE" > ~/.sui/sui_config/sui.keystore - | cat > ~/.sui/sui_config/client.yaml <