This method is suitable if you already use file storage like Amazon S3, Azure Blob Storage, Google Cloud Storage, Web Servers, etc., and want to use ImageKit.io for real-time optimization and URL-based transformation capabilities for your image and video files or the delivery of any other file.
How does it work?
You can connect your external storage with ImageKit.io. ImageKit.io acts as a proxy between the CDN and your storage. This means that when a request is made to ImageKit.io for any file, ImageKit.io fetches the file from your storage, processes it in real-time, and serves the optimized media file to the user over the CDN. Let's dive deeper into how this process works.
On a high level, this is how the request flow looks like:
Your media files remain securely stored in your storage system. ImageKit.io accesses these files in real-time upon receiving user requests. However, if you encounter slow response times from your origin server, you can see how to debug the same, as explained here.
Supported external storage
ImageKit works with a variety of external storage types. You can connect any of the following types of external storage with ImageKit.io:
- Object storage - ImageKit.io supports all popular S3-compatible storages like Amazon S3, Wasabi, Alibaba OSS, Digital Ocean Spaces, Azure Blob Storage, and Google Cloud Storage, etc. See generic instructions for S3-compatible storages.
- Web-server - You can also connect any web server like Nginx, ELB, ALB, EC2, Magento, WordPress, etc., to ImageKit.io. Firebase Storage also falls under this category.
- Web proxy - ImageKit.io can access files from any web URL using the web proxy external storage type.
- Akeneo PIM - If you are using Akeneo PIM, you can connect it with ImageKit.io using the Akeneo PIM integration to fetch product media, asset media, and reference entity media files.
- Cloudinary backup bucket—If you are migrating from Cloudinary, you can connect your Cloudinary backup bucket with ImageKit.io using the Cloudinary backup bucket integration. Check out the Cloudinary migration guide for more information related to no-code change migration.
URL Endpoints
URL endpoints are unique access points that allow you to retrieve your media files through ImageKit.io. When you create an account, a default URL endpoint is automatically generated:
Default URL endpoint: https://ik.imagekit.io/your_imagekit_id
Creating a new URL endpoint
You can create multiple URL endpoints to segregate media files based on categories like product images, user profile images, etc. To create a new URL endpoint:
Go to the URL Endpoints section in your ImageKit.io dashboard and click on the "Add new" button.
Fill in the
Identifierfield. It will become part of the URL endpoint. Suppose you want to create a URL endpoint just to access the product images bucket, and you want it to be like this:https://ik.imagekit.io/your_imagekit_id/product-images/
Then enter product-images in this field. 3. Attach the external storage (origin) to this URL endpoint. You can attach multiple origins to a single URL endpoint.
Origin preference
When you attach multiple origins to a single URL endpoint, you can set the order in which ImageKit.io will attempt to fetch the resource from these origins.
- ImageKit always tries to fetch the file from the integrated Media Library first. If the file is not found, it tries to fetch it from the attached external storage (origins) sequentially, one after the other till it finds the file on that path.
- Avoid adding more than two origins to a single URL endpoint for optimal performance.
- You have the option to configure a custom domain name and optionally associate it with only a specific URL endpoint. Contact support@imagekit.io for domain and URL endpoint mapping.
Troubleshooting 404 errors
When ImageKit encounters an error while fetching the original image from your external origin, it responds with a 404 status code and a generic "Not Found" message. You can check the ik-error header in the response to debug the issue.
| Error Code | Description |
|---|---|
| ENOENT | It means the file does not exist at the given path on the origin server or object storage. Check the origin server associated with the URL endpoint and ensure that the file exists. |
| EACCES | Invalid or expired authentication credentials for the corresponding origin. In this case, you should check the credentials provided in the ImageKit dashboard while configuring the origin and ensure that ImageKit.io has the necessary permission to access the file. In the case of web server origin, you should check firewall settings and whitelist our servers. In the case of object storage, you should ensure that the configured credential has read access. |
| ELIMIT | Refer to transformation limits to understand more about the reason for the error. The response status is 400 in this case. |
| ECONNREFUSED | The external origin refused to connect. This usually happens if your origin web server has some maximum connection limit or a firewall has blocked our request. You should check firewall settings and whitelist our servers. |
| UNIDENTIFIED | The exact nature of the error could not be identified. This is rare, in this case, contact us at support@imagekit.io. |
Whitelist requests from ImageKit.io
Suppose your origin server uses any Web Application Firewall (WAF) or any other setting that could prevent ImageKit's servers from accessing your origin. In that case, we recommend that you allow our requests to your origin based on the request header value. All our requests to your origin will have a header x-req-from with its value set to imagekit.
If header-based rules cannot be added, you should allow requests from the following IP addresses.
Note that these IP addresses may change in the future. Any changes will be reflected and updated in this document.
3.0.152.204 3.105.141.56 3.105.153.182 3.105.56.110 3.106.43.145 3.120.113.108 3.124.164.235 3.125.145.160 3.125.232.112 3.126.54.34 3.228.64.190 3.25.15.199 3.6.106.236 3.6.117.197 3.6.117.226 3.6.125.142 3.6.139.207 3.6.31.234 3.6.77.26 13.211.250.60 13.234.210.223 13.235.117.100 13.239.68.153 13.239.93.60 13.250.152.216 13.251.231.118 13.54.10.227 13.57.157.178 13.57.80.35 13.57.84.219 15.206.35.88 18.136.180.238 18.138.42.101 18.138.48.167 18.140.193.132 18.144.94.93 18.184.51.46 18.194.51.214 18.214.253.69 34.198.33.10 34.227.255.75 35.156.190.52 52.1.78.96 52.220.21.200 52.221.19.26 52.23.130.57 52.29.99.236 52.52.150.88 52.52.156.33 52.53.89.205 52.63.6.226 52.76.146.253 52.86.168.184 52.9.51.127 52.9.54.118 54.183.110.13 54.198.229.74 54.93.187.13 100.25.189.19 100.26.0.170 18.138.154.61 52.66.188.11 3.123.46.194 3.226.115.3 13.52.20.231 3.24.91.28 159.65.154.196 206.189.46.125 174.138.126.207 142.93.174.223 34.228.164.220 18.156.150.128 3.123.211.55 3.126.236.57 3.126.25.38 3.66.248.204 3.74.172.234 3.76.53.155 3.77.243.243 3.77.50.194 54.151.133.111 52.74.122.107 18.138.154.61 3.1.207.90 52.77.198.19 18.136.88.63 18.138.189.41 13.215.97.100 13.228.210.47 13.228.217.227 13.250.195.31 13.251.132.82 18.138.97.218 3.1.46.98 52.220.37.193 52.76.110.156 54.169.79.116 100.24.177.67 18.214.141.92 50.17.57.46 52.45.208.226 54.145.114.168 54.237.174.138 43.204.172.86 3.108.149.71 65.1.72.129 43.205.66.219 13.234.247.83 15.206.97.20 13.233.234.115 13.234.159.248 52.52.35.45 52.53.66.106 52.8.243.221 52.8.34.3 52.9.239.52 54.176.154.89 54.176.68.12
Staging vs production setup
There are two ways to handle the staging vs production setup with external storage:
- Use different external storage & URL Endpoints - Create separate external storage for staging and production. You can then create separate URL endpoints for staging and production and associate the respective storage with them. This way, you can keep the media delivery separate for staging and production.
- Using sub-account - In the above setup, the Media Library and other account settings will still be shared between the two environments. If that is not desired, or if you want separate analytics for both the environments, you can use a separate sub-account for different environments. This setup lets you confidently iterate on configurations and share credentials with your team without affecting the production setup. Sub-accounts are available only on enterprise plans.
Serving media from your local machine
If you want to access media files from your local host, you can use ngrok to create a secure tunnel to your local machine. You can then use the ngrok URL as the origin URL in ImageKit.io. For example, if your local server is running on http://localhost:3000, you can create a tunnel using ngrok http 3000 and use the ngrok URL like https://xxxxxxxx.ngrok.io as the origin URL in ImageKit.io.
Debugging slow origin response
ImageKit returns a standard Server-Timing header in the response that provides detailed information about the time it took to process the request. You can use these headers to identify the bottleneck in the request processing.
Server-Timing: transformation;dur=193,download;dur=35,cdn-rid;desc="emLLQhxPrnjER3V6q7vg3a0uB2PeL8WfjQGrDML6SCRXCn1_a5vGGw==",cdn-downstream-fbl;dur=470
- download - Time taken in milliseconds by ImageKit to download the original file from the origin.
- transformation - Time taken in milliseconds by ImageKit to apply transformations.
If your download time is high, then try the following steps:
- Check that your origin is working correctly and can respond to ImageKit requests quickly
- Check your processing region and the geographical location of your origin. The longer the physical distance between the two, the longer the download time. ImageKit.io has six processing regions: North California (United States), North Virginia (United States), Frankfurt (Europe), Mumbai (India), Singapore (Singapore), and Sydney (Australia). To change your processing region, you can speak to our support team. Additional one-time charges may apply for this change based on your traffic volume.
- Try using the feature to save a copy of the original asset in ImageKit
Save a copy of original assets on demand
This feature is available only on enterprise plans. When enabled, apart from the transformed file, ImageKit.io also caches the original file on its servers while processing the first request to a resource. Subsequent transformations for the same resource are generated from the copy stored in ImageKit instead of downloading the original resource again from the origin server.
This feature not only helps reduce the processing time by significantly reducing the time it takes to access the original file but also helps reduce data transfer costs, if applicable, when ImageKit downloads the content from your origin server.