Bolt can turn one person's idea into a working application with remarkable speed. Production begins when that application can survive something less glamorous: another person trying to operate it.

To take a Bolt app into production, you need more than a live URL and a GitHub repository. You need clear ownership of the Bolt project, source code, database, secrets, domain, billing and deployment process. Then somebody other than the original builder must prove that those arrangements work.

This is not an argument for moving everything out of Bolt. Bolt Cloud can provide hosting, databases, authentication, file storage and domain management in one workspace. That convenience can be entirely sensible. It does, however, mean that a founder may have assembled several production systems while feeling as though they created one project. The software industry has long enjoyed putting six cupboards behind one very attractive door.

Production starts with an ownership map

Begin by recording what the app actually uses. Do not start with the technology you remember choosing. Inspect the live project and its connected accounts.

Bolt distinguishes between the project, where code and development work live, and the site, which is the hosted version people visit. Updates to a project do not automatically appear on the published site; somebody must publish them. Bolt also treats its GitHub, Supabase, Stripe and hosting connections as separate integrations with their own permissions and accounts.

Your ownership map should look something like this:

This exercise exposes the difference between access and ownership. Being invited to edit a Bolt project does not necessarily let somebody administer its database connections, publish the site or manage the GitHub integration. A shared password is not a shortcut around this problem. It is merely an audit trail wearing a false moustache.

Put the Bolt project in the right operational home

For a continuing team, a team workspace is usually easier to govern than a project left in a founder's personal workspace. Bolt provides both team-level roles and project-level roles, and they do different jobs.

At team level, an Admin can manage members, project controls, security settings, integrations, analytics and billing. At project level, Viewers can inspect, Editors can change code and view environment variables, and Co-owners can also invite outside collaborators, publish and manage the site. The Co-owner role is available only to members of the team.

Use named accounts and give people only the access their work requires. Keep at least two authorised people for critical administration, particularly where one absence could prevent a release or incident response. Check team defaults too: Bolt lets team admins control the default project role, deployment provider, published-site visibility and whether GitHub, Stripe and Supabase integrations are allowed.

If the app must move, use Bolt's actual transfer process rather than duplicating it and hoping for administrative reincarnation. According to Bolt's project transfer documentation:

• A transfer to another workspace you belong to keeps the Bolt database and connected GitHub or Supabase integrations.
• A transfer to another user keeps the Bolt database connected, but it cannot transfer the Supabase account itself.
• A transfer to another user removes the GitHub integration when the recipient accepts. The new owner can connect their own GitHub account and create a new repository.
• Custom domains do not transfer and must be removed first. Bolt advises against transferring a project using a domain purchased through Bolt because it cannot be reconnected until it expires.

These are not small-print curiosities. They determine the order of the handover. If a Supabase project is involved, Bolt recommends transferring that project to its new owner before transferring the Bolt project. If GitHub history matters, decide separately who will own the existing repository and preserve its history. GitHub sync moves code changes; it does not transfer the database, credentials, hosting account, domain or the duty to answer the phone when deployment goes sideways.

Choose database ownership without sacrificing the data

A Bolt app can continue using Bolt Database in production. Claiming it in Supabase is an option when the operating team needs external management tools, SQL editing or more advanced monitoring. It is not a ceremonial step required to make the app respectable.

The dangerous move is to treat Connect and Claim as synonyms. Bolt's Supabase guidance says that claiming migrates the existing Bolt database, while connecting a Supabase database replaces the connection. Claiming requires a Pro or Teams plan and Supabase organisation-owner permission. Bolt also notes that its Version History does not restore a Supabase database, so the recovery plan must be reviewed when the data moves.

Before either change, identify the authoritative database, take an appropriate backup, document authentication and file storage dependencies, rehearse the change away from live users, and define the rollback point. A database decision made through a button still deserves a database migration plan.

Give source control a company address

