Other Supabase Inc. Bidirectional
Sdk
Connection
Bidirectional
Data Flow
10
Components
3
Dependencies

Description

Supabase Storage provides S3-compatible object storage for user-generated binary files including receipt images, activity attachments, Bufdir export files, driver declarations, and generated PDF/CSV reports. Access is controlled via RLS-backed storage policies ensuring users can only access files belonging to their organisation.

Detailed Analysis

Supabase Storage provides secure, scalable object storage for all user-generated binary content in the platform — receipt images submitted by peer mentors, driver declarations, activity attachments, and government-format Bufdir export files. By enforcing organisation-scoped access policies at the storage layer, the platform guarantees that sensitive financial and personal documents can never be accessed cross-organisation, which is essential for GDPR compliance and donor/government audit readiness. The S3-compatible architecture ensures industry-standard durability and availability for business-critical documents. Included in the Supabase Pro plan with per-GB overage billing, storage costs scale predictably with platform adoption.

Client-side receipt image compression before upload reduces both bandwidth costs and the exposure window for sensitive imagery in transit, demonstrating privacy-by-design principles that strengthen organisational trust.

Ten components depend on the storage integration, spanning receipt uploads, export file management, driver declarations, and attachment signing. Initial setup requires creating and configuring separate storage buckets per data type (receipts, attachments, exports, declarations) with distinct RLS policies and file size limits — this is a non-trivial configuration effort that should be planned as a dedicated task. The orphan file cleanup job for failed multi-step uploads must be implemented and tested to prevent storage cost leakage. Upload retry logic with exponential backoff adds resilience but requires end-to-end testing on degraded network conditions, particularly for field workers on mobile connections.

Signed URL expiry handling (default 1 hour) introduces time-sensitive access patterns that require thorough QA for edge cases. Storage quota alerts at the Supabase level and per-organisation consumption metrics should be built into the operational monitoring plan. Team members need to understand bucket policy authoring and signed URL generation patterns.

Supabase Storage v2 is accessed via the supabase_flutter SDK using JWT-authenticated REST calls. Each bucket (receipts, attachments, exports, declarations) has independent RLS storage policies restricting access to authenticated users within the same organisation. File uploads use multipart upload with retry logic (exponential backoff) handled in 100-receipt-storage-adapter and 423-supabase-storage-adapter. Signed URLs are generated by 421-attachment-signed-url-service with configurable expiry (default 1 hour) and regenerated gracefully on expiry.

The 420-attachment-upload-service validates file size client-side before initiating upload to avoid wasted bandwidth. Failed uploads are queued locally and retried on the next connectivity event. Receipt images are compressed client-side before upload to reduce egress costs and upload latency targets (<3s on 4G). Driver declarations are stored in a private bucket with encrypted filenames.

Storage bucket health is checked on app startup; upload failure rate spikes trigger alerts for operational response.

Dependencies (3)

supabase_flutter SDK External
Active authenticated Supabase session External
Storage buckets created and policies applied External

Authentication

TypeJwt
RequirementsAuthenticated Supabase session JWT, Storage bucket policies configured per bucket, Signed URL generation for temporary access
Scopesstorage.readstorage.writestorage.delete (coordinator and admin roles only)

Configuration

Required Settings

Bucket names per data type (receipts, attachments, exports, declarations) Required
Per-bucket RLS storage policies Required
Maximum file size limits per bucket Required

Optional Settings

CDN caching enabled for public assets Optional
Image transformation settings for receipt compression Optional
Presigned URL expiry duration Optional

Environment Variables

SUPABASE_URL
SUPABASE_ANON_KEY

Error Handling

Upload retry with exponential backoff on network failure
File size validation before upload attempt
Orphan file cleanup job for failed multi-step uploads
Signed URL expiry handled gracefully with regeneration

Monitoring

Health Checks

Storage bucket accessibility check on app startup
Upload success rate tracking

Metrics

Storage consumption per organisation
Upload/download latency
Failed upload rate

Alerts

Storage quota approaching limit
Upload failure rate spike

Performance

Latency< 3s for receipt image upload on 4G connection
Availability99.9% availability — receipt and declaration uploads are business-critical

Rate Limits

Supabase Pro: 100GB storage included
File upload size limit configurable per bucket (default 50MB)

Cost Implications

Pricing ModelIncluded in Supabase plan with overage billing per GB

Cost Factors

Total stored file size
Egress bandwidth for downloads
Number of storage operations

Security Considerations

Per-bucket RLS policies prevent cross-organisation file access
Driver declarations stored in private bucket with encrypted filenames
Signed URLs expire after configurable duration (default 1 hour)
Receipt images compressed client-side before upload to reduce exposure window

Fallback Mechanisms

Failed uploads queued locally and retried on next connectivity event
Existing uploaded files remain accessible during storage service degradation