store images locally vs cloudinary vs s3

today

The settings:

Blog with posts, buily with Laravel, where:

  • Every post can have max of 1 image (nullable).
  • Max posts in the blog is 1000. Let's assume there are 1000 posts for the discussion.
  • Every post has a comment section. Where registered users can comment and include an image in their comment. Lets assume every post has 2 images in the comments.

So in total it counts to 3000 images* that need to be stored (and resized I guess), presented, and etc.

This is the ideal amount in the long range, I'm not looking for a "scaleable" solution, since there is not going to be a crazy exponential growth.

*In reality for the time being it is less, and I assume that for these amounts of media files it doesn't really matter if its 1000/1500/2000 or 3000.. Correct me if that's wrong.

Few extra things to note:

  • I'm hosting it in shared hosting (I can store up to 300k files).
  • I want it to be secured, so no malicious file is uploaded in the cover of an image file.
  • I'm looking for a budget solution (so if s3 will start charging hard after 12 months it makes it not relevant), preferably free (.

So the dilemma is between storing all images locally in Storage folder (manipulating images with some Laravel package). Other possibility is cloudinary, which I don't know much about, just that it enables to store/manipulate/backup/use their api to present the images I stored there.

If I choose to do it locally - is it safe to store a user uploaded image locally? how do I make sure it's not malware in disguise of an image file?

With this amount of images/content can it cause performance issues in the shared hosting when storing locally?

What would be the advantages of using cloudinary for me?

Thanks.

3

1 Answer

Cloudinary can actually help a lot in this case. Instead of storing the resources locally and writing something up to manipulate them, you could integrate Cloudinary in the project.

This would free up server space. Storing images locally may or may not impact performance, depending on the architecture, but freeing server resources is always a good practice.

Also, manipulation and delivery of images could be done on the fly when first requested (or eagerly before they are requested if you want to) by a simple API call. So you don't need to make up something new, but leverage already existing API.

Cloudinary also has a fully-featured free tier that you could use. If you don't expect exponential growth at the moment, that tier would be more than enough for the project

Full disclosure: I'm currently working at Cloudinary, (but the above still holds :) ).

4

ncG1vNJzZmirpJawrLvVnqmfpJ%2Bse6S7zGiorp2jqbawutJobHJwYWV%2Fc4GOrKuoqpVitq6txp6qZqSfmK6tuNhmraxlk6G8trDIp5irsV2rwG6%2Fkg%3D%3D