Log in Sign up free

AUTOPILOT

We check what you accidentally published

Most leaked credentials are not published on purpose. They arrive in a ZIP of a whole project folder, or in a page an AI wrote, and nothing tells the person who shipped it. Droply looks through every version as it goes live and tells you in plain language what a visitor can read.

Publish a site and see How it works

Runs on every deploy, on every plan. Nothing to switch on.

  1. Publish as normal

    Drop a ZIP, a folder or a single file, or edit a site in the browser. There is nothing to turn on and no separate scan to run.

  2. Autopilot reads the version that went live

    It goes through the files a visitor can actually download, looking for credential files that came along for the ride and for keys written into the page itself. It never blocks a publish and never delays your site going live.

  3. You are told what is readable

    Anything worth your attention opens a note the moment the deploy finishes, before you send the link to anyone. Every version keeps its own report on the site page, in plain language, with what to do about each finding.

What it looks for

  • Credential files that came along with the upload

    A .env is the most common one. Zip a project folder and it is usually in there, holding every key and password the app uses, and it is downloadable by anyone who guesses the filename. The same goes for .npmrc, .netrc, a .htpasswd and a wp-config.php.

  • A .git folder, which is worse than it looks

    Publishing .git publishes your entire commit history. Anyone can reconstruct the source, including anything you committed once and deleted later. Removing a key in a later commit does not remove it from the history, which is why this one is worth catching before anybody looks.

  • Private keys and database passwords

    SSH and TLS private keys, .pem and .p12 files, and connection strings with the password still in them. A private key is the one file that is never meant to leave your machine.

  • Provider keys written into your pages

    Stripe secret keys, AWS access keys, GitHub tokens, OpenAI and Anthropic keys, SendGrid and npm tokens. Keys published in a public file get found by scrapers within minutes, and the usage is billed to you.

  • Passwords checked in the browser

    A login compared against a password sitting in the same JavaScript file is not a login. Anyone can read it in view-source. This is the one that turns up most often in pages built with AI, and the person who wrote it usually believes it works.

  • Leftovers that give away more than you meant

    Source maps, database dumps, editor backup files, .DS_Store. None of these is a leaked credential, so they are reported quietly, as tidying rather than as an alarm.

Why this keeps happening to AI built sites

A generated project is code you did not write and have not read. It arrives complete, it works, and somewhere in it is a configuration file you never opened. When the way to publish is to zip the folder and upload it, that file goes with everything else.

The most expensive version of this is a service key. Several popular backends hand you two keys that look almost identical: one is designed to sit in your front-end where visitors can see it, and one bypasses every access rule you set up. Pasting the second one into a page is a single character of difference to read and total access to the database if you get it wrong.

Nothing about a working site tells you this happened. The page loads, the deploy is green, and the key is sitting in a file anyone can open. That gap between "it works" and "it is safe to share" is the whole reason this check exists.

What this does not do

  • It is not a URL scanner. It reads files you publish here. There is no box to paste someone else's address into.
  • It is not a guarantee that a site is secure. It reports what it can see in your files, and a clean result means those checks found nothing, not that nothing is wrong.
  • It does not store, manage or rotate your credentials, and it never keeps the value of anything it finds. A finding records the file, the line and a masked snippet.
  • It does not change your files or block a deploy. Your site goes live either way and the decision stays yours.
  • It does not run your code, and it does not check a server, because there is no server: every site here is static files.

Frequently asked questions

Does the security check cost anything?
No. Every site is checked on every deploy, on every plan including the free one, and you are always told what was found and what to do about it. Showing the exact file and line is part of Free and above.
Can I check a site that is not hosted here?
Not today. The check reads the files of a site you publish on Droply, so there is nothing to point at an address somewhere else. If you want a site checked, publishing it here is what runs the check.
Will it stop my site from going live?
Never. The check runs after your site is already published and is purely advisory. It exists to tell you something, not to decide for you.
Does it flag the keys that are supposed to be public?
No, and that is deliberate. Publishable keys, such as a Supabase anon key, a Stripe publishable key or the API key in a Firebase web config, belong in your front-end and are not reported as leaks. A checker that cried wolf on those would teach you to ignore the one finding that matters.
What should I do if it finds something?
Two things, in this order. Remove the file or the key from your project and publish again, so it stops being downloadable. Then rotate that credential with whoever issued it, because anything that has been public should be treated as known, whether or not anyone fetched it.
Do you keep the keys you find?
No. The value is masked at the moment it is found and is never stored, never logged and never sent anywhere. A finding keeps the file name, the line number and a snippet with the value blanked out, which is enough to go and fix it.
Does it check sites edited in the browser too?
Yes. Uploads, folders, pasted HTML, templates, pages built with AI and edits made in the built-in file editor all go through the same check, because they all end in the same thing: a version of your site going live.
AI website builder Pricing