Skip to main content
Openinary speaks the same URL language as Cloudinary. Moving over mostly means copying your files and changing the start of your URLs:

Before you start

Openinary covers resizing, cropping, formats, quality and video trimming. It does not have effects (e_), overlays (l_), AI features, adaptive streaming or webhooks yet. If you rely on one of these, read the full comparison first.

Migrate in five steps

1

Create your Openinary account

Sign up for Openinary Cloud and create an API key under Settings → API keys. You can also self-host.The Free plan includes 1 GB of storage. If your Cloudinary library is bigger, switch to the Alpha plan first. See plans.
2

Copy your files

Our migration script copies every file from Cloudinary to Openinary and keeps the same paths. Find your Cloudinary API key and secret in the Cloudinary console settings, then run:
Add --dry-run to see what would be copied without uploading anything. If the script stops, run it again: it picks up where it left off.When it finishes, keep cloudinary-migration.jsonl. It lists every file with its old and new URL.
3

Send new uploads to Openinary

Replace your Cloudinary upload call with a request to POST /upload:
Uploading from the browser, like with the Upload Widget? Use the File Uploader for Next.js or React.Then run the migration script once more, to copy anything uploaded to Cloudinary in the meantime.
4

Update your URLs

Replace the start of your Cloudinary URLs with your Openinary one, and remove the version (v1712345678). Your bucket ID is in the to column of the migration log.Most transformations stay exactly the same. A few need a change, see transformations that change below.
Remove any transformation Openinary doesn’t support. A single unknown parameter, like e_blur in w_400,e_blur:300, makes the whole URL return 404.
URLs saved in a database? Use the conversion function below.
5

Test, then switch

Open your main pages on a preview deployment and check that images and videos load. A 404 in the network tab almost always means an unsupported parameter is left in a URL.Then deploy. Each image size is generated once, on its first visit, so the first loads are a little slower.Keep your Cloudinary account for 30 days, so old links in emails and caches keep working.

Transformations that change

Everything else you likely use, w, h, c, g, f, q, ar, a, r, b, so, eo, works as is. See the transformation reference.

More help

You don’t need an SDK. A small helper builds your URLs:
Note that Openinary paths include the file extension.
Use Next.js’s own <Image> with this loader:
openinary-loader.js
next.config.js
Each width Next.js asks for is a new transformation. Trim images.deviceSizes to the widths you really use.
Run each saved Cloudinary URL through this function. It changes the prefix, drops the version and keeps only the parameters Openinary supports.
to-openinary.js
If a URL has no file extension, find the right path in the migration log.
The script copies four files at a time. For hundreds of thousands of files, run several copies in parallel, one per folder, each with its own log:
Self-hosting? Raise MAX_FILE_SIZE_MB above your largest file first. The default is 50 MB.
  • Private and authenticated files
  • Tags and metadata
  • File types Openinary doesn’t accept, like SVG, PDF or TIFF. They are listed as unsupported in the log.
  • Upload presets, named transformations and webhooks. Recreate what you need by hand.
Stuck? Ask in the discussions, we read every migration question.