Hugo 101: Migrating images from services like Cloudinary

support
1

I am hosting on GitHub and thinking about hosting images somewhere else.

I am thinking to go with Cloudinary. What happens if in a few years I would decide that I have to migrate from Cloudinary to my own server or somewhere else?

How hard it is to migrate all the images?
How do you go about rewriting images URLs?

Keeping in mind I am not an advanced programmer – is this worth doing? Or is this a super complicated process and you would advise me to keep images inside the Hugo project?

Any pointers or other ideas on best practices for hosting images will be appreciated.

2

This is a decent Hugo topic, though I’d say it is something most site operators should consider, especially if they are all about visual stimuli.

My experience is from maintaining sites for orgs for long durations (over a decade), and making strategic hosting choices in field of technology choices. Here are some random tips:

  • Divide assets logically, thinking long-term. For NPOs we often have an archiving obligation for things like meeting minutes, whereas someone wants to upload every photo from every event to the blog. Those are two different buckets, and can be configured to make sense for their purpose (caching, storage, etc).
  • Choose a file layout, stick with it. If your files are consistent, paths and all, then it is relatively trivial to switch CDN or media assets URLs. A single redirect directive to a web server can handle a new domain.
  • Consider date-based assets, cache appropriately. Learned from a decade of dealing with WordPress sites that have the checkbox for “month-based folders” on uploads checked, and those those that do not. A single flat hierarchy isn’t as flexible as distinct, logical collections. How often do you go back to September, 2017 to edit the images uploaded then?

Cloudinary is a dope service, and I would not use it. I use Hugo because I follow the dream of the 90s, live in Portlandia, and serve static hypertext documents for public consumption. I expect folks to download the full assets I offer, once, and to be cached forever, per browser. I’m a system 2 web developer, and that extends to media prep. Cloudinary seems great for not having to deal with media, just upload and forget.

Cloudinary’s functionalities, those are things I would not count on being available in the future.

Good thinking about your exit strategy, by the way. That’s how I evaluate a service: what happens when I move away? :slight_smile:

1 Like
3

Thanks for the awesome answer! I think I am looking for similar approach. It’s super-valuable to get this advice from somebody a lot more advanced in front-end.
Some follow up questions:

Can you talk in ELI5 how a simple transfer from service like Cloudinary would look like?

So let’s say my blog would have 150 posts and 100 images per year. Because of some special functionality – I was planning to keep content in one flat folder with a sub-folder for images (no Hugo sections). Would you advise me to reconsider doing content/2019 or even content/2019/January?

P.S. :wave: from Seattle, might be moving to Portlandia in the fall

4

Basically, everything after the domain should be consistent. If your assets are always loaded from a sub-domain (ex. CDN), it doesn’t matter which sub-domain, you can always handle that with a redirect (I’ll follow up on this below). So if you are serving a file at assets.example.org/2019/07/example.png, you can setup a new domain or the same one at a new service, as long as you keep the file paths the same.

On the other hand, if you don’t like the old file layout and decide to change where things live, say during a migration, bad news bears, you have this whole other logic you’ve got to rewrite somewhere, potentially many somewheres.

But ya know, moving archives between services and keeping the file paths consistent, that’s pretty easy to do. Kinda presumed.

Hmmm. I’d consider how big the assets are, and where I’m storing them. Hugo modules allows you are arbitrarily pull in repos to build your site’s filesystem, so you could just do yearly or monthly asset repos. I’ve heard mention of size limits on MS-Git repos, so modules works with that paradigm.

Actually, modules and filesystem mapping is so awesome, I’d probably start with a yearly archive, and then break it down more if I need. Maybe I won’t.

I meant the show, specifically the pilot’s music video song. But if you are moving around between Seattle and Portland, congrats, you must be crushing it. I’m barely holding on here in Oakland. :grimacing:

Okay, earlier I said I’d follow up on redirects: they should not be used very often! If one is constantly redirecting and moving assets around to different domains, it creates more trouble than it solves.

In my hobby time I’ve been playing around with creating a digital asset manager interface-type themey thing in Hugo, using UUID to create HTML/API output for images and videos. And video archives gets big, fast. Still, date-based folders loaded on a CDN seems to be best config I’ve found. :slight_smile:

1 Like
5

Thanks for this in-depth and comprehensive round down. Very helpful!

So I added this image in Cloudinary to the 2019 folder https://res.cloudinary.com/dfc64lcoh/image/upload/v1566417354/2019/image1.png

Let’s say I would want to switch to another CDN and my image would be in:
foo.com/2019/image1.png

What would be the best practice for a simple Hugo redirect?

P.S. Yep traffic in the Pacific North West in pretty insane

6

Hugo doesn’t do the redirecting. It has ways of telling web servers to do redirects, but those depend on which web server is receiving the traffic for the redirect. To figure out what, or if, Hugo does with redirects, start with the server the old domain is pointing at.

7

Got it. Thanks. Have a good day!