Offline Access & Registry Backups

Atlas now supports license grant caching and migration directory registry backups across all CI/CD providers and Kubernetes, ensuring Atlas Cloud is never a single point of failure in your deployment pipeline.

As part of a robust business continuity strategy, Atlas ensures that your deployment pipeline never depends on a single external service. Two complementary features make this possible: license grant caching for license continuity, and registry backups for migration directory redundancy.

License Grant Caching

After a successful atlas login --token --grant-only, Atlas caches a grant file (~/.atlas) that allows CI/CD jobs to continue using Atlas Pro capabilities even without connectivity to Atlas Cloud. This is supported across all major CI/CD providers:

GitHub Actions

ariga/setup-atlas includes built-in license grant caching for ~/.atlas and restores it across workflow runs. No additional cache configuration is required.

# .github/workflows/atlas.yaml
steps:
  - uses: ariga/setup-atlas@v0
    with:
      cloud-token: ${{ secrets.ATLAS_CLOUD_TOKEN }}

GitLab CI

Atlas GitLab CI Components include built-in license grant caching by storing .atlas as cache and artifacts, restoring it for subsequent runs.

# .gitlab-ci.yml
include:
  - component: gitlab.com/ariga/atlas-ci-component/migrate-lint@~latest
    inputs:
      cloud-token: $ATLAS_CLOUD_TOKEN

CircleCI

The Atlas CircleCI Orb includes built-in license grant caching with restore/save cache and workspace persistence. No additional cache setup is required when using the official Atlas orb commands.

Bitbucket Pipelines

Bitbucket Pipelines requires manual external cache configuration for .atlas. Sync it with ~/.atlas before and after each Atlas action step.

# bitbucket-pipelines.yml
definitions:
  caches:
    atlas-grant: .atlas

pipelines:
  default:
    - step:
        caches:
          - atlas-grant
        script:
          - mkdir -p ~/.atlas
          - cp -a .atlas/. ~/.atlas/ 2>/dev/null || true
          - pipe: docker://arigaio/atlas-action:v1
            variables:
              ATLAS_ACTION: migrate/lint
              ATLAS_TOKEN: $ATLAS_TOKEN
          - mkdir -p .atlas
          - cp -a ~/.atlas/. .atlas/ 2>/dev/null || true

Kubernetes Operator

Enable Helm chart persistence to store Atlas CLI state (including .atlas) on a PVC across pod restarts. Each AtlasSchema and AtlasMigration resource uses a dedicated subdirectory, keeping grant state isolated per resource.

# values.yaml
persistence:
  enabled: true
  size: 1Gi
  accessModes:
    - ReadWriteOnce
  mountPath: /data

Registry Backups

Atlas supports backup repositories for migration directories. When configured, Atlas automatically replicates every atlas migrate push to one or more backup storage locations and handles fallback reads transparently. Supported providers include AWS S3, Google Cloud Storage, and Azure Blob Storage.

# atlas.hcl
env "prod" {
  migration {
    dir = "atlas://app"
    repo {
      name = "app"
      backup = [
        "s3://my-bucket/atlas-backup?region=us-east-1",
        "gs://my-bucket/atlas-backup",
      ]
    }
  }
}

If the primary registry is unreachable, Atlas reads from registry backups in order. If Atlas Cloud push fails but at least one backup succeeds, Atlas reports a warning and the command still succeeds. This means your migration artifacts are always accessible from at least one location.

Business Continuity

Together, license grant caching and registry backups ensure that both license grants and migration artifacts have independent redundancy. Atlas Cloud is never a single point of failure in your schema management workflow, making Atlas a natural fit for organizations that require resilient, autonomous deployment pipelines as part of their business continuity planning. For more details, see Service Availability.