Connecting GitHub is valuable. Bolt can maintain a history outside the platform, work across branches and pull updates made elsewhere. For a production team, the repository should normally sit under an organisation the business controls, with named maintainers, protected access and a documented branch-and-review process.

There is a Bolt-specific wrinkle. Only the Bolt project owner can connect and manage the GitHub integration. Changes made by collaborators sync when the owner next opens the project. Bolt also does not merge branches in the app; merging happens in GitHub. The team therefore needs to decide who owns that connection, who reviews changes and which event actually authorises a production publish.

Keep credentials out of the repository. Bolt's database secrets are designed for server functions to use API keys or passwords without exposing them in a user's browser. Access to those secrets is limited to the project owner on an individual account, or the project owner, Co-owners and team Admins on a team account. Bolt recommends rotating keys, removing unused keys and never storing secrets as plain text in code.

For every integration, record whose vendor account owns it, whose payment method funds it, where its secret is stored and how it is rotated. The variable name STRIPE_SECRET_KEY is documentation only in the same sense that a label saying “keys” explains who owns the building.

A worked example: handing over a booking app

Consider a fictional founder, Maya, who has built DeskDay in Bolt. Customers book desks, receive confirmation emails and pay through Stripe. The app uses Bolt hosting, Bolt Database, Bolt authentication and file storage. Its custom domain is registered outside Bolt. The source is synced to Maya's personal GitHub repository, while the email and Stripe accounts are also hers.

The app works. The company, however, cannot yet operate it without Maya.

The handover team creates a company Bolt workspace and gives two employees the necessary team and project roles. It transfers the project into that workspace, moves the repository into the company's GitHub organisation, and confirms the Bolt integration against the intended repository. The registrar, Stripe and email service are placed under company-controlled accounts with named administrators and company billing. Each production secret is recreated or rotated, rather than copied into a document entitled “important passwords final”.

They keep Bolt Database because the current operating needs do not justify a Supabase claim. The ownership map states that explicitly, names the people who can manage advanced database settings and records how backups and restoration will be handled. They also record that publishing remains on Bolt Cloud and identify the two Co-owners authorised to manage the published site.

Run the handover acceptance exercise

A handover document proves that somebody can write a handover document. The more useful test is to give an authorised operator who did not build the app a small, reversible task.

1. Enter through their own accounts. The operator signs into Bolt, GitHub, the domain provider and relevant service dashboards without using Maya's session or password.
2. Trace one customer journey. They create a test user, book a desk, confirm the database record, check the payment or test-mode event and verify the email result.
3. Make a controlled change. On a branch, they alter the wording of the booking confirmation, have another team member review it and merge it in GitHub.
4. Publish deliberately. They confirm which version will go live, publish it using the agreed account and verify the change on the production domain.
5. Diagnose a harmless failure. They submit an invalid promotional code in a test journey, confirm the user sees a sensible response and locate the relevant application or database log.
6. Prove the way back. In a non-live copy or agreed test window, they demonstrate the documented recovery route to the previous known-good application version and confirm how data recovery differs from code recovery.
7. Remove the founder-shaped support beam. After the team has passed the exercise, rotate personal credentials, reduce obsolete access and repeat the critical checks.

Record the result, including any step that needed undocumented knowledge. A failed step is useful evidence: it has found a production dependency before a staff departure, holiday or incident found it with rather less tact.

Production is an operating condition

Bolt makes it easy to publish an application, and keeping Bolt Cloud may be the right production choice. The serious question is not whether the platform can display the site. It is whether the organisation can govern the accounts, change the code, protect the data, publish a known version and recover when something fails.

That is also why this guide differs from a general AI prototype-to-production checklist or a debate about whether a platform is “production-ready”. The unit of readiness here is the operating team. A product owned by one browser session is not a company asset so much as an elaborate hostage negotiation waiting for annual leave.

If your Bolt-built product works but its code, database, integrations and deployment still orbit one founder's accounts, Venturist can review the full product and run a practical handover assessment. The aim is a launch-ready application your team can operate, not merely admire while the original builder is online.