Day-2 Operations

Once Marshal is installed, here’s how to operate it: upgrading, rolling back, renewing your license, and wiring up object storage. Each of the first three has a Terraform path and an ArgoCD (GitOps) path, matching whichever installer you used — see Installing Marshal if you haven’t installed yet, and Configuration Reference for the full settings surface referenced below.

Upgrading

Marshal ships as a single umbrella Helm chart whose version is the product version, so an upgrade is always “point at a new chart version and apply.”

terraform apply

argocd app sync marshal

Always confirm the target chart version against your Marshal onboarding materials or your Marshal contact — the registry deliberately doesn’t support listing available versions client-side.

Rolling back

helm rollback marshal -n marshal

git revert <commit>
argocd app sync marshal

argocd app rollback marshal

Renewing the license

Your installation JWT (installation_jwt) isn’t self-issued — when it’s close to expiry, your Marshal contact issues a new one the same way as the original: once, over a secure channel. Once you have it:

terraform apply

kubectl create secret generic marshal-license -n marshal \
  --from-literal=jwt="<new-jwt>" \
  --dry-run=client -o yaml | kubectl apply -f -
 
kubectl rollout restart deployment/marshal-api -n marshal

Object storage: audit export & session pause/resume

Two independent, optional features run on cloud object storage: audit export (compliance export of the session audit trail) and session pause/resume (snapshotting a space so it can be paused and later resumed instead of always tearing down on session end).

This is a two-step setup, and the steps are deliberately separate:

1. Provision the storage. This part is infrastructure, and it’s installer-specific — for example, the GKE and EKS flavors each expose a pair of toggles (create_audit_persistence_bucket / create_spaces_persistence_bucket) that create the bucket and wire up credential-less access (Workload Identity / IRSA) for you. See your platform’s install guide under Installing Marshal for the exact toggle.

2. Point Marshal at it. Creating a bucket doesn’t turn the feature on by itself. An org admin wires the actual bucket via the Marshal API after the infrastructure exists — this isn’t part of either installer, because it’s per-org configuration, not per-deployment. Session storage is configured with a call shaped roughly like:

   PUT /api/org/space-storage
   { "provider": "gcs" | "s3", "bucket": "<bucket-name>" }

   When the bucket was provisioned with Workload Identity / IRSA, no credentials are needed in the request — auth is ambient. If you brought your own bucket instead of provisioning one through the installer, supply explicit credentials in the same call.