Help CenterUse this guide after the interface and primary workflow have been reviewed. Connect only the services the application needs and verify what data each service will receive.
Before you begin
- Decide whether the product needs persistent data, authentication, server functions, or file storage.
- Create the supported backend project in the account your team controls.
- Prepare non-production test data.
- Confirm who can approve publication and who owns rollback.
Steps
1. Open Database
Choose Database in the project toolbar. The current workspace presents supported paths including Supabase and Neon, along with areas for tables, authentication, server functions, secrets, user management, and file storage.
2. Connect the required service
Choose the supported provider and add the connection value in the field provided. Use a project created for this application. Do not reuse production credentials from an unrelated system.
3. Keep secrets out of messages and source
Store private configuration in the supported secrets or environment controls. Never include a password, private key, database password, or unrestricted token in a prompt, screenshot, public repository, or client-side file.
4. Test with non-production data
Verify sign-in, record creation, updates, file handling, errors, and permission boundaries in Preview. Confirm that one user cannot read or change another user's information unless the product explicitly requires it.
5. Review the delivery state
Before publishing, check the final preview, page titles, navigation, mobile behavior, forms, error states, and any public data. Confirm that analytics, consent, and privacy notices match the data actually collected.
6. Publish deliberately
Choose Publish only after review. Record the published address and test it in a signed-out browser. Later changes may use Update. If Unpublish is available, understand that it removes public access but does not necessarily delete project data or connected service data.
Expected result
The reviewed application is available at its published address, required backend features work with appropriate permissions, and private configuration is not exposed in the public interface or source.
Status meanings
Disconnected means no backend is available to the project. Connected means a service is configured but still needs testing. Published means a public delivery is available. Unpublished means public access is removed; connected data can still remain with its provider.
Usage credit impact
Publishing itself has no fixed charge documented here. Model revisions, builds, and connected services can have separate usage or provider costs. Review the notices in Aivah and the connected account.
Information stored or shared
Publishing can make the interface publicly reachable. A connected backend can store account, form, file, and application data according to its configuration. Review both Aivah Code and the connected provider before collecting personal or confidential information.
Limits and permanent actions
Provider choices and delivery controls can vary by project. Deleting provider data, rotating credentials, or removing a production project can be permanent. Unpublishing does not guarantee deletion of connected data.
Common problems and recovery
- The backend will not connect: confirm the provider, connection value, project status, and network restrictions.
- The preview works but the published app fails: check production configuration and published environment values.
- A secret appears in source or chat: rotate it immediately, remove the exposed value, and check access logs.
- A published change causes a regression: stop further changes, capture the failing workflow, and use the team's rollback or unpublish process.
Next step
Monitor the live product and keep its dependencies, permissions, and privacy information current.