CI/CD Setup

The recommended pattern for Rise CI/CD is two service accounts with different environment restrictions: one for production (restricted to protected refs) and one for preview deployments (restricted to the staging environment). This is enforced server-side — a misconfigured pipeline cannot deploy to production using the preview service account.

See Environments for how environments, deployment groups, and service account restrictions work.

Recommended Setup

Service Account	Allowed environments	CI trigger
sa-production	production only	Protected branches / tags
sa-preview	staging only	All branches (MR pipelines)

Step 1 — Create the environments:

rise environment create staging -p my-app --group staging --color blue

The default production environment (mapped to the default group) already exists.

Step 2 — Create the service accounts (with environment restrictions set via the web UI or API after creation):

# Production SA: only protected refs
rise sa create -p my-app \
  --issuer https://gitlab.com \
  --claim aud=https://rise.example.net \
  --claim project_path=myorg/my-app \
  --claim ref_protected=true

# Preview SA: any ref, restricted to staging in the web UI
rise sa create -p my-app \
  --issuer https://gitlab.com \
  --claim aud=https://rise.example.net \
  --claim project_path=myorg/my-app

Then, in the web UI, edit the preview service account and restrict it to the staging environment.

Record the Email shown for each service account by rise sa create or rise sa list. Set it as RISE_IDENTITY in that account’s CI job so the CLI exchanges the provider’s OIDC JWT for a Rise access token. The example below uses my-app+0@sa.rise.local for production and my-app+1@sa.rise.local for previews; replace them with your actual account emails.

Direct external-token authentication without exchange is deprecated. It still works when the operator allows raw external tokens; disabling that compatibility path by default is planned for 0.25.0. See Service accounts for the exact scope and migration instructions.

Step 3 — Deploy from CI:

# GitLab CI example
deploy-production:
  only: [tags]
  variables:
    RISE_URL: https://rise.example.net
    RISE_IDENTITY: my-app+0@sa.rise.local
  id_tokens:
    RISE_TOKEN:
      aud: https://rise.example.net
  script:
    - rise deploy -E production --image $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG

deploy-preview:
  except: [tags]
  variables:
    RISE_URL: https://rise.example.net
    RISE_IDENTITY: my-app+1@sa.rise.local
  id_tokens:
    RISE_TOKEN:
      aud: https://rise.example.net
  script:
    - rise deploy -E staging --group mr/$CI_MERGE_REQUEST_IID --expire 7d

With this setup:

• Production deployments are served at the project’s main URL and custom domain.
• Preview deployments get a staging-environment URL (e.g. staging--my-app.preview.rise.example.com) and share staging-scoped variables (e.g. a staging database URL).
• The preview SA is physically unable to deploy to production even if a pipeline is misconfigured — the environment restriction enforces it server-side.

For GitHub Actions and other providers, see Service Accounts.