If the Publish or Update button shows "Your Cloud Balance is insufficient to publish" or "Your Cloud Balance is insufficient to update," your Cloud wallet has run out.

To fix this:

1. Go to Settings > Cloud & AI to check your current balance.

2. Select Top up now and add funds to your Cloud wallet.

3. Return to the Publish panel and try again.

Note: Your Cloud wallet is separate from your subscription credits. The Cloud wallet funds hosting and deployment services, while subscription credits are used for AI agent conversations.

1. Check the storage-usage view and identify the largest chats, projects, and files.
2. Download or back up anything you may need later.
3. Delete only unneeded items. If chat deletion offers to remove associated disk data, select that option only after confirming the data is safe to discard.
4. Refresh the page and confirm that available storage has increased.
5. Return to Publish and retry once.

Deletion may be permanent and can break a project that references a removed file. If usage does not fall, contact Support with the storage view, plan, project link, and time of the failed publish.

Wait for the security scan to finish, then review every flagged item before publishing.

1. Select Resolve All and inspect the affected behavior. Fix issues involving exposed secrets, authentication, permissions, user data, or unsafe external access before production use.
2. If a secret may have been exposed, remove it from the project and rotate it through the relevant provider before publishing.
3. Run the scan again and verify the affected flow.
4. Use Publish Anyway only when an accountable reviewer understands and accepts the remaining, non-critical risk. Record the reason and avoid bypassing an unresolved risk on a production site.

If you cannot determine the impact of a finding, do not publish it. Contact Support or your security owner with the finding text and sanitized evidence.

1. Test the platform production URL and the custom domain separately. Also compare the root page with the specific page or API path that fails.
2. Record the exact status code, full URL, time and timezone, and whether the failure is constant or intermittent.
3. Check the latest deployment status and whether a recent dependency, environment-variable, database, or external-service change matches the start of the failure.
4. Capture relevant Console and Network errors.

If the failure continues, contact Support with reproduction steps, the affected version, and sanitized diagnostics. Before sending a HAR, command output, or screenshot, remove cookies, Authorization headers, tokens, secret query parameters, personal data, and payment information.

If your deployment times out or the live site is temporarily unavailable:

1. Check whether both the platform Prod subdomain and Preview are inaccessible, or only one of them.

2. Keep the current error page visible — do not repeatedly click Publish.

3. Check whether you recently modified dependencies, startup entry points, or database connections, as these changes can affect deployment.

If the issue persists, contact Support and include:

- Project link and live URL

- Failure time and your timezone

- Version number and error page screenshot

- Whether Preview is working normally

- Whether you recently modified dependencies, startup entry, or database connection

If the Publish panel shows "latest" with the button grayed out, or is stuck on "Building":

1. Do not repeatedly click Publish — this will not speed things up and may create duplicate build tasks.

2. Wait a few minutes and refresh the page.

3. If the status does not change after refreshing, contact Support.

Include the following when contacting Support:

- Chat link

- Full screenshot of the Publish panel (including page URL, version number, and button status)

- Time of occurrence and your timezone

- Currently displayed version number

- At which step it started showing "Building" or the button became grayed out

1. Check whether the image is missing in App Viewer, on the published site, or in both places.
2. Select Reload App Viewer once. If the issue is only on the live site, confirm that the latest version has been published or updated.
3. Tell the Agent the page, the image that should appear, and where the image originally came from. Ask it to check that the current project still uses the correct image name and location.
4. If the original image was removed or renamed, upload or select the intended image again, then retest the page.
5. If the image uses App Storage or another connected service, confirm that the intended service is connected and that the file still exists there.

If the image still does not load, contact Atoms Support with the Chat Link, the affected page URL, the image name or source, and a screenshot. Do not include private access links, passwords, keys, or tokens.

If the exported self-host package downloads successfully but fails to run:

1. Check the README included in the export package for environment requirements and setup steps.

2. Verify your runtime environment matches the requirements (OS version, Docker version, Node.js version).

3. Run the startup command and review the complete output for error messages.

If the issue persists, contact Support and include:

- Export version and download time

- Running OS and Docker version

- Full command executed and complete output

- Failed script or API path

- Expected deployment method

Important: Attach a sanitized configuration example, but do NOT include passwords, secrets, or tokens.

App Viewer and the published site show different stages of your project. Saving a visual change does not update the live site by itself.

1. In Design, select Save and wait for the current Agent task or build to finish.
2. Open Publish. Publishing uses the latest project version; there is no version selector in the Publish panel.
3. Select Publish for the first release or Update for a later release. Wait until the panel shows Up to date.
4. Open the live site in a new tab and reload it once.
5. If the default Atoms address shows the change but a custom domain does not, check the domain connection instead of publishing the same version repeatedly.

If the live site still shows the wrong version, contact Atoms Support with the Chat Link, the live URL, the version you intended to publish, the time and time zone, and screenshots of App Viewer and the live site.

1. Contain immediate risk. If the release exposes sensitive data or creates unsafe behavior, open App Status and use Pause for an eligible Atoms Cloud app or Unpublish to remove public access. If there is no active risk, avoid causing an unnecessary outage.
2. Record the affected domain, publication time, current version, intended version, and business impact.
3. After the current agent task stops, open Versions, choose the last known good version, and select Restore this version.
4. Verify the restored version in Preview, including critical login, payment, and data flows, then Publish or Update it.

Restoring a project version may not reverse production database changes or external actions. Do not overwrite or delete production data to imitate a rollback. Contact Support immediately when data, credentials, payments, or destructive changes are involved.

