Lux GitHub Actions

Official GitHub Actions for Lux. Run Lux from your CI/CD with a Lux API key, no raw database credentials required.

Each action lives in its own subdirectory and is referenced by path:

Action	Use
lux-db/actions/setup@v1	Install the Lux CLI on the runner
lux-db/actions/migrate-plan@v1	Preview engine-owned migration decisions
lux-db/actions/migrate@v1	Plan, then apply pending migrations
lux-db/actions/migrate-status@v1	Compare local files with the engine ledger
lux-db/actions/push-status@v1	Check secret-free APNs and Web Push health

Authentication

All actions authenticate with a Lux API key (lux_...), created in the Lux Cloud dashboard under Tokens. Store it as an encrypted GitHub Actions secret (e.g. LUX_API_KEY) and pass it as the api-key input. You never need the instance's raw database password. Managed actions expose the key to the CLI through LUX_TOKEN; they never place it in command arguments.

migrate

Plan and apply pending migrations before a deploy. The engine owns parsing, SHA-256 checksums, progress recording, and the migration ledger. The action prints the plan before making changes and only unapplied migrations run.

- uses: lux-db/actions/migrate@v1
  with:
    api-key: ${{ secrets.LUX_API_KEY }}
    project: my-project

Inputs:

• api-key (required) — Lux API key.
• project (required) — project name, ID, or slug.
• dir (optional, default lux/migrations) — migration directory.
• version (optional, default latest) — Lux CLI version to install.

migrate requires CLI 0.27.0 or newer. A failed or interrupted migration is recorded at its exact command cursor and blocks later migrations until it is explicitly repaired with the CLI.

A typical deploy gate:

jobs:
  migrate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: lux-db/actions/migrate@v1
        with:
          api-key: ${{ secrets.LUX_API_KEY }}
          project: my-project

  deploy:
    needs: migrate
    runs-on: ubuntu-latest
    steps:
      - run: echo "deploy after migrations applied"

migrate-plan

Preview the exact engine decisions without applying anything. The action exits non-zero for conflicts and migration blockers, making it suitable for pull requests:

- uses: lux-db/actions/migrate-plan@v1
  with:
    api-key: ${{ secrets.LUX_API_KEY }}
    project: my-project

Inputs:

• api-key (required) — Lux API key.
• project (required) — project name, ID, or slug.
• dir (optional, default lux/migrations) — migration directory.
• version (optional, default latest) — Lux CLI version, 0.27.0 or newer.

migrate-status

Compare local migration files with the engine-owned ledger, including checksum conflicts and durable partial progress.

- uses: lux-db/actions/migrate-status@v1
  with:
    api-key: ${{ secrets.LUX_API_KEY }}
    project: my-project

Set check: true to turn it into a gate that fails the job when any migration is unapplied, conflicting, or partially applied:

- uses: lux-db/actions/migrate-status@v1
  with:
    api-key: ${{ secrets.LUX_API_KEY }}
    project: my-project
    check: true

migrate-status requires CLI 0.27.0 or newer.

push-status

Check secret-free APNs and Web Push configuration. By default the action fails when configured credentials are unhealthy:

- uses: lux-db/actions/push-status@v1
  with:
    api-key: ${{ secrets.LUX_API_KEY }}
    project: my-project
    app-id: default

Inputs:

• api-key (required) — Lux API key.
• project (required) — project name, ID, or slug.
• app-id (optional, default default) — push application ID.
• check (optional, default true) — fail on unhealthy configured providers.
• version (optional, default latest) — Lux CLI version, 0.27.0 or newer.

Status output includes provider metadata and the public VAPID key, but never APNs or VAPID private key material.

setup

Just install the CLI, then run any lux command yourself.

- uses: lux-db/actions/setup@v1
  with:
    version: latest # or a pinned version like "0.27.0"
- run: |
    lux login
    lux exec my-project PING
  env:
    LUX_TOKEN: ${{ secrets.LUX_API_KEY }}

setup accepts any published CLI version. The managed migration and push actions enforce their own minimum of 0.27.0 so a pinned legacy CLI cannot silently fall back to the former CLI-owned migration implementation.

Security and validation

Action inputs are passed through environment variables and quoted arrays rather than interpolated into shell source. The repository validates composite-action metadata and workflows with action-validator and actionlint, checks scripts with ShellCheck, and runs fake-CLI smoke tests that cover:

• explicit Cloud project targeting;
• token exclusion from process arguments;
• spaces and shell metacharacters in inputs;
• the stable CLI 0.27.0 minimum;
• migration plan/run/status argument construction;
• push-health check behavior.

Versioning

Actions are tagged together. Pin to a major (@v1) for stability, or a full release for reproducibility. The Marketplace is not used (these live in one repo); reference them by path as shown above. Publish backend support first, then CLI 0.27.0, then the corresponding Actions release.