Upload folders ship with code and images are lost—should files be stored locally or in object storage?

Where uploaded files should be stored depends first on the number of instances expected over the next year, the growth rate of total file volume, and whether files need external distribution: For a single-instance or small-volume internal system, storing files on the server local disk with regular backups is usually enough; if you can foresee multi-instance deployment, CDN acceleration or external links, or continuous growth in total file volume, the common 2026 practice is to use object storage directly, leaving only a temporary staging directory locally. Experience range: when individual files are generally within tens of MB, total volume is within one to two hundred GB, and there are only one to two servers, local storage has lower maintenance cost; once outside this range, the cost of migrating later is often significantly higher than using object storage from the start. Conversely, if it is only an intranet small-team transfer with a few MB added per day, forcing object storage may only add complexity around authentication and cost accounting.

1. Local disk and object storage: the difference is not only the path

Many people understand this as a difference in paths, but the real difference centers on access method, scaling method, permission model, and cost structure. Local disk uses file system semantics: you can read and write by writing a directory. Object storage uses HTTP interface semantics: first obtain credentials, then access by bucket and object key. This adds a layer of network and authentication, but in exchange gives capacity without a hard upper limit and natural cross-instance sharing.

The dividing line appears at the moment of 'multiple machines.' With a single instance, local disk is nearly zero cost. Once expanded to two or more, you either mount the directory as shared storage or accept that 'upload to machine A, request routed to machine B returns 404.' This is also why many systems change storage only when they add load balancing.

• Storage and access method: Local is file path plus system permissions; object storage is HTTP API plus key or temporary credentials.
• Scaling method: Local is limited by single-machine disk; scaling often requires downtime or disk migration; object storage scales on demand, generally invisible to the business side.
• Multi-instance sharing: Local requires extra NFS or shared disk, concentrating single points of failure; object storage is naturally shared.
• External distribution: Local requires your own Nginx or CDN origin pull; object storage usually connects directly to CDN and temporary signed URLs.
• Cost structure: Local is one-time disk purchase plus operations labor; object storage is storage fees, request fees, and egress traffic fees, and traffic can exceed expectations.

2. Run through the five-question checklist before you start

Storage solutions are not good to decide by gut feeling. Based on project delivery experience, running through the following five questions first can filter out most later rework. The first three determine direction; the last two determine implementation details.

1. How many instances will this service have in the next year? If only one and no short-term scaling, local disk comes first; if expecting two or more, design for object storage directly.
2. What are the approximate total volume and growth rate of uploaded files? Estimate one-year usage by monthly additions. Experience range: when total volume reaches several hundred GB or more, or monthly additions exceed several tens of GB, local disk management cost rises noticeably.
3. Do files need to be accessed by external parties or third parties? If you need generated external links, mobile direct upload, or CDN acceleration, object storage is less trouble.
4. Does the team have object storage accounts, a permission system, and cost accounting habits? If not, fill these gaps first; otherwise problems such as 'buckets set to public read-write' are easy to appear.
5. Are there compliance and data ownership restrictions? Some industries require data to remain in a self-owned environment or a specific region; in that case local or private object storage is more suitable.

3. Delivery reality: trade-offs among budget, timeline, and assets

At project delivery sites, storage choices are often not a contest of technical superiority but are pushed by constraints. A common combination is tight budget, only a few weeks of timeline, and only one operations person. The more pragmatic approach is to launch with local disk first, while abstracting the upload interface into a unified entry point (for example, upload, delete, and getUrl methods), with one local implementation and one object storage implementation; when volume or instance count really grows, change only the implementation, not business code.

Another common situation is that the client already has a cloud account but no one manages permissions. During delivery, first check the bucket read-write policy, key storage method (do not hard-code keys in code or frontend), and lifecycle rules for cleaning temporary files. Based on project delivery experience, these items should be written into the go-live checklist to avoid emergency firefighting after a publicly readable bucket is scanned. Based on typical ranges, when upload entry points are centralized, the change to swap storage implementations is usually half a day to two days; when entry points are scattered, it may stretch beyond a week, plus regression testing.

4. Verifiable comparison: experience ranges for local disk and object storage

