Files and storage

That depends on where the file is going.

Anywhere the work gets looked at (a review round, a card on a canvas, a shot version) only takes what a browser can put on a screen: jpg, png, webp, avif, gif, mp4, mov, webm, glb, gltf, usdz and pdf. A transfer to a client, and a project's file dock, both take anything at all, including EXR sequences, TIFFs, MKV, FBX, OBJ, Alembic caches, installers, fonts, and a .zip of a whole render sequence.

A review item or a card on a canvas is kept as your studio's record of what was agreed, and nothing on it is ever a blendfile or a texture pack in the first place. A transfer carries an end date and clears itself out afterwards, so a heavy master belongs there whether or not a browser could ever have opened it. A project's dock is the studio's own working copy of exactly that kind of file, the rig and the texture pack a job runs on, so it opens the same door a transfer does rather than the one review and canvas use. When a screen turns a file away, it says so the moment you drop it, and points you at the delivery door instead.

Two formats Kadrenta will not open: camera raw files, and true 16-bit images. In practice that means TIFFs; a 16-bit PNG is not something a filename can give away, so there is no check for that. Both still travel fine through a transfer.

A .mov can hold H.264, which every browser plays straight away, or ProRes, which none of them do. The file name never says which. The first time somebody opens a video the browser cannot decode, Kadrenta makes a viewing copy (through Cloudflare Stream) and the screen says it is on its way. It appears by itself a minute or two later. The same happens for .mkv, and for any .mp4 whose header turns out to hold a codec the browser cannot play.

Your original file is never touched by this. A download always hands back exactly what you uploaded, whatever plays in the browser in the meantime. The viewing copy also tops out at 1080p. If a client needs to inspect a 4K frame, they need to download the master.

If Cloudflare cannot make a viewing copy at all, the screen says so and explains why: too long for the account's limit, a file it could not read, a clip too short to bother with. In every one of those cases the file itself is untouched, and colleagues with the right software can still open it.

A picture large enough to be worth it gets a small thumbnail, made by the very browser that uploaded it. That is also why a thumbnail never appears for a format no browser can decode, like an EXR or a TIFF. Those fall back to a generic icon rather than a broken preview.

A video gets a poster frame the same way, taken a tenth of the way into the clip rather than frame one, because a render's first frame is very often black. If your own browser could not draw the frame (an unusual codec, ProRes before it has a viewing copy), the next colleague who opens that video may draw it instead, automatically, the next time they watch it.

Every project has its own Project files panel: a small file explorer with folders, for the work files that are not shots or review rounds. Source scenes, references, a client's brief. It is a Pro-plan feature. Anything already there when a studio falls back to the free plan stays and keeps counting, but new files need Pro again. A project lead can turn the panel on or off, and can hide it from individual team members. Everyone with it turned on can add files and make folders, up to ten levels deep.

Files there show who added them. A file that arrives on its own, dropped in by a render job rather than by a person, shows no name, because nobody pressed anything.

Removing a file from the dock, or deleting a folder that still holds something, is not instant. It goes into the studio's trash for five days first (see below), and only then is the space freed.

A free studio's room is counted two ways at once: at most 150 light files (images, PDFs, audio) and 20 heavy files (video, 3D). A screen shows you both counts as you approach them. There is also a byte ceiling behind those counts, set just above what 150 light and 20 heavy files could weigh at their own per-file limits. It is not shown as a number; the visible counts are what you run into first.

A paying studio's room is pooled across every seat: 250 GiB per seat (500 GiB on a Pro seat), and any one person on the team can use all of it. There is no per-person quota, so the one desk doing the rendering is never the one that runs out. Per file, a paid studio may put up to 4 GB inside a project, whatever kind of file it is. A transfer to a client has no practical per-file ceiling of its own; the studio's remaining room is the only thing that can still say no.

If a free studio stays over its room for a long stretch after being told about it repeatedly, the oldest files that are pushing it over the ceiling are cleared automatically. Never the ones you are still looking at first, and never more than is needed to get back under the line. The Storage tab (under Admin) shows where a studio's space is going: how much sits in projects, on canvases, in transfers, and in the file dock, project by project, so you can see at a glance where to clean up first.

Nothing in Kadrenta ever deletes a file directly. What you delete is a card, a shot version, a review round, or a file in a project's dock, and the file behind it becomes unreachable as a consequence. For five days after that, it sits in the studio's trash, visible on the Storage tab to studio admins, with a Put back button and a day count on each row. After five days the bytes are destroyed and nothing brings them back.

No delete dialog mentions the trash; it is only visible on the Storage tab, and only to studio admins. Putting something back is a favour you ask an admin for, not a button sitting next to the one that threw it away.

One thing the trash does not cover: a transfer that has run out. Nothing was deleted there; its date passed. The way to get those files back in front of a client is to open the transfer and give it more time, not to look in the trash.

A download link is signed and expires on its own: half an hour for a signed-in colleague, and a short window for someone on a share link, refreshed automatically as long as the tab stays open, and behind a passphrase if the link has one. If playback on a long-open tab ever seems to stall, that expiry is almost always why. Kadrenta asks for a fresh link on its own, and the file itself is never the problem.