Your team is already building apps with AI. Give them somewhere safe to run.
People across the company make tools with Lovable, Bolt, Cursor and Claude Code, then put them wherever they can: public by default, keys in the browser, nobody in IT aware. deployshed runs them behind your company's sign-in and checks them before they ship.
In invite-only beta. Beta teams start with credit.
$ git push origin main → Found a Vite app, building with Node 20 ✗ VITE_SUPABASE_KEY holds a Supabase service_role key, which bypasses every row-level security rule. A frontend build would publish it to every visitor. → Use the project's anon key here, and keep the service_role key server-side
The problem
Generated apps work, which is why their mistakes go unnoticed
An app made in an afternoon looks finished. What usually is not: who can open it, what its browser code gives away, and whether its database answers anyone who asks.
Public by default
The quickest way to share a generated app is a public address. Anyone who finds it can open the company's data with it.
Keys in the browser
Generators put a database key or an OpenAI key in a VITE_ variable because that makes the browser code work. The build writes it into a file every visitor downloads.
Tables anyone can read
A Supabase app is safe only when every table has row-level security rules. Generated projects often have none, and nothing about the app looks wrong.
What deployshed does
Push the repository. The rest is checked for you.
Lovable and Bolt export to GitHub. Connect that repository, or any GitHub, GitLab, Bitbucket or public one, and every push deploys.
Only your company can open it
Every app sits behind your organization's sign-in: Google, a password with two-factor, or your own identity provider on Enterprise. Narrow it to named people, or give an outsider a guest link for up to 90 days.
Secret keys stay out of the bundle
A VITE_, NEXT_PUBLIC_ or REACT_APP_ variable holding a Supabase service_role key, an OpenAI, Anthropic, Stripe or AWS key, or a database password is refused when it is saved and again when the app builds.
Open Supabase tables, found
After each build, every table in the app's Supabase project is asked for one row with its public key, exactly what a visitor could do. A table that answers is reported, and one holding emails, phone numbers or passwords is marked high.
Scanned before it ships
Leaked secrets, risky code and vulnerable packages are checked on every build. Choose whether a high or critical finding only warns or stops the deploy.
Every app in one list
The app inventory shows each app, who created it, who can open it, its last deploy and its latest findings, with filters for anything reachable from outside. Export it as a spreadsheet for a review.
A record of who changed what
Every change people make through the dashboard or the API is in the audit log: who, what and when. On Enterprise, export it as CSV or JSON Lines.
How it works
From a generated repository to a team-only address
Connect the repository
Point deployshed at the GitHub repository Lovable or Bolt exported, or the one your assistant wrote. No Dockerfile needed: Vite, React, Next.js, Python and the rest are built as they are.
Add its settings
Put the Supabase address and public key in the app's variables. Anything that must stay secret is refused under a public prefix, with the reason.
Share it with the team
The app gets an address only your organization can open. Each push redeploys it, and each build is scanned and checked again.
Questions
Before you ask
Does it work with Lovable and Bolt projects as they are?
Yes. Both export a Vite app to GitHub. deployshed builds it without a Dockerfile, passes its VITE_ variables to the build, and serves it so that links deep into the app work.
Does the Supabase check change or read our data?
It writes nothing and keeps no values. It asks each table for one row with the public key the app already ships, notes whether a row came back and what its columns are called, and discards the rest. It only ever contacts your project's own supabase.co address.
Will a finding stop a deploy?
Only if you choose so. By default findings are shown on the app's Security page and in the inventory. An owner can set the organization to block deploys with high or critical findings.
Who pays, and how?
The organization adds credit and pays for what its apps use, hour by hour. There is no charge per person who opens an app. See pricing.
How do we join?
deployshed is in invite-only beta. Request an invite with what your team would deploy, and you will get an invite code that starts your organization with credit.