Logistics User Files: 5 Isolation Tests for Free-Tier Alternative Storage Providers

A free storage tier is acceptable for a logistics receipt pipeline only after tenant isolation is tested as a system property, not inferred from a provider's bucket model. Keep the original receipt immutable, make every object key tenant-scoped, authorize reads through application policy, and treat the storage bill as a capacity-planning input rather than the decision itself. TL;DR: choose a provider or self-hosted service that exposes the primitives you need, then put an adapter in front of it. The adapter should bind tenant identity to an object namespace, validate uploads before persistence, record an audit event for each state transition, and make deletion or retention changes explicit. A free tier can lower the cost of a pilot; it cannot compensate for a cross-tenant read, an unverified content type, or an original file that cannot be recovered during an audit. The useful comparison is not a list of services with a zero-cost allowance. It is five isolation tests: can a request for tenant A ever address tenant B's key, can an operator prove which original was retained, can malformed input be rejected before it is trusted, can background jobs preserve the same authorization boundary, and can the design move providers without changing policy? Those answers determine the shape of the system for storing user files. How should logistics teams choose alternative storage providers for a free tier? There is no universal best provider. A free tier is useful for a bounded pilot, while a self-hosted alternative may fit a network-bound workload; both become poor choices when the team cannot test restore, authorization, or capacity against its SLO. The right boundary is the one the platform team can operate and verify. What makes receipt storage an isolation problem? A receipt is a document with operational and legal weight. In a logistics workflow it may arrive from a carrier, a warehouse, or a customer, and the platform may need to process its fields while retaining the original file for audit. The extracted amount, timestamp, and shipment identifier are useful application data; they are not a substitute for the original bytes. Tenant isolation fails in less dramatic ways than a public bucket. A key assembled from an untrusted account identifier can put files in the wrong namespace. A signed download URL generated by a worker can outlive the authorization that created it. A retry can overwrite an original with a transformed image. A bulk export can run with platform privileges and forget to filter by tenant. Each path deserves the same review as the upload endpoint. My decision rule is strict: storage layout may help enforce isolation, but it must never be the only enforcement point. The application should authenticate the caller, resolve the tenant from trusted session state, authorize the receipt, and only then ask a storage adapter for bytes. A caller-supplied tenant ID is a filter value, not an identity claim. That is the boundary. Which five tests expose the dangerous boundary? Run these tests against the complete request path, including workers and administrative tools. A green result means the boundary is enforced in that path, not that the underlying storage service has a convenient feature. Test Expected property Evidence to keep Cross-tenant read Tenant A cannot retrieve tenant B's object by guessed, copied, or replayed identifier Denied request and audit record Cross-tenant write A request cannot create or replace an object outside its authorized namespace Rejected key or policy decision Original preservation Processing creates derived data without mutating the retained receipt Original digest and version record Worker parity OCR, thumbnails, exports, and retries apply the same tenant rule Job input, decision, and result metadata Provider substitution Policy tests pass against another storage adapter Contract-test report The first two tests are deliberately boring. Boring is the goal. Use opaque receipt IDs, but do not mistake opacity for authorization; a random identifier reduces guessing and does not grant permission. The service must compare the object record's tenant ID with the authenticated tenant before it constructs a storage operation. For preservation, store metadata beside the object rather than encoding every business fact in a path. At minimum, the record needs an immutable receipt identity, tenant identity, object reference, content length, a digest calculated after validation, and the processing state. If a later job produces a normalized PDF or extracted JSON, those are new artifacts with new identities. How should the safe implementation separate policy from storage? An adapter keeps provider-specific calls out of handlers and makes the important contract testable. The interface below is intentionally small. It does not expose arbitrary key access to the rest of the application, and it does not pretend that a storage API can answer a tenant policy question. package receipts import ( "context" "fmt" "io" ) type TenantID string type ReceiptID string // ObjectStore is deliberately narrower than a general bucket client. type ObjectStore interface { Put(ctx context.Context, key string, body io.Reader, size int64, contentType string) error Get(ctx context.Context, key string) (io.ReadCloser, error) } type Receipt struct { ID ReceiptID Tenant TenantID Object string Digest string Bytes int64 MediaType string } func objectKey(tenant TenantID, receipt ReceiptID) string { return fmt.Sprintf("tenants/%s/receipts/%s/original", tenant, receipt) } func (s *Service) StoreOriginal(ctx context.Context, caller TenantID, receipt Receipt, body io.Reader) error { if caller == "" || receipt.Tenant == "" || caller != receipt.Tenant { return fmt.Errorf("tenant authorization failed") } if receipt.ID == "" || receipt.Bytes