Bitwarden Secrets Manager

The backupdrill CLI reads its settings from environment variables. If you keep secrets in Bitwarden Secrets Manager, store the database connection string and bucket keys there and let Bitwarden put them in the environment for each run: bws run on a machine, Bitwarden’s action in GitHub Actions. There’s no .env file to manage, and nothing to change in the CLI.

bws run --project-id "<project-id>" -- npx backupdrill backup

Store the settings

1. In Secrets Manager, create a project for your backups.
2. Add one secret per setting, named exactly like the environment variable in the table below. bws run uses each secret’s name as the variable name, so a misspelt name is a setting the CLI never sees.
3. Create a machine account, give it read access to that project, and create an access token for it. Copy the token when it’s shown.

To back up Storage files as well, add the four BACKUPDRILL_SUPABASE_STORAGE_* settings from the CLI docs the same way. The endpoint, region and project name aren’t secret, so they can just as well go in the command’s environment.

Run it on a machine

Install bws following Bitwarden’s Secrets Manager CLI guide, put the access token in BWS_ACCESS_TOKEN, and wrap each CLI command in bws run:

export BWS_ACCESS_TOKEN="<access token>"
bws run --project-id "<project-id>" -- npx backupdrill backup
bws run --project-id "<project-id>" -- npx backupdrill drill

bws run starts the command with the project’s secrets as environment variables and doesn’t hand BWS_ACCESS_TOKEN on to it. Keep --project-id: without it, every secret the token can read is injected. In a cron job or systemd unit, set BWS_ACCESS_TOKEN the way you set that job’s other secrets, not inline in the schedule line.

Run it in GitHub Actions

Bitwarden’s action fetches secrets by ID and exports them as masked environment variables for the steps after it, so the only repository secret you need is the access token. It fetches only the IDs you list, so add a line for every setting you stored: for AWS S3, leave out the endpoint line and keep the region, and add the Storage settings if you back up Storage files. Each secret’s ID is shown next to it in Secrets Manager.

      - uses: bitwarden/sm-action@v3
        with:
          access_token: ${{ secrets.BWS_ACCESS_TOKEN }}
          secrets: |
            <secret-id> > BACKUPDRILL_DATABASE_URL
            <secret-id> > BACKUPDRILL_S3_BUCKET
            <secret-id> > BACKUPDRILL_S3_ACCESS_KEY_ID
            <secret-id> > BACKUPDRILL_S3_SECRET_ACCESS_KEY
            <secret-id> > BACKUPDRILL_S3_ENDPOINT
            <secret-id> > BACKUPDRILL_S3_REGION

If you use the CLI’s scheduled workflow (see Schedule it with GitHub Actions), add this step before the backup step and delete the matching ${{ secrets.BACKUPDRILL_* }} lines from that step’s env:. Left in, they replace Bitwarden’s values with your repository secrets, or with empty strings where those secrets aren’t set.

EU cloud and self-hosted

On Bitwarden’s EU cloud, point bws at it once, or pass --server-url on each command:

bws config server-base https://vault.bitwarden.eu

In GitHub Actions, add cloud_region: eu to the action’s inputs. A self-hosted Bitwarden uses its own URL in the same places: bws config server-base, and base_url for the action.

Good to know

• A flag on the command line beats an environment variable, which beats backupdrill.config.json. A leftover config file won’t override what comes from Bitwarden, but a flag will.
• Two secrets with the same name in the project make bws run stop with an error instead of picking one.
• This is for the CLI. The hosted BackupDrill service stores the credentials you enter in the console and doesn’t read them from Bitwarden.