Bloggers where do you host images?

#discuss #watercooler

I usually upload all blog related images in a separate Google Drive folder and then use public links to add them in my blogs.

How you guys do it? Any other service?
Have you guys tried imgur? How is it?

I have been recently thinking to automate this but Google Drive API is a mess
:-|

Top comments (15)

Sandor Dargo • Feb 6 '21

I keep them in the same GitHub repo es the rest of the content

Bhupesh Varshney 👾 • Feb 6 '21

I do this for header images
Aren't you afraid the repo size will blow up one day?

Sandor Dargo • Feb 6 '21

I don't use a lot of images, so it's fine for the time being. What do you consider a critical size for a repo?

Kóredé Bashir • Feb 6 '21

I use the Image Upload option on DEV these days, but I used to upload image files on GitHub (repos).

Amey Sunu • Feb 6 '21

I add all my images in a folder within the root itself, and also at times upload it on imgbb.com. It’s a free image hosting service.

Thomas Broyer • Feb 7 '21

I must say I find this to be a very strange question.
What's your reason for adding complexity to your workflow compared to storing them right next to your content?

Bhupesh Varshney 👾 • Feb 8 '21

Mostly because git repositories weren't meant ro to store media files, 🤔
Moreover my repo size would eventually get large as I write more (think 5+ years) since I add gif demos etc. making it hard to clone/maintain the repo.

Thomas Broyer • Feb 8 '21

I disagree.
The problem with binary files in a DVCS is when they exist in the history but no longer in any tip of branch, because you pay their weight without them actually being useful. In other words, versioning binary files should be avoided if possible, but that mostly applies to big binary files. Another way to look at it is that if Git wasn't meant to store binary files, then maybe it wouldn't give you the means to actually handle them anyway: git-scm.com/book/en/v2/Customizing...
And there you're storing files that are very likely to never disappear and never be updated (well, that depends on your workflow of course), so the file you're committing to your repo will also always be checked out.
Thinking 5+ years, what will grow is the size of the working tree. If you were to zip it and share the zip file, you'd have the exact same "problem". Adding a VCS to it isn't really the problem here (of course it'll almost double the size on disk, as each file is stored in the history in the .git/, and in the working tree, but that's true of any VCS, and needs to be balanced against the benefits a VCS gives you).
Lastly, if you have that possibility, you can use Git LFS for bigger binaries (think videos or big GIFs); both GitHub and GitLab support it. AFAICT, the binary won't be in your .git/, only in your working tree.