1. Stop or wait for the current agent task; a version cannot be restored while conflicting work is active.
2. Open Versions, locate the last known good version, and select Restore this version.
3. Review the restored project in Preview and test the critical flows that changed.
4. Publish or Update only after the Preview result is correct.

A project-version restore does not necessarily roll back production database records, schema changes, environment variables, payments, emails, or other external actions. If the release changed production data or the target version is unavailable, stop and contact Support with both version numbers, the affected domain, and the required data-preservation outcome.

Pause and Unpublish are two different actions:

Pause (Atoms Cloud projects only):

- The app becomes unavailable to visitors.

- Server resources remain allocated and billing continues.

- You can resume the app at any time from App Status.

Unpublish (all projects):

- The website goes completely offline. Anyone using the published URL loses access.

- For Atoms Cloud projects, server resources are released.

- You can publish the project again later, but visitors cannot access it until you do.

Use Pause for a temporary takedown with quick restart. Use Unpublish to fully remove the site.

If your browser shows "too many redirects" or the page keeps reloading without displaying content:

1. Try the platform's default Prod subdomain (not your custom domain) to determine whether the redirect loop is caused by domain configuration or the application itself.
2. If the default Prod subdomain works, check your custom domain's DNS settings and your domain registrar for redirect rules that may conflict with the platform.
3. Clear your browser cache or test in an Incognito window to rule out cached redirects.

If the issue persists, contact Support and include:

- Full URL showing the redirect loop

- Whether the default Prod subdomain is accessible

- Domain name and DNS provider

- Full error screenshot

If your app works in Preview but fails in production due to missing or empty environment variables:

1. Check whether the environment variable was saved before or after the last publish. If saved after, you need to publish again for the change to take effect.
2. Verify the variable is set for the correct environment (Development vs. Production).
3. Check whether the downstream service error message gives a clue — for example, "unauthorized" often means an API key is empty or incorrect in that environment.

If the issue persists, contact Support and include:

- Project link or live URL

- The affected key name and which environment has the problem

- The full error from the downstream service

- A sanitized screenshot of the configuration page

- Whether the config was saved before or after publishing

Important: Only provide key names. Do NOT send secret values, passwords, or tokens.

Findings can use similar wording while pointing to different locations. Similar wording does not necessarily mean that the results are duplicates.

1. Compare the finding name and the location shown for each result.
2. Review every unique location instead of dismissing the repeated wording.
3. If several findings have the same underlying cause, fix that cause and then check each location again.
4. Run the security scan again on the updated version.

If the same finding and location still appear more than once, contact Atoms Support with the Chat Link, scan time and time zone, number of findings, and a redacted screenshot. Remove any passwords, keys, tokens, or other sensitive information that may appear in a finding.

A completed scan with no reported findings is a useful check, but it cannot guarantee that every security or runtime problem has been found. The scan checks the selected project version; your app still needs to be tested in the way real users will use it.

Before publishing, test the important journeys in your app, including sign-in, user roles, access to private data, payments, and connected services. Use separate test accounts for different roles and confirm that each account can access only the information and actions intended for it.

If you discover a production issue that could expose accounts, private data, payments, or credentials, stop using or restrict access to the affected feature first. Rotate any credential that may have been exposed, then contact Atoms Support with the Chat Link, affected version, steps to reproduce the problem, time and time zone, and a redacted screenshot. Do not share the exposed credential itself.

If the scan reports that an admin-only action may be unprotected, treat the finding as unresolved until you confirm that unauthorized users cannot use it. Hiding an admin button is not enough if the action can still be requested another way.

1. Open the finding and identify the action or location it names.
2. Decide which signed-in roles should be allowed to use that action.
3. Ask the Agent to check the user’s permission when the action is requested, not only when the button is displayed.
4. Test the action while signed out, with a normal test account, and with an authorized admin test account.
5. Confirm that rejected attempts reveal no private data and make no changes, then run the security scan again.

Do not publish the affected feature if an unauthorized account can still use the action. Contact Atoms Support with the Chat Link, finding text, affected version, and a redacted screenshot if you cannot resolve it.

HTTPS protects information while it travels between a user and a service. If the scan reports an HTTPS problem, use the exact finding to identify the affected address, resource, callback, or domain configuration.

1. Open the finding and note the exact location and address it reports.
2. Ask the Agent to replace that specific connection with the secure address supported by its provider, or to correct the related domain configuration.
3. Do not ignore certificate warnings or change an address blindly if the external service does not document a secure equivalent.
4. Retest the affected user journey and confirm that no password, token, payment detail, or private information is sent over an insecure connection.
5. Run the security scan again on the updated version.

If the finding concerns a custom domain or certificate that you cannot correct, contact Atoms Support with the Chat Link, affected URL, finding text, time and time zone, and a redacted screenshot.

Row Level Security, or RLS, is a Supabase feature that controls which database rows each user can read or change. This finding is relevant only when the project uses Supabase and the scan identifies a table whose access rules need review.

1. Open the finding and identify the table it names.
2. Write down who should be able to view, add, edit, or delete that table’s data.
3. Ask the Agent to create the least-permissive Supabase policies that support those user journeys.
4. Test while signed out and with a separate test account for each role. Confirm that each account can access only the intended rows and actions.
5. Run the security scan again after the policies are applied.

Do not disable RLS or allow every user simply to clear the warning. Before making a change that could affect existing data, confirm the plan and keep a safe backup or export where appropriate. Never share Supabase keys or database credentials in Chat or screenshots.