How I Used Cloudinary for Ecommerce Image Management
A deep dive into building a scalable ecommerce image management system using Cloudinary, Multer, PostgreSQL, and Node.js.
By Uttam Thapa · · Ecommerce
⚡ Executive Summary (TL;DR)
Storing product images on the application server or inside the database fails for the same reason in both cases: neither is built to deliver media. This is the
full media pipeline behind Golden Leaf Knots and Velvet Loop on Cloudinary —
signed uploads so no secret reaches the browser, transformation presets instead of hand-cut variants, CDN delivery, and cleanup that
keeps orphaned assets from accumulating.
Figure 1: One upload, many derived renditions — generated on demand rather than stored ahead of time.
Introduction
Product images are one of the most important components of any ecommerce platform. Before a customer reads a description, checks specifications, or compares prices, they see the product image.
While building Golden Leaf Knots and Velvet Loop, I quickly realized that image management is much more than simply uploading files. A production ecommerce platform requires reliable storage, fast delivery, scalability, security, and efficient media management.
This article explores how I implemented a scalable image management system using Cloudinary and why it became a critical part of the overall ecommerce architecture.
Why I Needed Cloudinary
Initially, storing images directly on the application server seemed like the easiest solution.
However, several problems quickly became apparent.
Problems With Local Storage
- Images consume server disk space.
- Deployments may overwrite uploaded files.
- Server migrations can break image paths.
- Scaling storage becomes difficult.
- Backup management becomes more complex.
Problems With Database Storage
- Large database size.
- Slower queries.
- Increased backup costs.
- Poor image delivery performance.
I needed a dedicated media solution built specifically for image storage and delivery.
Cloudinary provided:
- Dedicated image hosting.
- Global CDN delivery.
- Automatic optimization.
- Easy upload APIs.
- Reliable cloud storage.
- Scalable infrastructure.
For a production ecommerce platform, Cloudinary was the ideal choice.
Before Cloudinary
The initial implementation relied on local image storage.
images/
↓
Upload File
↓
Store Path
↓
Save In Database
Although simple, this approach introduced several maintenance challenges.
Issues Faced
- Image URLs broke after deployments.
- No CDN support.
- Server storage usage increased.
- Production maintenance became harder.
- Scaling image delivery was difficult.
As the ecommerce platform evolved, migrating to Cloudinary became necessary.
Types of Images Stored
The image management system currently supports multiple image categories.
Product Images
- Keychains
- Personalized Gifts
- Crochet Products
- Accessories
- Handmade Items
Gallery Images
Additional images used to showcase products from multiple angles.
Admin Uploaded Media
Images uploaded directly through the admin dashboard.
Future Media Types
- Hero Banners
- Category Images
- Marketing Assets
- Promotional Graphics
How Image Upload Works
The upload process follows a structured workflow.
Admin Selects Image
↓
Frontend Form Submission
↓
Backend Receives Request
↓
Multer Processes Upload
↓
Cloudinary Upload API Called
↓
Cloudinary Stores Asset
↓
Cloudinary Returns URL
↓
Database Updated
↓
Product Published
Separating image storage from application storage makes the architecture significantly more scalable.
Cloudinary Configuration
Cloudinary credentials are stored using environment variables.
CLOUDINARY_CLOUD_NAME
CLOUDINARY_API_KEY
CLOUDINARY_API_SECRET
These credentials are never exposed to the frontend.
The backend acts as the only trusted layer that communicates directly with Cloudinary.
Backend Implementation
The backend uses dedicated libraries to manage uploads and communication with Cloudinary.
Packages Used
cloudinary
multer
Multer Responsibilities
- Multipart Form Processing
- Upload Handling
- Request Parsing
Cloudinary SDK Responsibilities
- Image Uploading
- Storage Management
- URL Generation
- Cloud Delivery
Together these components provide a complete media management pipeline.
Database Storage Strategy
Images themselves are not stored inside PostgreSQL.
Instead, the database stores only the Cloudinary URL.
https://res.cloudinary.com/...
This approach offers several advantages.
- Smaller database size.
- Faster database queries.
- Improved scalability.
- Simpler backups.
Future improvements may also store:
- Public IDs
- Image Dimensions
- Metadata
- Transformation Information
Image Display Flow
Displaying product images is intentionally lightweight.
Customer Opens Product Page
↓
Frontend Requests Product Data
↓
Backend Returns Product Record
↓
Database Returns Image URL
↓
Frontend Renders URL
↓
Cloudinary CDN Delivers Image
↓
Customer Views Product
This architecture ensures extremely fast image delivery.
Image Optimization Benefits
One of the biggest advantages of Cloudinary is automatic optimization.
Global CDN Delivery
Images are delivered through geographically distributed servers.
Compression
Images are automatically optimized for performance.
Faster Product Pages
Reduced file sizes improve loading speed and user experience.
Scalability
Traffic spikes are handled by Cloudinary infrastructure rather than the application server.
Future enhancements may include:
- WebP Delivery
- AVIF Support
- Responsive Images
- Dynamic Transformations
Replacing Product Images
Products occasionally require updated images.
The current workflow is:
Upload New Image
↓
Cloudinary Generates URL
↓
Database Updated
↓
Frontend Displays New Image
This allows product media to be updated without affecting other application components.
Deleting Images
Current cleanup focuses primarily on database consistency.
When a product is removed:
- Database record deleted.
- Image URL removed.
Future versions may automatically remove unused Cloudinary assets to prevent orphaned media.
Security Measures
Image uploads require multiple layers of protection.
File Type Validation
Only supported image formats are accepted.
Upload Restrictions
Invalid files are rejected before upload.
Backend Validation
Every upload passes through server-side verification.
Credential Protection
Cloudinary secrets remain protected through environment variables.
Controlled Upload Pipeline
All uploads pass through the backend before reaching Cloudinary.
These safeguards significantly improve platform security.
Challenges Faced
The most time-consuming issue involved Cloudinary configuration.
Symptoms
- Uploads failed unexpectedly.
- Images did not appear.
- API requests returned errors.
Root Cause
Incorrect environment variable configuration.
Solution
- Verify Cloud Name
- Verify API Key
- Verify API Secret
- Validate Deployment Variables
Once configuration was corrected, uploads became reliable.
Deployment Challenges
Several deployment-related issues surfaced during production rollout.
Render Backend
- Environment variable setup.
- Upload testing.
Frontend Integration
- Image URL handling.
- Rendering validation.
CORS Configuration
- Cross-origin upload requests.
Extensive testing ensured uploads worked correctly across environments.
Why Cloudinary Was Better
Compared To Local Storage
- No storage management.
- Easier deployments.
- Better scalability.
- CDN delivery.
Compared To Database Storage
- Smaller database.
- Better performance.
- Faster backups.
Compared To AWS S3
- Faster setup.
- Built-in optimization.
- Simpler transformations.
- Developer-friendly workflow.
For Golden Leaf Knots and Velvet Loop, Cloudinary provided the best balance of simplicity and scalability.
Lessons Learned
Implementing image management taught several important lessons.
- Media should be decoupled from application storage.
- CDNs significantly improve user experience.
- Environment variables require careful management.
- Image optimization affects ecommerce performance.
- Scalability decisions should be made early.
What appears to be a simple image upload feature often becomes a critical architectural component.
Future Improvements
- Multiple Product Images
- Gallery Management
- WebP Delivery
- AVIF Delivery
- Dynamic Resizing
- Watermarking
- Lazy Loading
- Automatic Cleanup Jobs
- Image Analytics
- Admin Image Editing
Key Takeaways
- ✓Never store product media on the application server. Deployments overwrite it and migrations break every path.
- ✓Never store images in the database. It inflates backups and slows every unrelated query.
- ✓Sign uploads on the backend. The API secret must never be reachable from the browser.
- ✓Derive renditions with transformation presets rather than uploading a variant per size.
- ✓Serve modern formats automatically. WebP and AVIF negotiation costs nothing and halves transfer.
- ✓Delete the remote asset when the record is deleted. Orphaned media is a bill nobody notices for months.
Conclusion
Cloudinary turned image management from an infrastructure burden into a service the platform simply calls. Instead of hand-managing file storage, CDN delivery,
optimisation and scaling, both Golden Leaf Knots and Velvet Loop hand media to one system and spend their engineering time on business functionality — which is
the whole argument for the decision.
If you are building the storefront that consumes these images, Core Web Vitals in React applications
covers why the hero image is almost always the metric you are being measured on.
Frequently asked questions
Should product images be stored in the database?
No. Image bytes inflate the database, slow down backups, and make every unrelated query more expensive. Store the images in a media service and keep only the URL or public id in the database.
Why not just save uploads to the application server's disk?
Deployments replace the filesystem, so uploaded files vanish or fall out of sync between instances. Any platform that runs more than one container makes local disk storage actively wrong.
How do you stop your upload API key leaking to the browser?
Sign uploads on the backend. The server generates a short-lived signature for one specific upload; the browser sends the file directly to the media service with that signature and never sees the secret.
Home · Projects · Blog · Services · Résumé · Contact