The following comparison is not precise pricing, but common magnitudes in 2026 projects, used to judge direction:

• Initial integration time: Local is usually half a day to one day; object storage with centralized entry points is about half a day to two days, and if bucket policies, key rotation, CDN, and frontend direct upload are involved, it may add another one to two days.
• Daily operations cost: Local routine capacity and backup checks are a typical range of half an hour to two hours per month; object storage mainly involves traffic and permission audits, with a typical range of one hour to several hours per month.
• Cost structure: Local is one-time disk or cloud disk fees, plus backup storage and labor; object storage is storage fees, request fees, and egress traffic fees. Storage fees are usually not high, but when external distribution volume is large, traffic fees can be noticeably higher than storage fees.
• Scaling and migration: Local scaling often requires downtime or disk migration, with an experience range of several hours to one day; object storage scales on demand, generally invisible to the business side, but migrating existing files still needs a window, with a typical range of several hours to several days.

If the number of instances will not increase in the next year and total volume is controllable, local disk has better value; if two of the three items are close to their limits, prioritize designing for object storage.

5. Common pitfalls that usually come down to details

• Putting the upload directory inside the code release directory, so one release wipes all files. The upload directory should be separated from code and logs and explicitly excluded in deployment scripts.
• Directly using the original filename uploaded by users, causing same-name overwrites, special characters, or path traversal. A common practice is to regenerate the filename on the server and store only the original filename in the database.
• Restricting size and type only on the frontend. Frontend restrictions are for experience; server-side validation is the baseline.
• Setting object storage bucket permissions to public read-write. The default should be private plus temporary signed URLs; only publicly displayed resources should be opened separately.
• Deleting files and deleting records out of sync, eventually creating orphan data where 'the database has a record but the file is lost.' It is advisable to keep a regular reconciliation task.

6. Applicable scenarios and boundaries

When local disk is suitable: single-instance deployment, files only flow within an intranet or small team, total volume within several hundred GB, and operations can accept self-managed backups; or the product itself must be privately deployed to the client data center. When object storage is suitable: multi-instance deployment is expected, external links or CDN distribution are needed, file volume continues to grow, and you want backups and multiple replicas handled by the platform.

When you do not need to force object storage: attachments for internal management systems, documents growing by a few MB per day, temporary export files; in these scenarios, introducing object storage often only adds complexity around authentication, networking, and cost accounting, with limited benefit. The boundary can be remembered in one sentence: the trouble with local storage is scaling and sharing; the trouble with object storage is permissions and cost. First judge which one you can less afford. In 2026, a compromise used by many teams is: business attachments stored locally, user-facing images and videos on object storage.

Frequently asked questions

For a small single-machine system, is storing directly on local disk unstable?

As long as it is a single instance, the upload directory is separated from code, and there are regular backups to another disk or another machine, stability is usually sufficient; the main risks are disk full and accidental deletion, so capacity alerts are recommended.

If switching from local disk to object storage, does business code need many changes?

If upload logic is concentrated in a few entry points, the change is usually just replacing the read-write implementation; if upload code is scattered everywhere, the experience range is that change points increase noticeably, so centralizing entry points early is less work than refactoring later.

Does object storage always need CDN?

Not necessarily. When traffic is low and usage is limited to a specific region, using the object storage domain directly is fine; when cross-region access or concurrent downloads become noticeably slow, adding CDN is usually more cost-effective.

How should the upload file directory structure be organized?

A common practice is to divide directories by business or date, for example business name plus year-month, which makes cleanup by time easier and avoids slow listing operations caused by too many files in a single directory.

If files are already stored locally, when is it more suitable to switch to object storage?

When multiple instances appear, disks alert continuously, external links or CDN are needed, or monthly additions rise noticeably, that is a common switching window; before switching, first consolidate upload entry points, then swap the implementation.

The next step is specific: first count the number of instances and file growth for the next year, then consolidate upload logic into a unified entry point, and finally confirm permissions, backups, and capacity alerts according to the go-live checklist. The applicable scope is self-hosted or hybrid-deployed business systems; if files only flow within a small intranet range and total volume is controllable, keep local disk with good backups, and do not migrate just for uniformity.