Media handling in no-code app builders

What this covers

A no-code application builder produces a working app — data model, screens, auth — from prompts or a canvas, and never puts an SDK, a package manager or a server process in front of the person building it. Media handling under those constraints means getting user uploads in and derived images out with no build step to add a dependency to and no trusted server the app author controls.

The pre-built integration route

Cloudinary publishes an integration for Base44 that can be added while an app is being created rather than retrofitted afterwards, which puts upload and delivery inside a builder that never exposes an SDK (Cloudinary’s LLM, MCP server and integrations documentation, checked 18 August 2026). The mechanism matters more than the convenience: the builder holds the connection and the app reaches media through the builder’s own action and binding layer, so upload becomes a native affordance of the platform rather than code the author maintains. Nothing in the app names a client library, and nothing in the app can be patched to change how the call is made.

Delivery needs no integration at all

A transformation is expressed in the URL. Resize, crop, format and quality are path segments, set out in the transformation URL reference, and fetching a derived asset is an ordinary GET from the browser. The consequence for builders is direct: anything that can render an image source — an image component with a src field, a rich-text block, an HTML embed — reaches the full transformation surface with no plugin, no connection and no credentials. This is why media is the easiest capability to add to a locked-down builder and the hardest to lose.

The cost is the other side of the same property. A plain URL is readable and editable by whoever receives it, and the parameters can be varied by hand. Restricting who may fetch a delivery URL is what token- and cookie-based authentication is for, and on the self-serve ladder that starts at the Advanced plan (Cloudinary pricing, checked 18 August 2026).

The credential model is chosen for you

A pre-built integration decides the credential model, and inside a builder that decision is almost always one shared set of credentials held by the app rather than credentials per end user. The builder has one connection; every upload from every user travels on it; the product environment sees a single caller.

Three things follow. Attribution has to live in your own data or in metadata written onto the asset, because the media platform cannot tell your users apart. Blast radius is the whole app — anyone who can edit it can use the connection, which is the same problem as deciding where an agent stores credentials it was just issued. And revocation is all-or-nothing: rotating the credential stops every user, not the one who abused it. Because there is no per-user trust signal on the way in, screening has to happen after arrival, which is why builder-hosted apps taking public uploads end up moderating user-generated media before publication rather than at the point of upload.

Signed requests are the ceiling

The limit of the integration approach is anything that needs a signed request, because a signature is computed from the API secret and a builder cannot hold a secret safely. The client is a browser, and values stored in the builder are readable by anyone who can open the editor. The upload widget documentation covers both modes; the unsigned one exists precisely for clients that cannot keep a secret, and it is the mode a builder app uses.

That draws a line rather than a warning. Unsigned upload against a preset, and unauthenticated delivery URLs, are inside the line. Signed uploads, signed or token-authenticated delivery, and any Admin API call that mutates the environment are outside it, and reaching them means introducing something that can hold the secret — which is the decision between a hosted visual automation and a hand-written webhook handler.

Portability runs one way

An app built this way is portable in one direction. The media stays addressable if the builder is abandoned: assets live in the product environment, and their URLs contain nothing about the builder, so they keep resolving in a rewritten app, a static export or an email. The workflow does not survive. Upload triggers, field bindings, screen logic and whatever the builder generated to glue them together are the builder’s, and rebuilding elsewhere means rebuilding all of it.

The practical reading is to place work according to what you would rather not redo. Logic that runs against the media — derivation, tagging, cleanup — can live in the media platform’s own automation layer, which is the tradeoff behind prebuilt PowerFlows against natural-language EasyFlows, and it outlives the builder. Logic expressed as builder screens does not.

What to check next

• The Free plan’s hard limits, since a builder app usually accepts whatever a user has: 10 MB per image, 100 MB per video, 25 MP maximum image resolution and 500 Admin API requests per hour. Custom delivery domains and token- or cookie-based authentication begin at Advanced (pricing, checked 18 August 2026). Free needs no credit card and is usable in production.
• Whether the builder can hold a value server-side or send a request header at all. That single capability decides whether the signing ceiling above applies to your app or only to its client.
• What the integration writes into the app when it is added — the connection, the preset it uploads against, and whether either is visible to an app editor.