CI/CD Integration

Automate pipeline deployments to Runtime from your CI/CD system.

Authentication in CI

CI/CD environments cannot use the interactive browser-based login. To authenticate non-interactively, you'll need an API key — a long-lived token that the CLI can use without human interaction.

CLI integration in progress

API key creation is now available, see API keys. CLI authentication using these keys is coming next. Until then, the workflow below shows the intended end-to-end flow but cannot be run yet.

Example: GitHub Actions

Once CLI integration lands, a workflow like this will deploy to Runtime on every push to main:

name: Deploy to Runtime

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: astral-sh/setup-uv@v5

      - name: Install dependencies
        run: uv sync

      - name: Configure secrets
        run: |
          mkdir -p .dlt
          cat > .dlt/secrets.prod.toml << 'EOF'
          [destination.motherduck.credentials]
          database = "${{ secrets.MOTHERDUCK_DB }}"
          password = "${{ secrets.MOTHERDUCK_TOKEN }}"
          EOF

      - name: Deploy to Runtime
        env:
          DLT_RUNTIME_API_KEY: ${{ secrets.RUNTIME_API_KEY }}
        run: uv run dlt runtime deploy

      - name: Schedule pipeline (optional)
        run: uv run dlt runtime schedule my_pipeline.py "0 0 * * *"

note

Store all credentials as GitHub Actions secrets. Never hardcode tokens or passwords in workflow files.

What to automate

Task	Command	When to use
Deploy code + config	dlt runtime deploy	On every merge to main
Deploy and run immediately	dlt runtime launch <script>	For deploy-and-test workflows
Set up a schedule	dlt runtime schedule <script> "<cron>"	Once during initial setup, or when schedule changes
Check workspace status	dlt runtime info	As a post-deploy verification step

Declarative job and schedule definitions

Currently, jobs and schedules are created imperatively via CLI commands (dlt runtime launch, dlt runtime schedule). We are working on support for defining jobs and schedules in Python code — so your job configuration, cron expressions, and profile settings live alongside your pipeline code and are version-controlled as part of your project.

This will make CI/CD workflows simpler: instead of running separate CLI commands to create jobs and set schedules, a single dlt runtime deploy will pick up everything from your code.

More details will be added here once the feature is available.

Tips

• Deploy on merge, not on PR. Deploy to Runtime when code is merged to your main branch, not on every pull request.
• Keep schedules in code. Run dlt runtime schedule in CI so your cron expressions are version-controlled alongside your pipeline code.
• Use profile-specific secrets. Configure secrets.prod.toml and secrets.access.toml separately in CI. See Manage Secrets.
• Verify after deploy. Add dlt runtime info as a post-deploy step to confirm the deployment succeeded.
• Monitor from the Web UI. After CI deploys, check the Dashboard and Jobs page to verify runs are executing correctly.