store images locally vs cloudinary vs s3

5
votes

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.

1
laravelimageamazon-s3sharedcloudinary
I would suggest going for a solution that you can change quite easily if you want/need to. If you have the space on your server and your traffic isn't going to be that high then I would say keep it local for now (unless there is a specific reason not to). Have a look at docs.spatie.be/laravel-medialibrary/v7/introduction and github.com/spatie/laravel-medialibrary/issues/1185 – Rwd
Thanks for the reply. Is this package basically an api for dealing with images? what is the difference between this and Intervention package? Also, would a few thousands of users a month is considered low or high traffic? – nscode
I would say that's quite low traffic. Intervention image is a package that is for manipulating images, media-library does this too but also provides a way to handle the storage and different manipulations of images. It's only a suggestion though, it might be that it doesn't suit your needs but it might give you a starting point if nothing else. – Rwd

1 Answers

7
votes

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 :) ).