Open-source alternative to Vercel Blob: the short answer
If your app keeps uploads in Vercel Blob and you need data residency, less lock-in or costs you can forecast, the usual replacement is S3-compatible object storage that you run on your own servers. Garage suits small geo-distributed clusters linked by ordinary internet connections, and SeaweedFS suits workloads with many small files. Either way, the application moves from the Vercel Blob SDK to a standard S3 client, so the storage backend can change later without rewriting upload and download code.
The migration is mostly a code change in the storage layer. Uploads, downloads and deletes move from the Blob SDK calls to an S3 client pointed at your endpoint, with credentials scoped per bucket in place of Vercel tokens. Confirm before you commit that the features your app relies on are supported. Garage, for example, does not implement bucket versioning, bucket policies, object lock or event notifications, and its lifecycle rules cover only aborting incomplete multipart uploads and expiration. Check the Garage S3 compatibility page against your own call list. Also plan for the operator work that Vercel currently absorbs: backups, capacity, monitoring and recovery of the stored objects.
Do not choose MinIO community edition for new work. Its repository is archived and read-only, the last tagged community release is dated October 16, 2025, and the README says legacy binaries will not receive updates. Existing MinIO deployments can keep running under the AGPLv3 terms, but any commercial or proprietary use needs review against those obligations. Treat the choice of Garage or SeaweedFS as a decision to make with your own workload data, such as object count, object sizes, number of sites and your team's tolerance for operating a cluster.
Which Vercel Blob capabilities map to self-hosted object storage
This table maps the main Vercel Blob capabilities to three self-hosted S3-compatible options: Garage, SeaweedFS and Ceph RADOS Gateway. Read each row as a check against the S3 calls your app makes, because feature coverage differs by product and some cells need a test run to confirm. The main takeaway is that Garage covers core upload and signed URL flows but omits bucket policies, and none of the three supplies a global CDN.
| Capability | Garage | SeaweedFS | Ceph RADOS Gateway |
|---|---|---|---|
| Uploads and multipart uploads | Multipart uploads supported; large files can be sent in parts | S3 API served through filer servers; confirm multipart coverage in your SDK tests | Object storage through RGW; confirm multipart behavior with your client library |
| Signed (presigned) URLs | Presigned URLs supported with signature v4 | Confirm presigned URL support on the S3 gateway version you deploy | Confirm presigned URL support on your Ceph release |
| Public and private access | Per-access-key, per-bucket permissions only; no bucket policies or ACLs, so plan public reads through a proxy or CDN | Access control model not covered in supplied material; confirm public read options | Access control depends on RGW configuration; confirm public read options for your release |
| Listing and deletion | Standard S3 listing and delete calls; verify pagination and key naming with your SDK | Verify listing and delete behavior against your Blob SDK replacement code | Verify listing and delete behavior against your SDK and cluster version |
| Expiry of temporary files | Lifecycle rules limited to expiration and aborting incomplete multipart uploads | Confirm lifecycle rule coverage before relying on automatic cleanup | Confirm lifecycle rule coverage for your Ceph release |
| Versioning and object lock | Not implemented; plan backups or application-side versioning | Confirm versioning and retention features on your deployed version | Confirm versioning and object lock support on your Ceph release |
| Encryption | Server-side encryption with customer-provided keys (SSE-C); no server-side encryption configuration | AES256-GCM encryption at rest and TLS or mTLS for transport | Confirm encryption options for data at rest and in transit |
| CDN delivery and edge caching | Not provided by the storage; place a CDN or caching proxy in front | Not provided by the storage; place a CDN or caching proxy in front | Not provided by the storage; place a CDN or caching proxy in front |
| Minimum footprint | One binary per node; three nodes recommended for three-way replication across locations | Master, volume and filer roles; a Raft group of three masters is the usual high-availability pattern | Multiple Ceph daemons on one RADOS cluster; the heaviest operational footprint of the three |
Garage, SeaweedFS and Ceph RGW: when each option fits
Each option below speaks the S3 API that the Vercel Blob replacement will use, so the choice depends on operations, data shape and what else your team runs. Read each card against your file counts, number of sites and existing storage skills, and confirm features in a test cluster before you commit.
Garage for small geo-distributed clusters
Garage is an S3-compatible store licensed under AGPL-3.0 that ships as one self-contained binary and is designed for several sites linked by ordinary internet connections. Its deployment guide recommends at least three nodes for three-way replication, with copies placed in different locations. The trade-off is a narrower S3 surface: bucket versioning, bucket policies, ACLs, object lock and replication are not implemented, and access is controlled by its own per-key, per-bucket permissions. Check that your Blob workflows use only features Garage supports, and confirm the AGPL-3.0 obligations with your legal team before you run it.
SeaweedFS for many small files
SeaweedFS is Apache-2.0 licensed and separates volume servers, which store blobs in append-only volume files, from filer servers that manage directories and files. Its README describes a 16-byte in-memory index per blob, which suits workloads with very many small objects such as user uploads and thumbnails. It also exposes S3, HTTP and WebDAV through the filer and can keep filer metadata in stores such as PostgreSQL. Its README places data recovery and self-healing storage in the paid Enterprise Edition, so confirm which recovery procedures your team can run on the community release and budget for the tests that prove them.
Ceph RGW when Ceph already runs
Ceph RADOS Gateway provides S3 and Swift interfaces on a RADOS cluster that can also serve block storage through RBD and file storage through CephFS. Most of Ceph is dual licensed under LGPL 2.1 or 3.0. It fits when your platform team already operates Ceph and needs object, block and file storage on one cluster. It is a poor fit for a small team that only needs a Blob replacement, because a healthy Ceph cluster requires monitors, managers, OSDs and skilled operators. Ask your storage vendor or internal team to confirm the RGW features your application depends on before migration.
Confirm features before you choose
Whichever option you pick, list every Blob SDK call your application makes, including uploads, signed URLs, list pagination, public access and deletes, and test each one against the candidate store. Garage supports multipart uploads, CORS, presigned URLs and signature v4, but lifecycle rules only cover abort of incomplete uploads and expiration. Record which checks passed in a test environment that matches your production layout. Treat any feature not on the list as unsupported until you verify it yourself.
Avoid archived MinIO community code
The MinIO community repositories are archived and read-only, and the README says the community edition is distributed as source only, with no further pre-compiled binaries and no updates for legacy binaries. The last tagged community release is dated October 16, 2025. Existing deployments can still run, but new deployments should start from a maintained option, and the README points to commercial AIStor editions for support. Check whether any internal runbook, Helm chart or container image still references MinIO before you select a replacement.
Why MinIO community edition is a poor choice for new deployments
The MinIO community edition is no longer maintained, so a new deployment would start on code that will not receive fixes. The minio/minio, minio/operator and minio/mc repositories are archived and read-only, and the minio/minio README points readers to AIStor Free and AIStor Enterprise as alternatives. The last tagged community release is RELEASE.2025-10-15T17-29-55Z, published on October 16, 2025. The README also says the community edition is distributed as source code only, with no more pre-compiled binary releases, and that legacy binaries will not receive updates. A team that chooses MinIO today would be building from source, maintaining its own image pipeline and accepting that any security issue found after the archive will stay open unless the team patches it.
Support is the second gap. The README describes community support as best effort through GitHub and Slack, and says SLA-backed support is only available through AIStor. For a regulated organization, confirm whether a best-effort channel satisfies its vendor risk and incident response requirements before committing storage for files that may hold customer or patient data. Also confirm the licensing position with counsel. The community server is released under the GNU AGPL v3.0, and the README states that any commercial or proprietary use must be validated against AGPLv3 obligations, with commercial licensing available through AIStor. Whether your application's network use triggers source disclosure duties under AGPL is a legal question, not an engineering one.
If you already run MinIO, plan a move rather than expanding the cluster. Adding nodes or buckets extends the period during which you depend on unmaintained software and deepens the eventual migration. Inventory every application that calls MinIO, record the S3 features each one uses, and check them against the target you choose, such as Garage or SeaweedFS. Then run a copy from the MinIO bucket to the new store and verify object counts and checksums before switching clients. Keep the old cluster read-only during cutover so you have a clean rollback path, and set a retirement date with the owners of each dependent service.
How apps switch from the Blob SDK to an S3 client
This sequence moves stored files from Vercel Blob to an S3-compatible store you operate, with objects verified, application code repointed and every stored URL rewritten before the old store is retired. Each phase ends with a check your team can confirm.
Inventory buckets and objects through the SDK
Your team lists every Blob store and object using the Blob SDK's paginated list call, writing the pathname, size, content type, upload time and public URL for each object to a manifest file. The engineer who owns storage should run the export against production credentials and keep the manifest under access control. The step is done when the manifest's object count matches the count shown in the Vercel dashboard for each store, and any gaps are explained before copying starts.
Deploy the target store and a replica
Platform engineers deploy the chosen S3-compatible store on servers you control, sized for the stored volume and the expected request rate. Garage suits small clusters spread across sites and needs at least three nodes for three-way replication, while SeaweedFS suits workloads with many small files. Confirm sizing with the vendor documentation and your own load tests, and run a replica in a second location if your recovery targets require it. The step is done when a test object can be written, read and listed through both nodes or sites.
Copy objects and verify checksums
Using the manifest, a migration script downloads each object from Blob and uploads it to the target bucket with the same key, preserving content type and cache metadata. Once the copy finishes, the script compares a checksum of each source and destination object and records mismatches for retry. The step is done when every manifest entry has a matching checksum, and the migration log lists no unresolved failures.
Switch upload and download code to an S3 client
Application developers replace Blob SDK calls such as put and del with an S3 client configured with the new endpoint, bucket name and access key, keeping credentials in your secret manager rather than in source code. Presigned URLs for direct browser uploads should be generated by the S3 client using the store's signature version 4 support. The step is done when uploads, downloads and deletes succeed in staging and a test suite covering each file path passes against the new store.
Update CORS and access rules
Security and platform engineers review each application's browser access and reproduce it with the target store's CORS configuration and its per-access-key, per-bucket permission model. Garage does not implement bucket policies or ACLs, so public read access and write permissions must be expressed through its key-based rules, and features such as object versioning or object lock must be planned as application-level controls. Confirm the current feature list with the vendor's S3 compatibility page. The step is done when a browser test from each allowed origin succeeds and a key without write rights is refused.
Rewrite stored Blob URLs and add a CDN
Blob URLs stored in database rows, content fields, emails and cached HTML must be rewritten to the new hostname, usually with a scripted find and replace run against a database backup first. If you previously relied on Vercel's global edge caching, place a CDN or caching reverse proxy in front of the new store and set cache headers on objects. The step is done when a sample of rewritten records resolves to the new endpoint and no references to the old Blob hostname remain in the scan results.
Cut over and retire the Blob store
Operations staff schedule a short write freeze, run a final incremental copy of objects created since the first pass, switch the application's storage configuration to the new store and reopen writes. Keep the Blob store read-only for a period your team sets, then delete it after confirming that logs show no requests to the old hostname. The step is done when production traffic shows successful reads and writes against the new store and the final checksum comparison is recorded for audit.
What the self-hosted storage costs to run, by component
The main cost shift is that Vercel Blob bills metered storage and transfer as part of your Vercel account, while self-hosted storage is paid for as infrastructure you buy and operate. Vercel's pricing page lists its own metered units, and you should compare those against your actual monthly stored bytes, read and write operations and egress, not the plan headline. On the self-hosted side, the recurring costs are the storage nodes themselves, the network links between them, a reverse proxy or CDN in front, and backups. Garage's deployment guide recommends metadata on SSD and data on large HDDs, with XFS for the data directory and a checksumming filesystem such as BTRFS or ZFS for metadata. Its site lists minimum node requirements of 1 GB RAM, at least 16 GB of disk and 50 Mbps or more between nodes, and its guide recommends at least three nodes for three-way replication. Each of those lines is a server or disk line item to price.
Several factors move these costs most. Replication factor multiplies raw disk, so three copies across three locations means roughly three times the usable capacity you buy, and geo-distributed nodes add inter-site bandwidth that a single-datacenter cluster does not. Egress is often the largest variable on either side: a public bucket serving images through a CDN generates traffic your hosting provider may bill differently from your own proxy. Ask your provider for a quote that states the price per terabyte of disk, per server and per month for bandwidth, whether the figures include a hot spare or failover node, and whether backups of object data are priced separately. Ask the same of any managed S3-compatible service you consider as a fallback.
The part most often missing from a comparison is engineering time, which recurs. Someone must patch the Garage or SeaweedFS binaries, monitor disk health and replication state, rotate access keys, test restores and plan capacity growth. Garage's per-bucket permission model replaces IAM policies, so access reviews move into your runbook. Ask your implementation partner for a fixed-scope estimate covering setup, cutover, backup testing and handover, and separately ask what ongoing upgrade and monitoring support costs as a retainer. Confirm the hours and hardware with your own team before you compare totals against Vercel's invoice.
Questions teams ask before moving off Vercel Blob
How much effort and time does moving off Vercel Blob take?
The effort depends mainly on how many objects and how many gigabytes you hold, how many application services read or write files, and whether those services use the Blob SDK's upload helpers, public URLs or client-side uploads. A small app with one bucket and a handful of upload paths is a different job from a platform with many buckets, signed download flows and years of archived files. The work falls into four parts: provisioning and sizing the store, changing the SDK calls to an S3 client, copying existing objects with a checksum comparison, and cutting over reads. Ask any provider or partner to break the estimate down by these parts and by the number of services affected, and to state which assumptions about object count and data volume they used.
Can our engineering team move Vercel Blob data by itself?
Often yes, if the team already runs servers and has someone comfortable with S3 semantics. The SDK swap is ordinary application work, and copying objects can be scripted with an S3-compatible client. The harder parts are the operational ones: sizing disks, configuring replication for the number of nodes you run, setting up TLS and access keys, and writing a restore procedure you have actually tested. Garage and SeaweedFS both document their own permission and metadata models, so your team must check which S3 features the apps depend on before cutting over. A fixed-scope engagement with DeployOpen can cover planning, implementation, hardening and documentation, while your team keeps ownership of application changes. Decide which parts you can staff before you ask for a quote.
What does a DeployOpen implementation of object storage deliver?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For this migration, that typically means an agreed design for the storage cluster, its placement across zones or sites, the S3 client changes in the application, the data copy and verification plan, backup and restore configuration, and runbooks for routine operations. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. DeployOpen does not issue audit reports or certifications, so any compliance evidence it prepares is input for your independent assessor. Ask for the list of deliverables, acceptance criteria and what is excluded, such as application code ownership or ongoing support, which is available as a retainer.
Does Garage or SeaweedFS fit our node count and file sizes?
The fit depends on node count, file size distribution and how much metadata you expect. Garage is designed for a small number of geo-distributed nodes and recommends at least three nodes for three-way replication, with copies placed in different locations. SeaweedFS keeps a 16-byte in-memory index per blob, so very large numbers of small files raise memory planning. It can also use separate filer metadata stores, and it offers erasure coding for warm data. Confirm your object count, average size, growth rate and the number of sites before choosing. Check Garage's requirements for RAM, disk and inter-node latency, and confirm that your sites meet the stated network thresholds. Running a proof of concept with a copy of real object sizes is the most reliable test.
What happens to existing Blob URLs and CDN caching after the move?
Existing Blob URLs point to Vercel's hosted endpoints, so they stop working when you decommission the store unless you keep a redirect or rewrite layer. The clean approach is to move object keys to a new domain you control, update stored URLs in the database through a planned migration, and set a cache lifetime and invalidation plan so clients do not keep old links for longer than necessary. Public objects can sit behind your own CDN or reverse proxy, which you must configure and monitor. Garage supports presigned URLs and CORS, but its lifecycle rules are limited, so confirm which cache and expiry behavior your application needs. Test a sample of URLs from every upload path before cutover.
What recurring work remains once object storage runs on our servers?
The recurring work moves from Vercel to your team or your support provider. It includes backups of object data and metadata, restore tests, software upgrades, monitoring of disk health and capacity, certificate renewal, access key rotation and capacity planning as data grows. Garage and SeaweedFS both depend on the underlying filesystem and disks, so SMART alerts, filesystem checks and replacement procedures belong in your runbook. Licensing also recurs as a review item: MinIO's community edition is archived and no longer receives updates, so track license terms and release activity for whichever store you choose. Ask any partner which of these tasks are included in a fixed-scope project and which need a retainer.
Running the new store alongside the rest of the Vercel stack
Vercel Blob rarely moves alone. The application still runs Next.js, may still sit on Vercel for a while, and may later run on Coolify or Dokploy. These cards cover the decisions that connect the new object store to the rest of that stack during and after the switch.
Keep Next.js on Vercel while Blob moves
You can move storage without moving the application. The Next.js app can keep its Vercel deployment and call an S3-compatible endpoint you operate, as long as the server-side code can reach that endpoint over HTTPS. Confirm that Vercel's outbound network path to your store is acceptable to your security team, and test uploads from preview deployments as well as production, since each environment needs its own credentials and endpoint values.
Keep Blob for legacy URLs
Existing links to Blob URLs may live in emails, PDFs, cached pages and partner systems that you do not control. Keep the Blob store readable until you have a list of where those URLs appear, or add a redirect or proxy route for them. Decide whether old objects are copied, served from Blob until they expire, or rewritten in the database, and record that decision with an owner and a date.
Run storage next to Coolify or Dokploy
If the application later moves to Coolify or Dokploy, the object store can run as a separate service on the same servers or on a dedicated node. Keep it on its own volumes and networks, and confirm that the reverse proxy that handles app domains does not also terminate traffic for the storage API unless you intend it. Check where the store's data disks sit, since both platforms are operated by your team.
Separate public and private buckets
Blob offered public objects and private access controls, and the S3 side should keep the same split deliberately. Put only assets meant for anonymous viewing in a bucket with read access, and keep uploads, invoices and user documents in private buckets served through short-lived presigned URLs. Garage uses its own per-access-key, per-bucket permissions instead of bucket policies, so write down which key can read and write each bucket before the first upload.
Keep credentials in environment variables
Store the endpoint, access key and secret key as environment variables in each platform, never in client-side code or the repository. Use separate keys for production, preview and local development, and rotate them through the platform's secret handling. Vercel marks some values as secret and cannot return them later, so record where each value is held. Limit each key to the buckets it needs.
Account for the CDN you lose
Blob files were served through Vercel's global network. Files served from one self-hosted store reach users from one location unless you add a CDN, caching proxy or regional replicas yourself. Test download latency from the regions your users are in, set cache headers on public objects, and confirm that signed or private downloads are not cached in a shared layer where they should not be.
What the operator takes on after leaving Blob
Once files move to Garage or SeaweedFS, the team owns every duty Vercel handled invisibly, starting with node and disk monitoring. The question to settle first is who gets paged when a node drops out of a cluster, and how quickly. Garage's own requirements are useful here: its site lists at least 16 GB of disk, 1 GB of RAM and 50 Mbps or more between nodes, so alerts should cover free disk, memory pressure and inter-node latency, not just whether the process is running. For SeaweedFS, watch the master servers and volume servers separately, since the master tracks where volumes live.
Replication health is the second duty. With Garage, the question is whether each chunk still has its three copies in different zones after a node is lost, and how long the team accepts running degraded. Backups are the third. Object data and the metadata store must be backed up together, because a restored data set without matching metadata is unusable. Garage's deployment guide flags that LMDB files are not portable across CPU architectures and that corruption has been reported after unclean shutdowns, and it offers SQLite as a more robust alternative. Decide which engine you run before go-live, because changing it later is a migration in its own right. Ask your team whether power loss or kernel panics are likely on your hardware, since that answers how much the metadata engine choice matters.
Upgrades and restore testing close the loop. Garage tags releases such as v2.4.0 and v2.4.1, so plan a rolling upgrade procedure, confirm the release notes for each tag, and test it in a non-production cluster first. Restore testing is the duty teams most often skip: a backup that has never been restored is an assumption. Schedule a restore of a sample bucket into an isolated environment, check object counts, checksums and that the Blob-era application paths still resolve, and record the result. Confirm with the vendor or project which versions receive security fixes before you commit to a version policy.
How DeployOpen delivers Blob replacement
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Vercel Blob replacement, that means choosing the S3-compatible store that fits your footprint, moving the objects and the application's upload and read paths, and handing over a system your team can operate.
How we scope
- Inventory of Blob stores, object counts, public versus private access and the apps that read or write them.
- Choice between Garage and SeaweedFS, documented against your node count, site layout and file size profile.
- Written fixed scope listing deliverables, cutover steps and acceptance checks before any work starts.
How we build
- Deploy the chosen object store on your servers or cloud accounts with replication matched to the agreed layout.
- Switch the application from the Blob SDK to an S3 client, including CORS, presigned URL and lifecycle behavior.
- Test uploads, downloads, large files and failure cases, then record gaps such as missing versioning or object lock.
How we hand over
- Runbooks covering bucket and access key management, node replacement, backups and monitoring of the store.
- Migration record showing object counts, checksums and the DNS or configuration change for each application.
- Knowledge transfer sessions so your engineers can run the store and its upgrades without DeployOpen on call.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrade planning when new Garage or SeaweedFS releases are published, tested against your applications first.
- Ask in your quote which support hours, response paths and backup restore tests are included in the retainer.
