--- title: "Introducing Storage Destinations" description: "Store generated images directly in your own S3 or S3-compatible bucket with HTML/CSS to Image." published: "2026-07-28" author: "Jeffrey Needles" canonical: "https://htmlcsstoimage.com/blog/introducing-storage-destinations" --- ## Introduction Storage Destinations let you store images generated by HTML/CSS to Image directly in an Amazon S3 or S3-compatible bucket you control. Once you've connected a bucket, you simply provide its ID as a [parameter](https://docs.htmlcsstoimage.com/parameters/storage_destination_id/) when creating an image or template. When the image renders, HCTI stores it in your bucket. By default, we'll still keep the normal HCTI copy, and you can still use our CDN. But now, you can also select **Disable HCTI Storage**. In that mode, we do not store the rendered file or make it available through our CDN. Your bucket is the only place it lives. This removes a step from a lot of integrations using a create/download/delete workflow. You no longer need to download every render from HCTI just to upload it into the system where you wanted it in the first place. The full setup is covered in the [Storage Destinations guide](https://docs.htmlcsstoimage.com/guides/advanced/storage-destinations/). ## Why & When to Use It If you already have a content pipeline, you probably have a storage bucket somewhere in the middle of it. The usual flow is pretty simple. A file lands in the bucket and triggers an event. Another service picks it up and does whatever comes next. Maybe that means creating a few additional sizes. Maybe an AI agent inspects the render, extracts useful details and stores its findings alongside the original. Maybe the image gets attached to a content record, reviewed by someone, or moved into long-term storage. Whatever happens next, you already have a process for it. Now HCTI can store the render at that same entry point. Your existing storage notifications and workers can take it from there. This also works well for public images. You might want Open Graph images, product previews or reports served from your own domain and CDN. Storing them alongside your other media lets them use the same delivery, tracking and retention rules. Some of the more interesting use cases are not public at all: - Internal employee badges or identification cards. - Certificates, reports and records attached to an internal system. - Invoices, receipts, shipping labels or account documents. - Personalized images that contain customer or operational data. - Draft creative work that should stay inside an approval workflow. For these files, a public image URL is not very useful. You probably want the render stored with the rest of the record and available only through your application. This is what **Disable HCTI Storage** is meant for. The final image is stored only in your bucket. It can stay private and be served through your application, a signed URL or whatever access layer you already use. When HCTI Storage is disabled, rendering uses the authenticated `PUT /v1/store` endpoint. Since the response is private, it can include details like the bucket, object key and storage errors without exposing them through a public image URL. > [!TIP] > `PUT /v1/store` works with any HCTI image, not just images using Storage Destinations. It renders the image, stores it in the configured location and returns a detailed storage result instead of the image itself. HCTI does not change the access settings on the object or make it public. Access is still controlled by your bucket and your application. ## How It Works The S3 API has become a standard for object storage, so this is not limited to AWS. Storage Destinations natively support Cloudflare R2, Backblaze B2, DigitalOcean Spaces, Wasabi and Google Cloud Storage. You can connect other S3-compatible services too. We just make setup easier for the listed providers. Start in your [dashboard](https://htmlcsstoimage.com/dashboard/storage-destinations). Choose a provider and enter an existing bucket. You can also add a prefix like `hcti-renders` to keep HCTI files in one part of the bucket. Test the connection, enable the destination and copy its ID. Pass that ID when you create an image, batch or template. ##### HCTI Storage Disabled {.no-link} With HCTI Storage disabled, use the authenticated `PUT /v1/store` endpoint to render the image and store it in your bucket. ##### HCTI Storage Enabled {.no-link} Requesting the normal `/v1/image/...` URL stores a copy in your bucket while returning the rendered image. Resized, cropped or reformatted versions get their own object keys, so they do not replace the original. ### Security For Amazon S3, we can do better than asking you to create another long-lived access key. We provide example trust and permissions policies for a new IAM role that you create in your AWS console or through infrastructure as code. You give us your role ARN and HCTI assumes it to store your image using temporary credentials. You can limit those permissions to a single bucket and even just to a prefix. If HCTI only needs to store new files, write access is enough. Read access is optional and only needed if you want to do later image transformations when HCTI Storage is disabled. The dashboard generates example policies so you do not need to put them together from scratch. The goal is to give HCTI the smallest amount of access it needs, limited to the exact place where renders should be stored. Other providers use access keys instead of an IAM role. Those keys should also be limited to the destination bucket and prefix whenever the provider supports it. The [Storage Destinations guide](https://docs.htmlcsstoimage.com/guides/advanced/storage-destinations/) has the complete setup for each provider, along with API examples and troubleshooting. ## Conclusion Customers use our API in all kinds of automated image workflows. For many, having us host and serve the images is part of the value. Others need more control over where those files live. Storage Destinations gives them that option. Storage Destinations put the finished image directly into your system. There is no extra transfer step to build. Private images do not need a public HCTI URL. Public images can still be served, but now you have a copy too. Storage Destinations are available on plans with 3,000 images per month or more. [Follow the guide to connect your first destination](https://docs.htmlcsstoimage.com/guides/advanced/storage-destinations/). If you have any questions, [email us](mailto:support@htmlcsstoimage.com).