Skip to content
SSShipSafeStack

Ship guide

Ship a Bolt app

Bolt can keep hosting, a database, and auth inside Bolt Cloud, or the project may be a Vite app pointed at Supabase or another API. Identify which one you generated. The checks below are useless against the wrong architecture.

Updated 16 Oct 2026 · Directory entry

A checklist for this builder, not a promise the app is production-safe. Confirm every setting in the project you actually generated.

  1. 01

    Name the stack in one sentence

    Write down where the frontend is hosted, where the rows live, and where auth happens. Bolt Cloud is one answer. A downloaded project on Vercel plus Supabase is another. If you cannot write the sentence, you are not ready to share the URL.

  2. 02

    Treat Vite env vars as public

    Anything prefixed for the client bundle is visible in devtools. Search the built assets, not only the source. The API key checklist is the procedure. Rotate anything secret you find, then remove it.

  3. 03

    Test access with two accounts

    Create a second user and request the first user's data with the same client the app uses. If you are on Supabase, use the RLS checklist. If you are on Bolt Cloud's database, use whatever rules screen it gives you and do not stop at “the happy path works.”

  4. 04

    Check payments and email

    A pay button that only flips a React state is not a payment system. Use a server confirmation. Stripe users should follow the webhook checklist. Keep the email API key on the server.

  5. 05

    Limit the expensive routes

    If the app calls a model or sends mail, add a rate limit on the server. Bolt will not have done this just because the UI disables a button while a request is in flight.

  6. 06

    Scan and watch

    Run a scanner on the URL you will publish, then add error monitoring. Close with the pre-launch checklist.