Ask HN: Where do you host images for your blog or landing pages?

When it comes to GitHub repo, what does the URL of the image look like? Is some kind of hash added to the filename? At the moment I use media files from my WordPress blog to store images.

I guess I'm behind the times, but I just store them on the file system where I am serving the website from.

In the same place. Why anything else? Much simpler, and no extra HTTPS connection to make, and probably within ε on file delivery performance (though that’s heavily subjective). There’s almost never any reason to do it any other way.

I have an entire repo set up to share images via iPic - I just select an image locally and with a keyboard command updload it and add the url to my clipboard

https://github.com/toolinbox/iPic

The image is placed in my website directory and then my static site generator, jekyll, uses a relative path tag to generate the path for the final compiled website on my machine. This static website is then uploaded to github. If I was uploading elsewhere, the workflow would be the same. Only the relative path is hardcoded and the domain therefore doesn’t matter. The true filepath is to some github link in my “_site” directory, but neither I nor the user see it. Static sites are very easy to manage in this way.

I commit to a github repo and that gets deployed to cloudflare pages. https://pages.cloudflare.com/

I use Zola the static site generator. My repo is here https://github.com/purton-tech/cloak/tree/main/www

Just curious, what do you use for hosting the blog or landing page itself?

For example, we use GitHub Pages for hosting the landing page. So for hosting images, we use GitHub itself and it mostly works.

For the blog, we currently use Substack, but thinking of maybe moving it to GitHub Pages too.

FYI, here is our repo: https://github.com/dstackai/dstack

It’s probably not the cool answer but aws s3.

If you aren't getting hundreds of requests per second, and the resources aren't huge, there's really no reason why you can't host them yourself. Especially with webp, the bandwidth is negligible.

If you're really worried, cloudflare can help with caching. FWIW, this is served off domestic broadband with cloudflare caching: https://search.marginalia.nu/explore/random It's survived the HN front-page, despite being a bit of a pathological case since the images are random out of a pool of tens of thousands. Images are also larger than they appear visually. Native res is like this: https://search.marginalia.nu/screenshot/187889

That depends.

Some files are files that are part of the web site. They are put there by the developer(s) of the web site. Things like maybe the logo image in the header, or that cool rotating flaming skull in the footer. These files just go on the file system of the web server.

Some files are user uploads. A person writing a blog post wants to upload some images to be inserted into that blog post. For these sorts of files I just use whatever object storage system makes the most sense given the circumstances S3, GCS, etc.

Okay this might be an overkill but my images are on CloudFront. I store them in S3, which get served through the CDN. It’s practically free at my scale. The actual blog is a GitHub pages site.

You can go surprisingly far with a $5/mo Digital Ocean droplet and the Cloudflare free tier. Just host your website the boring way, put CF in front of it and they will cache and serve all of your static content for free.

S3 has no minimum fee. For a small site they'll probably send you a 4 cent invoice each month. You can then throw cloudflare in front of the S3 box for free.

Alternatively, as others have said, you can just plop them on the server and call it a day.

  1 GB per month / 0.00390625 GB average item size = 256.00 unrounded number of objects
  1 GB x 0.0230000000 USD = 0.02 USD
  100,000 GET requests in a month x 0.0000004 USD per request = 0.04 USD (S3 Standard GET requests cost)
  40 GB x 0.0007 USD = 0.028 USD (S3 select returned cost)
  0.023 USD + 0.04 USD + 0.028 USD = 0.09 USD (Total S3 Standard Storage, data requests, S3 select cost)
  Internet: 40 GB x 0.09 USD per GB = 3.60 USD
  
  Total: $3.69

  1,024 GB per month / 0.00390625 GB average item size = 262,144.00 unrounded number of objects
  1024 GB x 0.0230000000 USD = 23.55 USD
  1,000,000 GET requests in a month x 0.0000004 USD per request = 0.40 USD (S3 Standard GET requests cost)
  1,024 GB x 0.0007 USD = 0.7168 USD (S3 select returned cost)
  23.552 USD + 0.40 USD + 0.7168 USD = 24.67 USD (Total S3 Standard Storage, data requests, S3 select cost)
  262,144 number of objects x 0.000005 USD = 1.31072 USD (Cost for PUT, COPY, POST requests for initial data)
  Internet: 1024 GB x 0.09 USD per GB = 92.16 USD
  
  Total: $118.14

for https://prose.sh we use https://imgs.sh

Have done both “local” (site host) and Cloudinary. With static sites in particular, a lot of it depends on your preferred site-building tool. The Hugo static site generator does a pretty impressive job of managing and processing images out of the box while, with most other SSGs, you’ll need to wrangle plugins and packages and you won’t get the same high performance. Thus, apart from Hugo sites, Cloudinary may end up being a better solution — although you’re right about its UI, and I’d say the same thing about its documentation. Even if you do use Hugo, it may be better to go with Cloudinary so you can avoid having to keep a lot of images in the site repo.

Some meta-commentary about some of the replies ... so far, there are 4+ replies suggesting the obvious step of storing in the images on the same web server host. But I notice the submitter is software engineer ex-Stripe, ex-Yelp, ex-Adobe... so I'm guessing he already knows that simple setup but doesn't locally host gifs & vids for technical reasons (bandwidth?, latency?).

Maybe recalibrate the suggestions based on the above. (Or the submitter can further clarify why hosting local image assets instead of using a CDN is not feasible in his particular case so the crowdsourced answers can be more productive to his goals.)

EDIT add: Sure, obvious technical answer may be applicable but some replies have a bit of condescension that doesn't seem appropriate and respectful of this person's tech background.

My site is generated by Jekyll and then I just sync to S3 and serve it all through CloudFront - works pretty well https://atomic14.com

Scene7 or Cloudflare or AWS Cloudfront.

>use GitHub repositories for hosting images

I don't know the current state of doing this, but it has been problematic in the past because they don't return the right content-type headers.

Vultr object storage

On the same server i have my website on. It's easy to implement and i don't have headaches due to GDPR. Performance is good, if it's properly optimized. I also add Hotwire Turbo if necessary.

I just commit them to the git lfs (in my case via netlify). Larger sites benefit from actual asset management systems though.

Colby from Cloudinary here what framework / tooling are you using? Sorry you haven't had a great experience with the UI, but if you stick around with Cloudinary, I would suspect there's a lot of solutions where the processing / uploading can be automated, such as using a Cloudinary plugin within a headless CMS (like Contentful) where you just use a URL or plugins like the Gatsby plugin: https://github.com/cloudinary-devs/gatsby-transformer-cloudi... (only supports images so far)

If you're on the Netlify side of things, I have a plugin there that automates images https://github.com/colbyfayock/netlify-plugin-cloudinary/

There's a ton others too: https://cloudinary.com/documentation/cms_ecommerce_integrati... https://cloudinary.com/documentation/partner_built

Hope that helps, happy to brainstorm other ideas as well!

My own Web-site is mostly static, so images (I don't use video) are in the file system. For customer's it is sometimes more complex: The setup of dynamic Web-site content happens in a database application. The images are stored in their raw format in a database and transfered to the file system of the Web-site in the right dimensions and scale when their associated data-set (such as a specific product information, etc.) is to be published. This makes it easy to reuse the images in other contexts, e.g. PDFs, or to adapt to changes in the Web-site layout, e.g. low resolution/high compression for mobile.