The blogging service noh uses Firebase, but images stored in Cloud Storage are delivered via Cloudflare CDN. This will explain the method.

The setup method is almost the same even if you are not using Firebase Cloud Storage.

This time, we are using Cloud Storage for Firebase, but if you want to reduce costs, it might be worth considering using Cloudflare R2 instead.

A: Cloud Storage seems to behave like a CDN even without CDN settings (though the communication fees should remain the same). It won't be a problem for applications that don't have a lot of access. However, using a CDN can provide benefits in download speed and can reduce costs when there is a high volume of access.
Also, if there are requirements such as difficulty in changing the image URLs later, I believe it should be implemented early on. For example, this blog contains image URLs within the markdown, so changing the image URLs later can be quite challenging.

A: This section explains how to configure the settings to make all (or some) objects inside the bucket public. This allows them to be read from the URL, ignoring Firebase's security rules (however, writes can still be controlled by the security rules). It is advisable to create a separate bucket for public access.

I am using the default bucket for private use. Here I am using Firebase security rules to read.

We will decide on the subdomain to be used for distribution. The reason for deciding this in advance is that the subdomain used for distribution must be the same as the bucket name. In this article, we will use storage-noh-production.noh.ink.

This is written somewhere in the official documentation.

To create a subdomain bucket in Cloud Storage, it is necessary to prove domain ownership. If you attempt to create it in the Firebase console without doing this, it will fail (it will only display An error occurred while creating the bucket, so you won't know why it failed).

The requirements for the bucket name are described in the document.

The verification of ownership is done through the Search Console. Generally, it can be completed by just clicking the buttons, but if you encounter a 404 error or it fails, it might be a good idea to change to the following method.

I will add a bucket. The important point is that the subdomain name will be the bucket name. Here it is set as storage-noh-staging.noh.ink. If the location is set to Tokyo, then it should be asia-northeast1.

I am making all objects in the created bucket public. By making all objects in the bucket public, access becomes possible, ignoring Firebase security rules. Please be careful not to add objects that you do not want to make public in the relevant bucket.

I am making all objects in the bucket public, but I also think it would be fine to only make part of the bucket public.

Just set it up according to the following document.

Please be careful to set it up so that unintended files are not made public.

Add a CNAME to DNS.

The document instructs to set c.storage.googleapis.com., but the final dot disappeared when saved.

I will upload an appropriate file from the Firebase console screen.

You can access the uploaded file via the URL.
The URL is like https://${storageBucketName}/${filePath}, and the URL of the image below is https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/FJd0PZjcffz6wGdQhyUf/origin.webp.

Let's open the image in a new tab and take a look at the Response headers. You can confirm the parameters related to the Cloudflare CDN.

After reloading a few times, it was confirmed that the cf-cache-status:HIT indicates that it is being delivered from the CDN cache.

The URL to access will look like http://localhost:9199/storage-noh-production.noh.ink/${path}. In practice, I don't think you will connect from the development environment to the production environment, so I believe the part storage-noh-production.noh.ink will be storage-noh-development.noh.ink.