Vultr
F Object Storage (S3-compatible)
This card is object storage only. Apps authenticate with the subscription's S3 access key and secret key. They are long-lived, have no documented expiry, scoping or last-used time, and are not revoked when leaked. The control-plane API can regenerate them. Vultr IAM lists object-level actions and per-user S3 keys, but publishes no guide to short-lived or federated S3 credentials. The control plane is graded on vultr-cloud.
Docs: docs.vultr.com · Checked 2026-10-22 · source YAML · dispute via PR
Inbound F
How a workload running anywhere authenticates to this product.
Static S3 access key and secret key per Object Storage subscription, read from the console, API (GET /v2/object-storage) or vultr-cli and replaced with a regenerate call. No documented federation or temporary-credential path into the S3 endpoint.
- docs.vultr.com checked 2026-10-22
“These credentials include the hostname, secret key, and access key.”
- docs.vultr.com checked 2026-10-22
“Your apps use these credentials to authenticate to the Vultr Object Storage subscription programmatically.”
- docs.vultr.com checked 2026-10-22
“You need your Vultr Object Storage subscription credentials to access the files.”
- vultr.com checked 2026-10-22
“Object Storage is S3 API compatible.”
- docs.vultr.com checked 2026-10-22
“Get user S3 keys”
The documented credential is the subscription key pair, and nothing in the Object Storage docs describes swapping an OIDC token or IAM role session for S3 keys. Some hints point elsewhere. The IAM actions map lists object-level actions and a GetUserKeys action for "user S3 keys", and the API reference's assumed-role session response has an empty s3_credentials object. Neither is explained in public docs, so neither is graded. If assumed-role sessions (including Vultr's external-issuer federation, see vultr-cloud) are documented to return short-lived, IAM-scoped S3 keys, this would move to C or better. Fetching or regenerating keys runs on the static API key graded on vultr-cloud. With 1 of 5 hygiene checks passing, the grade is F.
Outbound n/a
How this product reaches into your cloud, repos, or other SaaS.
Object Storage never needs access to customer infrastructure.
- vultr.com checked 2026-10-22
“Objects uploaded to object storage can be accessed privately or publicly on the web.”
- docs.vultr.com checked 2026-10-22
“Rclone is an open-source application used to manage and migrate cloud storage solutions.”
The migration guides from S3, GCS, Azure Blob, DigitalOcean and Linode have the customer run rclone themselves, so Vultr never holds those credentials.
Hygiene for any static credential the product still issues
| ✗ Expiry enforceable | No expiry is documented for S3 keys. They last until someone regenerates them.
|
| ✓ Rotation via API | POST /v2/object-storage/{id}/regenerate-keys replaces the pair in one call. There is only one pair, so the old key dies right away and rotation cannot overlap.
|
| ✗ Scoped keys | The documented key pair belongs to the whole subscription, every bucket in it. Per-user S3 keys governed by object-level IAM actions may exist (see inbound notes), but no public doc says how to create them or limit them. Held at fail until documented.
|
| ✗ Last-used visible | No last-used time is documented for S3 keys.
|
| ✗ Leak revocation | Vultr does not appear in GitHub's secret-scanning patterns table.
|
Notes
Split from vultr-cloud because the credential differs. This product uses S3 access key pairs, while the control plane uses IAM-backed API keys with role sessions. The fix is to document short-lived S3 credentials from IAM role sessions (the response field already exists), with per-key scoping, expiry and a last-used time.
Badge
[](https://wif.tax/p/vultr-object-storage/)