Switching from Cloudinary, Filestack, Mux, or Uploadcare

Kevin van Zonneveld

Co-founder · Amsterdam, The Netherlands · Show bio

Bring uploads, image resizing, video encoding, and document previews into one versioned pipeline, with files in storage you control. Our migration guides show how to map Cloudinary, Filestack, Mux, and Uploadcare workflows to Transloadit, bring your existing files along, and switch traffic gradually.

Each guide maps upload and processing workflows, provides example Templates, explains how to import existing sources, and gives a cutover checklist.

• Migrate from Cloudinary: upload presets, fixed and eager transformations, asset inventory, and replacing delivery references
• Migrate from Filestack: picker callbacks, MIME routing for images and PDFs, static previews, and reconciling partial exports before retrying
• Migrate from Mux: direct uploads, upfront or on-demand HLS, posters, retained originals or temporary masters, and playback-ID changes
• Migrate from Uploadcare: uploader callbacks, CDN-operation recipes, optimized image variants, and separate metadata and file-group records

Map the concepts first

On Transloadit, a Robot runs each processing Step, and the Steps together form your Assembly Instructions. You can save those instructions as a Template, and run them as an Assembly for each upload or import. Here is how the upload and processing pieces fit together:

Templates are JSON, so you can keep processing rules in version control next to your application code, as the guides recommend. Review changes alongside your application code and reuse processing rules for new uploads and backfills.

One transformation, four vendors

For the three image vendors, here is a square 400×400 WebP thumbnail in each vendor’s syntax alongside its Transloadit replacement. For Mux, compare a poster request at five seconds within a 640×360 box.

These three image operations scale the image to cover the box and crop the overflow around the center. That is what resize_strategy: "fillcrop" does in the 🤖 /image/resize Robot, and you will find that exact Step in the backfill example below. Compare appearance and quality on your own images; matching crop geometry does not reproduce automatic format, quality, or focal-point selection.

For poster frames, set offsets in seconds on the 🤖 /video/thumbs Robot. Mux's default fit mode keeps the aspect ratio inside the requested box, so pair width: 640 and height: 360 with resize_strategy: "fit". The default pad strategy would add bars instead. From a 4:3 test video, that Step gave us a 480×360 poster.

Bring your existing files along

A migration is not finished until your existing library has moved too. The guides explain how to inventory sources and import authorized URLs with the 🤖 /http/import Robot. Its url parameter also accepts an array, so you can move files in bounded batches. The Mux guide shows how to replace the input Step in its video Template; the other guides include image backfill Templates. Here is a runnable example that imports two public images and makes the thumbnail from the table above. Save it as backfill.json:

{
  "imported": {
    "robot": "/http/import",
    "url": [
      "https://demos.transloadit.com/inputs/chameleon.jpg",
      "https://demos.transloadit.com/inputs/prinsengracht.jpg"
    ]
  },
  "thumb": {
    "use": "imported",
    "robot": "/image/resize",
    "width": 400,
    "height": 400,
    "resize_strategy": "fillcrop",
    "format": "webp",
    "result": true
  }
}

Run it in your terminal with the CLI that ships with our Node.js SDK, tested here with @transloadit/node 5.1.0. When the Assembly completes, it prints a URL for each thumbnail. The abbreviated URLs below will differ on your run:

$ export TRANSLOADIT_KEY=MY_AUTH_KEY TRANSLOADIT_SECRET=MY_SECRET_KEY
$ npx -y @transloadit/node assemblies create --steps backfill.json --print-urls
STEP   NAME                URL
thumb  chameleon.webp      https://pub-….r2.dev/…/….webp
thumb  prinsengracht.webp  https://pub-….r2.dev/…/….webp

These result URLs are temporary; files are normally retained for 24 hours and are intended for short-term retrieval. In production, the guides add an export Step such as the 🤖 /s3/store Robot with your own credentials. Set notify_url in the signed Assembly request, verify notification signatures, and require ASSEMBLY_COMPLETED. Before updating your application, read results from the producing Steps and check is_temp_url: false so you persist permanent export URLs. /http/import counts 10% of imported bytes toward processing usage; resizing, metadata extraction, and any export add their own usage, per our Robot pricing.

Keep dynamic URLs with the Smart CDN

If your front-end builds transformation URLs on the fly, you do not have to move everything to upload time. The Smart CDN runs a Template on the first request for a URL and caches the result at the edge. That Template must use compatible Robots, end its response branch in /file/serve, and be called through URLs you sign on your back-end. /image/resize works there, while /video/encode and /video/adaptive do not. For video, the Mux guide points to /video/ondemand, which generates HLS as viewers request it.

The Cloudinary guide recommends generating canonical variants up front for high-traffic pages and using the Smart CDN for long-tail libraries. Our Upload once, transform forever post walks through the on-demand setup end to end.

What you get after the switch

• One pipeline for images, video, and documents. A single Assembly can import files, resize images, encode video, thumbnail documents, and export the results. The Filestack guide, for example, routes images and PDFs through one Template.
• One usage metric across media types. Plan image, video, and document processing with one GB-based metric instead of per-minute video pricing. Most processing Robots count input plus output bytes, with their own discounts and minimum charges. You can set monthly spending limits. See pricing.
• Open source uploads. Uppy, our file uploader, and tus-js-client, which its Tus plugin uses for resumable uploads, are MIT-licensed open source projects, so you can read, fork, and extend your upload front-end.
• Your storage, your regions. Export results to your own bucket, and choose processing in the United States, Europe, or Asia Pacific for data residency, or use our global endpoint. Configure your storage and delivery regions separately.

For a broader look at how these platforms differ, see our comparison of media processing platforms for startups.

Plan the application changes

The guides cover processing, uploads, storage, and notifications. Copying media bytes does not migrate metadata, groups, versions, permissions, hosted DAM catalogs, or CMS integrations. Preserve those records and rebuild the application behavior you need. For Mux, player integration, analytics, live streaming, DRM, and multilingual track packaging need separate planning; an Assembly does not recreate a Mux asset or playback ID. Test replacements for provider-specific effects and AI workflows separately, then compare real files and access rules before switching traffic.

The guide examples export to your own bucket. Transloadit Storage, our managed storage for originals and results, is in private preview. If you want to try it, ask us to enable it for your workspace. The backfill in this post uses temporary results and needs no storage configuration.

Start with one workflow

Choose your vendor from the migration index, inventory one workflow, configure its export destination, and test a handful of your own files. Keep the old asset IDs and delivery mapping available for rollback while you move traffic gradually. Sign up to get your credentials, and if you would like a second pair of eyes on your mapping, contact us.