Open-source alternative to Cloud Storage for Firebase

Firebase Storage rules match file paths and evaluate the caller's auth token and request data, such as the content type or size, before allowing a read or write. The open-source platforms express the same intent differently, so the rules cannot be copied across line by line. In Supabase, storage objects are rows in a Postgres table, so access is written as row level security policies on the storage schema, typically keyed on the authenticated user ID stored in the object path or metadata. In Appwrite, access is granted through bucket-level and file-level permissions that name users, teams, roles or labels. In PocketBase, a file is a field on a record, so the collection rules that govern the record also govern the file, and you must decide whether file access should follow the record or be separate. Start with a written inventory of every Firebase rule: the path pattern, the condition, the operation (read, write, delete), and any custom claims or request fields it depends on. Each entry should map to one target construct, and any rule with no clean equivalent becomes a design decision to record before work begins.

Test each rebuilt policy before cutover, not after. For every path in the inventory, run requests from three identities: a signed-in user who owns the object, a signed-in user who does not, and an anonymous client. Add a fourth case for cross-user access attempts that try to guess or enumerate paths belonging to others. Record the expected result for each request and compare it with what the target platform returns, including the HTTP status and whether the file body is actually returned. Pay particular attention to list operations, signed or public URLs, and deletes, because these are the most common places where a policy that looks correct still leaks or blocks access. Confirm each platform's current behavior for these cases against its own documentation and your version, since storage features change between releases. Keep the test results as evidence for your change record, and rerun the suite after every upgrade of the storage service.

Self-hosted file storage replaces a metered Cloud Storage bill with costs you pay to your own infrastructure provider and staff, so the first decision is which cost components you will own. The main recurring items are the servers or VMs that run the storage service (Supabase Storage with its imgproxy and database dependencies, Appwrite's Storage service inside its Docker or Helm stack, or PocketBase's single executable), the disk or object capacity behind them (local disk for PocketBase by default, or an S3-compatible store such as Garage or SeaweedFS), backups, monitoring, and the staff time to patch. Capacity cost grows with the volume of files and with replication you add for durability, while compute cost follows peak download and image transformation load. Ask your infrastructure provider to price each of these separately so you can see which line moves when your file volume grows.

Backups deserve the most careful line item. Supabase's self-hosting docs list managed backups and point-in-time recovery as unavailable when you self-host, so you must budget for your own backup tooling, its storage target and restore tests for both the Postgres metadata and the object store, since a file record without its bytes is a broken application. Appwrite's Helm chart docs say its built-in object storage runs a single replica without failover, which means production file data usually needs a replicated external store, another recurring cost. The Supabase changelog also flags one-way Storage database migrations that require a backup before updating, so staff time for each release should include a rehearsal on a copy.

Patching is the cost most often under-quoted. Self-hosted Supabase releases its Docker configuration as a bundle that pins specific Auth, PostgREST and Realtime versions, so each release means pulling and recreating services in your environment, and the 0.8.3 release flagged security fixes for Storage. Appwrite and PocketBase also ship frequent releases, and PocketBase warns of manual migration steps before v1.0.0. Support is community-based for self-hosted Supabase and volunteer-based for PocketBase, so a paid support contract or internal on-call rota is a cost you must add. For one-time work, the migration of files and the rebuild of access rules into Storage policies or Appwrite permissions is the largest item. Request a quote that separates the one-time migration and rules rewrite from the monthly run cost, names the storage capacity assumption, includes backup and restore testing, and states which upgrade windows and security patch response times are covered and which are not.

DeployOpen delivers a storage replacement under a written, fixed scope agreed before work starts. The scope names the storage backend (Supabase Storage, Appwrite Storage or PocketBase file fields), the object store behind it (local disk or an S3-compatible store such as Garage or SeaweedFS), the buckets or collections in use, and the sign-off criteria for cutover. Scope, deliverables and timelines are set out in writing, so the reader can compare them against internal estimates before committing. Any timeline or fee is quoted from that written scope, not from a standard package.

The core deliverables are a rules inventory, a deployed storage stack, a migration runbook and a security test of access policies. The rules inventory lists every Firebase Storage security rule, the paths and file types each one covers, and the client code that depends on them, then maps each rule to its equivalent in the target platform. The deployed stack is installed inside the client's own cloud account, data center or air-gapped network, with secrets generated rather than copied from example files. The runbook covers export of objects from Cloud Storage, checksum verification after upload, the database backup to take before any one-way storage migration, and the rollback path. The security test checks that anonymous, cross-user and expired-session requests are refused on every rebuilt policy.

Optional retainers cover upgrades and continuous testing after cutover. Storage components release often, and some storage-related changes in the self-hosted Supabase Docker configuration flag security fixes, so the reader should agree in advance who applies updates, how they are tested and who owns patch windows. Continuous testing can repeat the access policy checks after each release. Before requesting a quote, confirm the file volumes, the number of user groups with different access, whether files are shared through public links, and which compliance evidence the organization needs. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report.