Hi Railway team/community,

I'm reviewing the least-privilege security model for Railway Buckets before using one for a dedicated synthetic staging environment.

This is not an application debugging request, and I'm not requesting any credentials or configuration changes. I'm trying to establish Railway's actual Bucket permission, identity and revocation semantics.

If possible, I'd particularly appreciate confirmation from a Railway employee or links to official Railway documentation, as we need provider-level answers rather than assumptions based solely on generic S3 behaviour.

Credential rotation / revocation - highest priority

In the Central Station thread “Bucket rotate credentials is broken” from 10 June 2026, a Railway employee acknowledged an issue where rotating Bucket credentials could leave the old credential working while the new secret remained inactive.

Could Railway please confirm:

Is that issue fixed today?

Does railway bucket credentials --reset guarantee invalidation of the previous Access Key / Secret?

What is the maximum guaranteed time after reset before the old credential can no longer authenticate?

Do already-issued presigned URLs signed with the old credential remain valid after reset?

If so, is their configured expiry the only termination boundary?

Is there any stronger revocation mechanism that can invalidate an outstanding presigned request before expiry?

Do reset/invalidation semantics differ between presigned GET and HEAD requests?

Bucket permissions / least privilege

Can a Railway Bucket credential be restricted to read-only?

Can write/upload, delete, multipart, copy and tagging operations be explicitly denied?

Can a credential be scoped to an exact object or prefix rather than the entire bucket?

Can LIST permission be controlled independently from GET/HEAD?

Does HEAD/object-metadata authority inherently also permit downloading the object's bytes?

Is a Bucket credential strictly limited to its issuing bucket, or could it authenticate against another bucket/resource in the same project/account?

What is the maximum authority of a Bucket credential — object/data-plane operations only, or can it also perform bucket-level administration/configuration operations?

Can multiple independent credential pairs exist simultaneously for one Bucket, allowing one to be revoked/rotated without affecting the others?

Presigned URLs

Railway documentation covers presigned GET and PUT URLs. We haven't found equivalent Railway documentation for presigned HEAD.

Are presigned HEAD requests officially supported, and can a presigned request be restricted to one exact object, one operation and a short expiry?

Resource identity / auditability

What Railway/provider identifier should be treated as the stable identity of a Bucket for environment verification? Is that identifier guaranteed to remain stable for the lifetime of the Bucket?

Relatedly, is there provider-side access/audit logging that can attribute S3/API operations to an individual Bucket credential?

We're specifically trying to distinguish Railway's actual guarantees from capabilities that merely exist because the API is S3-compatible.

Please don't post or request any access keys, secret keys, tokens, passwords or other credential values in this thread.

Thanks!