Uploading source code to a service you found through a search engine deserves scepticism. The file you are sending is, by definition, the part of your application somebody thought was worth protecting. Here is what happens to it here, stated precisely enough that you can hold us to it.
Where files actually sit
Uploads and decoded results are written to private storage outside the web root. Nothing under that directory is reachable by URL — every download goes through the application, which checks that the file belongs to the account asking for it.
That detail matters more than it sounds. A decoded .php file placed anywhere a web server will serve it is not merely a leak: it is executable code sitting on a public URL. Keeping artifacts outside the document root is the single most important thing a service like this gets right or wrong.
How long they stay
Every file carries an expiry from the moment it finishes. You choose the retention period — 1, 3, 7, 14 or 30 days — and a scheduled job removes anything past it, together with the bytes on disk.
Delete on download
If you would rather nothing lingers, switch on delete-on-download. The file and its decoded result are removed the instant you fetch them; download once and there is nothing left to leak. It remains subject to the retention period as a backstop, so a file you never collect does not sit here for ever either.
The encoded original
Once a decode succeeds, the file you uploaded has done its job and is deleted immediately — only the result you came for is kept. Failed jobs are the exception: those keep their payload for a limited window so the failure can be investigated, then the bytes go and only the record remains.
Archives are not an extra copy
Downloading a folder as a ZIP builds the archive on private storage, streams it to you, and deletes it as it finishes sending. A derived artifact should not outlive its download, and an hourly sweep clears anything left behind by an interrupted transfer.
Note that downloading an archive deliberately does not trigger delete-on-download. That setting means one file; applying it to a ZIP of five hundred would erase them all from a single click, with no way back.
Who can see your code
Administrators can download a customer's file when investigating a failure, and every such download is recorded — who, which file, whose account, when. The log never contains file contents. We would rather have an audit trail with our own name in it than an unlogged capability.
What we never do
- Keep a searchable index of your source. An index outlives the file it describes, which would quietly break every retention promise above.
- Log file contents, or the text of anything you search for.
- Send your code to third parties beyond the decoding engine required to process it.
Practical advice, whoever you use
- Strip credentials first. Config files with live database passwords and API keys should not be uploaded anywhere; decode the class, not the secrets.
- Rotate anything that was embedded in code you have handed over, here or elsewhere.
- Test with one file, and check the retention settings before sending the rest.
You can review your own retention settings any time from the auto-delete control on your dashboard.