S3 Compatible External Storages
If your storage provider is S3-compatible, i.e., it can be interfaced with using the S3 API and specification, you can seamlessly integrate your storage buckets with your ImageKit account. Suppose your images are originally stored on S3-compatible storage like Digital Ocean Spaces or Wasabi. In that case, you can add the bucket on which your images reside as an origin in your ImageKit configuration.
Most of the following procedure is identical to adding your own vanilla Amazon S3 bucket as an origin. All of the options and inputs remain the same, except for the endpoint input parameter. By default, the AWS SDK will try to access your specified bucket at standard, region-based S3 endpoints. However, when you are using a third party S3 compatible storage provider such as Wasabi, you need to specify the custom endpoint corresponding to your storage provider. Learn more.
For instance, here's an example endpoint for Wasabi storage:
https://s3.wasabisys.comfound on 'What are the service URLs for Wasabi's different regions?'. You can similarly find the appropriate endpoint for your S3 compatible storage provider in their documentation.
Note: We do not start copying images from your bucket as soon as you add it. Instead, we will fetch the particular image when you request it through ImageKit.io URL-endpoint. Learn more to understand how this works. The images accessed from this origin will not appear in your Media library.
Amazon S3 buckets in regions launched after 2019-03-20, such as South Africa (Cape Town), Middle East (Bahrain) and Asia Pacific (Hong Kong), must be added to ImageKit as S3 compatible external storages with the endpoint of that region, (e.g.
- 1.Go to the external storage section in your ImageKit.io dashboard, and under the Origins section, click on the "Add origin" button.
- 2.Choose S3 Compatible Storages from the origin type dropdown.
- 3.Give your origin a name, it will appear in the list of origins you have added. For example - Wasabi - Product images bucket.
- 4.Fill out the S3 bucket name.
- 5.Specify the S3 bucket folder in which your images are present. If you have to access files at the root (i.e., present directly in the bucket and not inside a folder), enter
- 6.Fill out S3 access and secret keys. These keys should provide read-only access to ImageKit.io as explained below.
- 7.Enter the custom endpoint for your storage provider as explained above.
- 9.Click on the Submit button.
Read-only permission required ImageKit.io needs read-only access to your storage bucket. You can refer to your S3-Compatible storage provider's documentation to figure out how to provide read-only access to a bucket.
When you add your first origin in the dashboard, the origin is by default made accessible through the default URL-endpoint of your ImageKit.io account. For subsequent origins, you can either create a separate URL-endpoint or edit the existing URL-endpoint (including default) and make this newly added origin accessible by editing the origin preference list.
Let's look at a few examples to fetch the images:
- The same master image using ImageKit.io URL-endpoint https://ik.imagekit.io/your_imagekit_id/rest-of-the-path.jpg
So when you request
https://ik.imagekit.io/your_imagekit_id/rest-of-the-path.jpg, ImageKit.io internally access the object at path
rest-of-the-path.jpgin your bucket.
URL-endpoint transformation image path
Now start using ImageKit.io URL endpoint in your application to accelerate image loading.
Get started with our quick start guides and SDKs:
Learn about real-time image resizing:
While fetching images from your S3 bucket with special characters in the name, you will get a
404 NOT FOUNDresponse. For example, let’s assume that there is a key
image%2Bexample.jpgin your S3 bucket, and the request is made using
image+example.jpgin the URL. In this case, ImageKit.io tries to fetch
image+example.jpgobject from the S3 bucket resulting in a 404 error as this object does not exist.
While adding the origin in your ImageKit.io account, you are now provided with an option to encode the keys while fetching the object from your S3 bucket. By default, this option is disabled. When enabled, the requests made while fetching images will be made using encoded keys.
Note: ****At present, this feature can only be enabled upon request, please email support at [email protected]
When enabled, the image response contains a Link header with the appropriate URL and rel=canonical. You will have to specify the base URL for the canonical header.
For example, if you set
https://www.example.comas the base URL for canonical header, then the image response for URL
https://ik.imagekit.io/your_imagekit_id/rest-of-the-path.jpgwill have a Link header like this:
Link: <https://www.example.com/rest-of-the-path.jpg>; rel="canonical"
When enabled, path-style URLs will be used instead of the default, virtual-hosted style URLs while fetching the image from your S3-compatible storage provider. This may be useful if your provider does not yet support the virtual-hosted style URLs i.e. URLs where the bucket name is a part of the hostname.
For example, if your service provider's endpoint is
https://s3.wasabisys.com, your bucket is named
product-images, and your file is named
red-dress.jpg, then the URL generated as per each style will be:
virtual-hosted [default]: https://product-images.s3.wasabisys.com/red-dress.jpg