6 days ago
Hello Railway team,
We are evaluating Railway-managed Buckets for a small deletion-receipt ledger, kept separately from an application volume so that restoring an older volume does not make deleted chats reappear. This is a pre-provisioning capability question, not a live incident.
Could you confirm the following for Railway-managed buckets specifically?
- Does PutObject with If-None-Match: * atomically reject an existing key, including competing requests?
- After a successful write, do GetObject and ListObjectsV2 always return the latest object and include it in listings, including after application restart, region changes and failover? What configuration or routing constraints apply?
- Can runtime credentials be restricted to reading/listing and create-only writes, denying overwrites, DeleteObject and bucket deletion?
- What durability and recovery protections apply? Are versioning or retention controls available through Railway?
We read the Railway Buckets documentation and the existing conditional-writes discussion pointing to Tigris. We do not want to assume that every direct-Tigris feature or guarantee is available through Railway. The current Railway documentation lists object versioning and object locks as unsupported.
We have only tested local simulations so far. A small cloud smoke test could check observed behavior, but would not establish the provider guarantees above. Links to current Railway-specific documentation or clarification from the team would help us select an appropriate design.
Thank you.
3 Replies
6 days ago
Our Storage Buckets documentation is the Railway-specific source here. It lists Put, Get, Head, Delete, List/ListV2, Copy, presigned URLs, tagging and multipart as supported. It lists object versioning, object locks, bucket lifecycle configuration and server-side encryption as not yet supported, so versioning and retention controls are not available through Railway today.
On durability and recovery, buckets are encrypted at rest and run on Tigris's object storage, and we don't currently offer automatic backups or snapshots for buckets. A deleted bucket can be restored from the project's Activity feed for 52 hours. After that its objects are permanently destroyed.
On credentials, each bucket instance comes with one S3 access key pair, shown in its Credentials tab, and each environment gets its own isolated credentials. Our documentation does not describe read-only, create-only or no-delete credential scopes.
Conditional-write atomicity (If-None-Match: *) and read-after-write and listing consistency come from the S3 endpoint itself, which is Tigris's implementation. Our documentation makes no separate guarantee about them. For those semantics, the reference is Tigris's documentation. Keep in mind that Tigris documenting a feature does not mean Railway exposes it on your bucket. A bucket's region is fixed when you create it, and buckets are reachable only over public networking, not private networking.
Status changed to Awaiting User Response Railway • 6 days ago
Railway
Our [Storage Buckets documentation](https://docs.railway.com/storage-buckets) is the Railway-specific source here. It lists Put, Get, Head, Delete, List/ListV2, Copy, presigned URLs, tagging and multipart as supported. It lists object versioning, object locks, bucket lifecycle configuration and server-side encryption as not yet supported, so versioning and retention controls are not available through Railway today. On durability and recovery, buckets are encrypted at rest and run on Tigris's object storage, and we don't currently offer automatic backups or snapshots for buckets. A deleted bucket can be restored from the project's Activity feed for 52 hours. After that its objects are permanently destroyed. On credentials, each bucket instance comes with one S3 access key pair, shown in its Credentials tab, and each environment gets its own isolated credentials. Our documentation does not describe read-only, create-only or no-delete credential scopes. Conditional-write atomicity (If-None-Match: *) and read-after-write and listing consistency come from the S3 endpoint itself, which is Tigris's implementation. Our documentation makes no separate guarantee about them. For those semantics, the reference is [Tigris's documentation](https://www.tigrisdata.com/docs/). Keep in mind that Tigris documenting a feature does not mean Railway exposes it on your bucket. A bucket's region is fixed when you create it, and buckets are reachable only over public networking, not private networking.
6 days ago
Thank you. We still need clarification from the Railway team on whether atomic If-None-Match: * writes and fresh, complete GetObject/ListObjectsV2 results are guaranteed for Railway-managed buckets, and whether create-only/no-delete credentials are available. If these guarantees or controls are unavailable, confirming that would also help us choose a different design. Could a team member review these remaining questions?
Status changed to Awaiting Railway Response Railway • 6 days ago
6 days ago
To answer directly: our documentation makes no Railway-level guarantee on If-None-Match: * atomicity, or on read-after-write and listing consistency, for Railway buckets. Those semantics are implemented by the underlying Tigris S3 endpoint, not by us, so the only reference for them is Tigris's documentation. Tigris documenting a behavior doesn't mean we commit to it for your bucket, so if your design needs these as guaranteed properties, don't count on Railway to provide them.
On credentials, each bucket instance comes with one S3 access key pair, and our docs describe no read-only, create-only or no-delete credential scopes. The Storage Buckets docs also list object versioning, object locks and bucket lifecycle configuration as not yet supported. That means the bucket itself can't enforce an append-only, immutable ledger today.
Status changed to Awaiting User Response Railway • 6 days ago