Security and data retention
Last updated 11 September 2026
Retention Periods
| The file you upload | Deleted with the last job that used it, on that job’s window plus the day’s grace described below — so on a one-day plan the master goes about two days after the work is delivered, and up to six hours later than that if the sweep has just run, rather than a month later. Where one video was submitted for several languages or several shapes, the master and the extra cuts go once every job that references them has expired. Thirty days from upload is the outer limit the bucket enforces on its own, and it is the backstop rather than the normal answer. A video, a static creative — the rule does not distinguish between them. Music is not on that list because Music takes no upload: it is described in words. |
| A typeface you add | A font is a tool in your library rather than a submission, so it is not on the rule above. It stays for as long as your plan keeps files, counted from the last render that actually used it: every use restarts the countdown, so a face you work with stays and one you tried once goes a window after you uploaded it. Delete it yourself and the same window runs from the deletion. When the file goes the entry stays — the name, the family, the measured scale and your confirmation that you had the right to use it — because a video rendered last month names that typeface and has to stay explainable. From that moment the font stops being offered, and a re-render that would have needed it is refused rather than quietly delivered in the wrong face and charged for. Where we cannot establish when a font was last used, we keep it. |
| Finished work | Localized videos, redrawn creatives, generated tracks and their cover art, and the clips and stills Generate makes with the poster frame drawn from a clip, all under your workspace’s own window — your plan’s number unless we have agreed a different one with you, which is 1 day on the free tier, 3 on Starter, 7 on Pro, 14 on Growth and 30 on Scale. The five numbers are the ladder, not the rule: the window this product enforces is the one on your workspace, and where we have agreed a different one it is that number the sweep and every download door use — the data processing addendum puts it in writing. Underneath all of them sits the storage service’s own flat 30-day rule on delivered files, which cannot read a job record, so a window agreed above 30 days is ended by that rule first and 30 days is the outer bound on this page. You are told how long is left before it passes, in the app, and the date itself is on the job’s own record. This is the same rule for every product, and on the shortest windows that is worth saying out loud: a campaign of two hundred localized images stops being available the day after it is delivered on the free tier, and three days after on Starter, exactly as a video would be. Download them. The window is when access stops, not when the bytes go. The sweep that deletes them runs a day behind it, so an object lives one day longer than the number above — that extra day is ours, not yours: every download, comparison, poster and re-render is refused on the window itself. There is one window and no result is exempt from it. This table carried a row here until 8 September 2026 describing a control that took a result off the window; the control is gone and so is the exemption. Nothing you can press, and nothing marked on a single result, changes the schedule above. Download anything you want to keep — that is the whole of what a customer does about retention now, and it is why the sentence is on this page rather than left to be discovered. |
| Working files | Everything a job produced on the way to the deliverable is kept beside the deliverable and deleted with it, at your plan’s window above: transcripts and subtitle files for a video, the wording read off a creative and its translations for a static job, the generated lyric sheet a track is delivered with. A track’s title is part of its job record and is kept for as long as that is. Working files used to expire separately after three days, which is why a re-render of an older video could fail to find its own subtitles. Extracted audio is never kept in our storage — it exists only inside the machine doing the work and goes when that finishes. It is sent to OpenAI to be transcribed, and their abuse-monitoring logs hold it for up to 30 days; we have not asked for the zero-retention option that endpoint offers. The wording read off a creative is refused when you ask for it once its window closes, not just swept. The copy sheet delivered with a campaign is on the same clock as the images: opening it, editing a line on a delivered creative or redrawing from it afterwards is refused, and the refusal names the window and the day it ended. On a one-day plan that means a campaign delivered on Friday has no readable copy on Saturday, and the creative is submitted again from your master — one rule for text and pixels alike, which is the point. |
| The job record and the credit ledger | The job record goes when its output does, on the same window as the file itself — the sweep that removes the bytes removes the row with them. Pressing Delete on a job takes it off your list straight away and the same sweep removes the record afterwards. The ledger is what stays: one line per charge, kept as our books of account, and if you erase your account it stays with your identifiers stripped out of it. It holds no video, audio or images, and it is what lets us show what you were charged. What that means for you: the parameters you chose and the words you typed — the prompt, the style note, any lyrics — live on the job record, so they go when it does. Download what you want to keep before the window closes; re-running a track or a still months later means submitting it again rather than regenerating it from a record we no longer hold. |
| Proof that you accepted these documents | While your account exists. One row per document: which document, its version, the hash of the words you were shown, when you accepted them, a shortened form of your IP address and your browser’s identification string. Erasing the account removes the row, and copies three of those fields into our own record of the erasure first — which document, its version and the front of the hash — where they stay, with nothing that names you. The time, the shortened address and the browser string are not copied. |
| Server logs | Kept 14 days: the IP address, the URL and the time of each request, for security and for debugging. That figure is read off the machines rather than applied by any code of ours — log rotation on the server that answers requests keeps fourteen daily files of the request log, a reading whose date we have not recorded, and the render workers’ log group was measured at fourteen days on 1 September 2026 — so it describes the deployment as it stands, and a change to either machine could move it without any code of ours changing. One thing is outside that number and is worth saying rather than rounding in: the application’s own log lines on the server that answers requests go to the system journal, which is trimmed by size rather than on a clock, so nothing puts fourteen days on those. |
| Database backups | The last 30 copies, counted rather than aged: our own job drops one when a newer one has been written, never because it reached an age. The table list is derived from the migrations rather than hand-picked — accounts, job records, the ledger, your glossary, your saved subtitle styles, your acceptances of these documents and the waiting list — and never your files. The prompts you save in Generate are on it too, and were not until 19 September 2026: a rollback line in that table’s own migration read to the scanner as a drop, so nothing saved there reached any copy. The scanner stopped reading comments as instructions and the table has been copied since. So a deleted row survives in one for about a month while the daily copy is running, and for longer whenever it is not — up to ninety days, which is the rule the storage service applies to the backups themselves. |
Three mechanisms, and it is worth knowing which is which. The 30-day outer limit is a rule on the bucket itself: it applies whether or not any of our code is running, and nothing we could break would extend it. Your plan’s shorter window is enforced by a sweep that runs every six hours, because the storage layer cannot know which plan an account is on. Typefaces have a third: a daily sweep of their own, on your plan’s window counted from the last render that used them, because no rule on the bucket covers them at all.
Deletion runs one day behind the date you are shown, and that is on purpose. Access ends exactly on the window: the moment it passes, every download, preview and comparison is refused. The bytes are removed by the next sweep after that, plus a day’s grace — so that a sweep running late can never delete something the app still says you can fetch. The 30-day rule on the bucket is the backstop under the file you upload and everything a job produces. Two things sit outside it: typefaces, which no rule on the bucket covers at all, so the daily sweep above is the only thing that removes them and it keeps any face whose last use it cannot establish; and the one case in the clause below.
We write to you two days before finished work stops being available, to the address that owns the account and at most once a day: how many files reach the end of their window, and how long is left to download them. On a one-day window there is no such email and there cannot be — two days’ warning would arrive before the work did — so there the delivery notice does that job, and it says in its own words how long the file stays. Both carry an unsubscribe link, and using it changes what you are told, never what is deleted or when.
When We Must Retain Something
One case outlives every rule above, the daily sweep over typefaces included, and it is the second of the two exceptions to the 30-day rule named there. Where we learn that material we hold sexually exploits a child, that material is copied somewhere no deletion sweep walks and no storage rule reaches. It survives your plan’s window, the rule on the bucket, the account being closed and you deleting the job yourself, and it stays there until a person removes it by hand — because United States law requires us to preserve it for at least ninety days after we report it. That figure is a duty on us rather than a window our code applies: nothing sweeps that copy, and closing the incident releases the account without touching it. Until the incident is closed — while it is open, and while it is with the authorities we reported it to — an erasure of the whole account is refused. That is said again below, because it is the one place on this page where deleting your data is not the answer. The acceptable use policy sets out what triggers that and what we do next. Nothing else on this page is preserved by it.
Access to Your Files
What you upload, and every typeface you add, is stored under a prefix belonging to your account; what a job produces is stored under a prefix carrying that job’s own id. Either way, every request that names an object is checked against the account making it. Download links are generated on request and expire; there is no public URL for any customer file.
Files are encrypted in transit and at rest by the storage service. Access from our side is limited to the credentials the pipeline runs under. Those credentials can read and write the whole media bucket rather than one customer’s prefix — the same process has to sweep every account’s expired files — and what is narrowed is deletion, which reaches only the working prefixes and can never touch the spend ledger or preserved material.
Incident Response
If we learn of a breach affecting your data, we tell you without undue delay, and within 72 hours of learning of it where the data processing addendum applies. The notice says what happened and when, which categories of data are involved and roughly how many people and records, what it is likely to mean, what we have done or propose to do, and a person to reply to. Where the picture is incomplete we send what we have and follow up rather than hold the first notice back until it is tidy. That is the same commitment the privacy policy and clause 9 of the addendum make, in the same number of hours, because two deadlines to the same reader would be worse than either.
Found a problem here. Write to info@cralio.app with what you found and enough for us to reproduce it. Two things we ask while you look: do not test against anybody else’s account or data, and do not run load against the live service to make a point — neither is needed to show us something real. The acceptable use policy prohibits probing our infrastructure and circumventing a rate limit outright and writes no research exception into either, so the second of those is already a rule rather than a request. Testing against somebody else’s account is the one that is asked here and written nowhere.
How We and Our Providers Process Your Files
Your files are used to produce your outputs, and for nothing else except the preservation hold described above and anything you have specifically agreed to. What a provider may do with what it receives is a separate question, answered in the paragraph below. We do not use them as examples, demos or marketing material without asking you first. That covers what you type as well as what you upload: a music prompt, a style note and lyrics you wrote are your material on the same terms as a video.
Cralio has no models and trains nothing. The models belong to the providers who do the work, and each of them decides what it may do with what it receives. The subprocessors page carries that answer per provider, in its own column, under the date a person last read those companies’ terms — and where a row was added after that date, in that row’s own note, because moving the one date for one new row would claim we had re-opened all of them. Including where the answer is that they may use it to improve their own models. We do not negotiate that away on your behalf and we will not pretend to.
It covers an email address left on the waiting list too, and there the promise is smaller and easier to check: we write to you once, when the product opens, and that is the only thing the address is for.
What We Have Not Done
There is no SOC 2 report, no ISO certification and no third-party penetration test yet. If your procurement process needs one, say so and we will tell you honestly where we are rather than pointing at a badge.
Deleting Sooner
You can delete a job and its files from the dashboard as soon as that job is not running, which removes them ahead of the retention window — finished, failed, rejected, or still waiting its turn; a job that is actually running has to be stopped first. Deleting takes it off your dashboard at once and destroys everything under it: the renders, the poster, the subtitle files and the job’s own log. The file you uploaded goes with it once nothing else still needs it — one upload feeds every language job of the same submission, so the master is removed when the last of them is deleted and not when the first one is. A job that had not started yet gives its credits back at the same time.
If the storage service refuses one of those deletes we do not call it done and move on. The failure is written on the job, a sweep retries it every hour, and a delete still failing days later raises an alert to us — a deletion we reported and did not perform is the one failure you could never see for yourself.
To have an entire account and everything in it erased, send a DELETE request to /account, confirmed by typing the address on the account — or ask us, and we will run the same thing. That erasure is code rather than a hand process: it removes your jobs, your uploads and outputs, your fonts, glossary terms and settings, strips your identifiers out of the credit ledger. Since 19 September 2026 it also removes the prompts you saved in Generate — those rows hang on the workspace rather than on you, and the erasure, which empties the workspace instead of deleting it, used to leave them behind. Four things make it answer not yet by policy, and the refusal names which: a subscription still running, which you cancel in Billing first so that nothing charges you afterwards; jobs still running, which you wait for or stop from the dashboard; other people still in your workspace, whom you remove from the Team page first, because erasing you would take their work with it; and a safety incident on the account that is still live — open, or reported and not yet closed — where all we say is that the account is under review. Two more answers are not policy at all, and you get them rather than a half-finished erasure: if we cannot confirm the address on the account we refuse rather than delete half of one, and if something on our side will not answer — the incident table, the list of your jobs — nothing is deleted, you are told so in those words, and it is finished by hand rather than left half done. There is no button for it in the dashboard yet. See the privacy policy for what that covers and what we have to keep for accounting.
The subprocessors that receive your files are listed on their own page.