Skip to main content
Secrets store the cloud provider credentials that DataRaven uses to access your storage locations. Every location references a secret, and DataRaven supports two storage modes to fit your security requirements.

Native Vault

Enter credentials directly. Stored encrypted in AWS SSM Parameter Store (SecureString). Simple, secure, zero configuration.

External Vault (BYOV)

Map credential fields to references in 1Password, Doppler, or Infisical. Credentials resolved at execution time and immediately discarded.

​
Supported Providers

Each cloud storage provider requires specific credential fields. DataRaven auto-selects the auth method when you choose a provider — except Azure, which offers two options.
ProviderAuth MethodRequired Fields
AWS S3s3_access_keyaccess_key_id, secret_access_key
Azure Blobazure_sas_urlsas_url
Azure Blobazure_account_keyaccount_name, account_key
Google Cloud Storagegcs_service_accountservice_account_json
Cloudflare R2r2_access_keyaccess_key_id, secret_access_key
Backblaze B2b2_application_keyapplication_key_id, application_key
Wasabiwasabi_access_keyaccess_key_id, secret_access_key
Railwayrailway_access_keyaccess_key_id, secret_access_key
Oracle Object Storageoracle_object_storage_s3_access_keyaccess_key_id, secret_access_key
Tigristigris_access_keyaccess_key_id, secret_access_key
DigitalOcean Spacesdigitalocean_spaces_access_keyaccess_key_id, secret_access_key
Hetznerhetzner_access_keyaccess_key_id, secret_access_key
Rabatarabata_access_keyaccess_key_id, secret_access_key
S3 Compatibles3_compatible_access_keyaccess_key_id, secret_access_key

​
Creating a Secret

Store credentials directly in DataRaven’s encrypted vault. Best for teams that don’t use an external secrets manager.
1

Choose your provider

Select the cloud storage provider. The auth method is auto-selected (Azure lets you choose between SAS URL and account key).
2

Enter credentials

Fill in the required credential fields for your provider. These are encrypted and stored in AWS SSM Parameter Store.
3

Name and save

Give the secret a descriptive name (e.g., “Production AWS” or “Staging GCS”) and save.
You cannot provide both credentials and vault_connection_id on the same secret. Choose one storage mode — native vault or external vault — per secret.

​
Validation Rules

DataRaven validates secrets on creation and update:
  • auth_method must be valid for the chosen secret_type
  • field_mappings must cover all required fields for the auth method (partial mappings are rejected)
  • credentials and vault_connection_id are mutually exclusive

​
Updating & Rotating Secrets

Edit a secret to rotate the credentials
You cannot switch a secret between native vault and external vault after creation. A native secret always uses credentials, and a BYOV secret always uses field_mappings.
Changing secret_type on an existing secret triggers validation against all linked locations to ensure compatibility.

​
Secret Lifecycle

Secrets are referenced by Locations, which are referenced by Tasks. This creates a dependency chain:
1

Create a secret

Store credentials for a cloud provider using either storage mode.
2

Link to a location

When creating a storage location, select the secret that holds credentials for that provider.
3

Use in tasks

Tasks reference locations. At execution time, DataRaven resolves the secret’s credentials to access the storage.
4

Deletion protection

A secret cannot be deleted while it’s in use by one or more locations. You’ll receive a 409 Conflict error. Unlink or delete the dependent locations first.
The secret detail view shows all linked locations and tasks, along with creation metadata.

​
Security

Never exposed

Credentials are never returned in any API response — not on read, not on list, not on update confirmation.

Encrypted at rest

Native vault credentials are stored as AWS SSM Parameter Store SecureString parameters, encrypted with AWS KMS.

In-memory only

External vault credentials are resolved in-memory at execution time and immediately discarded after the operation completes.

Audit logged

All secret operations — creation, updates, deletions, and runtime resolutions — are logged for audit purposes.

​
Provider Tips

Use SAS URLs over account keys. SAS (Shared Access Signature) URLs are scoped to specific containers and operations, and they expire automatically. Account keys grant full access to the entire storage account.When using azure_sas_url, generate the SAS URL from the Azure portal with the minimum required permissions (read/write/list) and a reasonable expiration window.
The service_account_json field expects the entire JSON key file contents as a string. Copy the full JSON output from gcloud iam service-accounts keys create — don’t extract individual fields.
R2 credentials (access_key_id and secret_access_key) go in the secret. The account ID belongs in the Location’s endpoint_url field, not in the secret — typically formatted as https://<account_id>.r2.cloudflarestorage.com.
Wasabi requires an endpoint_url in the Location configuration (e.g., https://s3.us-east-1.wasabisys.com). The secret only holds the access key credentials.
Tigris uses standard S3 access key credentials. The endpoint_url goes in the Location configuration — typically https://fly.storage.tigris.dev.
DigitalOcean Spaces uses standard S3 access key credentials. The endpoint_url goes in the Location configuration — formatted as <region>.digitaloceanspaces.com (e.g., nyc3.digitaloceanspaces.com).
Hetzner Object Storage uses standard S3 access key credentials. The endpoint_url goes in the Location configuration — formatted as <region>.your-objectstorage.com (e.g., hel1.your-objectstorage.com).
Rabata Object Storage uses standard S3 access key credentials. The endpoint_url goes in the Location configuration — formatted as s3.<region>.rabata.io (e.g., s3.us-east-1.rabata.io). Region is also required.

​
Tier Limits

PlanSecrets
Free5
Pro100
Need more? Upgrade your plan from the billing page.