Publica tu proyecto

Si el botón Publish o Update muestra "Your Cloud Balance is insufficient to publish" o "Your Cloud Balance is insufficient to update", tu billetera de Cloud se ha quedado sin fondos.

Para solucionarlo:

1. Ve a Settings > Cloud & AI para revisar tu saldo actual.

2. Selecciona Top up now y agrega fondos a tu billetera de Cloud.

3. Regresa al panel de Publish e inténtalo de nuevo.

Nota: Tu billetera de Cloud es independiente de tus créditos de suscripción. La billetera de Cloud financia los servicios de hosting y despliegue, mientras que los créditos de suscripción se usan para conversaciones con agentes de IA.

1. Revisa la vista de uso de almacenamiento e identifica los chats, proyectos y archivos más grandes.
2. Descarga o haz una copia de seguridad de cualquier cosa que puedas necesitar más adelante.
3. Elimina solo los elementos innecesarios. Si al eliminar un chat se ofrece eliminar los datos de disco asociados, selecciona esa opción solo después de confirmar que los datos se pueden descartar de forma segura.
4. Actualiza la página y confirma que el almacenamiento disponible haya aumentado.
5. Regresa a Publish y vuelve a intentarlo una vez.

La eliminación puede ser permanente y puede romper un proyecto que haga referencia a un archivo eliminado. Si el uso no disminuye, contacta a Support con la vista de almacenamiento, el plan, el enlace del proyecto y la hora en que falló la publicación.

Espera a que el análisis de seguridad termine y luego revisa cada elemento marcado antes de publicar.

1. Selecciona Resolve All e inspecciona el comportamiento afectado. Corrige los problemas relacionados con secretos expuestos, autenticación, permisos, datos de usuario o acceso externo inseguro antes del uso en producción.
2. Si un secreto pudo haber quedado expuesto, elimínalo del proyecto y rótalo a través del proveedor correspondiente antes de publicar.
3. Ejecuta el análisis nuevamente y verifica el flujo afectado.
4. Usa Publish Anyway solo cuando una persona responsable entienda y acepte el riesgo restante no crítico. Registra el motivo y evita omitir un riesgo no resuelto en un sitio de producción.

Si no puedes determinar el impacto de un hallazgo, no lo publiques. Contacta a Support o a la persona responsable de seguridad con el texto del hallazgo y evidencia saneada.

1. Prueba por separado la URL de producción de la plataforma y el dominio personalizado. Compara también la página raíz con la página específica o la ruta de API que falla.
2. Registra el código de estado exacto, la URL completa, la hora y la zona horaria, y si la falla es constante o intermitente.
3. Revisa el estado del despliegue más reciente y si un cambio reciente en dependencias, variables de entorno, base de datos o servicios externos coincide con el inicio de la falla.
4. Captura los errores relevantes de Console y Network.

Si la falla continúa, contacta a Support con los pasos para reproducirla, la versión afectada y diagnósticos saneados. Antes de enviar un HAR, salida de comandos o una captura de pantalla, elimina cookies, encabezados Authorization, tokens, parámetros secretos de consulta, datos personales e información de pago.

Si tu despliegue agota el tiempo de espera o el sitio en vivo no está disponible temporalmente:

1. Verifica si tanto el subdominio Prod de la plataforma como Preview están inaccesibles, o solo uno de ellos.

2. Mantén visible la página de error actual — no hagas clic repetidamente en Publish.

3. Revisa si modificaste recientemente dependencias, puntos de entrada de inicio o conexiones a la base de datos, ya que estos cambios pueden afectar el despliegue.

Si el problema persiste, contacta a Support e incluye:

- Enlace del proyecto y URL en vivo

- Hora de la falla y tu zona horaria

- Número de versión y captura de pantalla de la página de error

- Si Preview está funcionando normalmente

- Si modificaste recientemente dependencias, punto de entrada de inicio o conexión a la base de datos

Si el panel de Publish muestra "latest" con el botón atenuado, o se queda atascado en "Building":

1. No hagas clic repetidamente en Publish — esto no acelerará el proceso y puede crear tareas de compilación duplicadas.

2. Espera unos minutos y actualiza la página.

3. Si el estado no cambia después de actualizar, contacta a Support.

Incluye lo siguiente al contactar a Support:

- Enlace del chat

- Captura de pantalla completa del panel de Publish (incluyendo la URL de la página, el número de versión y el estado del botón)

- Hora de ocurrencia y tu zona horaria

- Número de versión que se muestra actualmente

- En qué paso empezó a mostrar "Building" o el botón se atenuó

1. Verifica si la imagen falta en Visor de Apps, en el sitio publicado o en ambos lugares.
2. Selecciona Reload App Viewer una vez. Si el problema ocurre solo en el sitio en vivo, confirma que la versión más reciente se haya publicado o actualizado.
3. Dile al Agente la página, la imagen que debería aparecer y de dónde provenía originalmente la imagen. Pídele que verifique que el proyecto actual siga usando el nombre y la ubicación correctos de la imagen.
4. Si la imagen original fue eliminada o renombrada, vuelve a cargar o selecciona la imagen prevista y luego vuelve a probar la página.
5. Si la imagen usa Almacenamiento de App u otro servicio conectado, confirma que el servicio previsto esté conectado y que el archivo siga existiendo allí.

Si la imagen aún no carga, contacta a Atoms Support con el Chat Link, la URL de la página afectada, el nombre o la fuente de la imagen y una captura de pantalla. No incluyas enlaces de acceso privados, contraseñas, claves ni tokens.

Si el paquete exportado para self-host se descarga correctamente pero no se ejecuta:

1. Revisa el README incluido en el paquete de exportación para conocer los requisitos del entorno y los pasos de configuración.

2. Verifica que tu entorno de ejecución coincida con los requisitos (versión del SO, versión de Docker, versión de Node.js).

3. Ejecuta el comando de inicio y revisa la salida completa en busca de mensajes de error.

Si el problema persiste, contacta a Support e incluye:

- Versión de exportación y hora de descarga

- SO en ejecución y versión de Docker

- Comando completo ejecutado y salida completa

- Script o ruta de API que falló

- Método de despliegue esperado

Importante: Adjunta un ejemplo de configuración saneado, pero NO incluyas contraseñas, secretos ni tokens.

Visor de Apps y el sitio publicado muestran etapas diferentes de tu proyecto. Guardar un cambio visual no actualiza por sí solo el sitio en vivo.

1. En Design, selecciona Save y espera a que termine la tarea actual del Agente o la compilación.
2. Abre Publish. La publicación usa la versión más reciente del proyecto; no hay selector de versión en el panel de Publish.
3. Selecciona Publish para la primera publicación o Update para una publicación posterior. Espera hasta que el panel muestre Up to date.
4. Abre el sitio en vivo en una nueva pestaña y recárgalo una vez.
5. Si la dirección predeterminada de Atoms muestra el cambio pero un dominio personalizado no, revisa la conexión del dominio en lugar de publicar repetidamente la misma versión.

Si el sitio en vivo sigue mostrando la versión incorrecta, contacta a Atoms Support con el Chat Link, la URL en vivo, la versión que intentabas publicar, la hora y la zona horaria, y capturas de pantalla de Visor de Apps y del sitio en vivo.

1. Contén el riesgo inmediato. Si la publicación expone datos sensibles o genera un comportamiento inseguro, abre App Status y usa Pause para una app de Nube de Atoms elegible o Unpublish para quitar el acceso público. Si no hay un riesgo activo, evita causar una interrupción innecesaria.
2. Registra el dominio afectado, la hora de publicación, la versión actual, la versión prevista y el impacto en el negocio.
3. Después de que se detenga la tarea actual del agente, abre Versions, elige la última versión conocida como buena y selecciona Restore this version.
4. Verifica la versión restaurada en Preview, incluidos los flujos críticos de inicio de sesión, pago y datos, y luego publícala o actualízala.

Restaurar una versión del proyecto puede no revertir cambios en la base de datos de producción ni acciones externas. No sobrescribas ni elimines datos de producción para imitar una reversión. Contacta a Support de inmediato cuando haya datos, credenciales, pagos o cambios destructivos involucrados.

1. Detén o espera a que termine la tarea actual del agente; no se puede restaurar una versión mientras haya trabajo conflictivo activo.
2. Abre Versions, localiza la última versión conocida como buena y selecciona Restore this version.
3. Revisa el proyecto restaurado en Preview y prueba los flujos críticos que cambiaron.
4. Publica o actualiza solo después de que el resultado en Preview sea correcto.

Restaurar una versión del proyecto no necesariamente revierte registros de la base de datos de producción, cambios de esquema, variables de entorno, pagos, correos electrónicos u otras acciones externas. Si la publicación cambió datos de producción o la versión objetivo no está disponible, detente y contacta a Support con ambos números de versión, el dominio afectado y el resultado requerido de preservación de datos.

Pause y Unpublish son dos acciones diferentes:

Pause (solo proyectos de Nube de Atoms):

- La app deja de estar disponible para los visitantes.

- Los recursos del servidor permanecen asignados y la facturación continúa.

- Puedes reanudar la app en cualquier momento desde App Status.

Unpublish (todos los proyectos):

- El sitio web queda completamente fuera de línea. Cualquiera que use la URL publicada pierde el acceso.

- En los proyectos de Nube de Atoms, se liberan los recursos del servidor.

- Puedes volver a publicar el proyecto más adelante, pero los visitantes no podrán acceder hasta que lo hagas.

Usa Pause para una retirada temporal con reinicio rápido. Usa Unpublish para eliminar completamente el sitio.

Si tu navegador muestra "too many redirects" o la página sigue recargándose sin mostrar contenido:

1. Prueba el subdominio Prod predeterminado de la plataforma (no tu dominio personalizado) para determinar si el bucle de redirección es causado por la configuración del dominio o por la aplicación misma.
2. Si el subdominio Prod predeterminado funciona, revisa la configuración DNS de tu dominio personalizado y las reglas de redirección de tu registrador de dominios que puedan entrar en conflicto con la plataforma.
3. Borra la caché del navegador o prueba en una ventana de incógnito para descartar redirecciones almacenadas en caché.

Si el problema persiste, contacta a Support e incluye:

- URL completa que muestra el bucle de redirección

- Si el subdominio Prod predeterminado es accesible

- Nombre del dominio y proveedor de DNS

- Captura de pantalla completa del error

Si tu app funciona en Preview pero falla en producción debido a variables de entorno faltantes o vacías:

1. Verifica si la variable de entorno se guardó antes o después de la última publicación. Si se guardó después, debes publicar nuevamente para que el cambio surta efecto.
2. Verifica que la variable esté configurada para el entorno correcto (Development vs. Production).
3. Revisa si el mensaje de error del servicio dependiente da alguna pista; por ejemplo, "unauthorized" a menudo significa que una clave de API está vacía o es incorrecta en ese entorno.

Si el problema persiste, contacta a Support e incluye:

- Enlace del proyecto o URL en vivo

- El nombre de la clave afectada y en qué entorno ocurre el problema

- El error completo del servicio dependiente

- Una captura de pantalla saneada de la página de configuración

- Si la configuración se guardó antes o después de publicar

Importante: Proporciona solo los nombres de las claves. NO envíes valores secretos, contraseñas ni tokens.

Los hallazgos pueden usar una redacción similar mientras apuntan a ubicaciones diferentes. Una redacción similar no significa necesariamente que los resultados estén duplicados.

1. Compara el nombre del hallazgo y la ubicación mostrada para cada resultado.
2. Revisa cada ubicación única en lugar de descartar la redacción repetida.
3. Si varios hallazgos tienen la misma causa subyacente, corrige esa causa y luego revisa cada ubicación nuevamente.
4. Ejecuta otra vez el análisis de seguridad en la versión actualizada.

Si el mismo hallazgo y ubicación siguen apareciendo más de una vez, contacta a Atoms Support con el Chat Link, la hora del análisis y la zona horaria, la cantidad de hallazgos y una captura de pantalla censurada. Elimina cualquier contraseña, clave, token u otra información sensible que pueda aparecer en un hallazgo.

Un análisis completado sin hallazgos reportados es una verificación útil, pero no puede garantizar que se hayan encontrado todos los problemas de seguridad o de ejecución. El análisis revisa la versión seleccionada del proyecto; tu app aún debe probarse de la forma en que los usuarios reales la usarán.

Antes de publicar, prueba los recorridos importantes de tu app, incluidos inicio de sesión, roles de usuario, acceso a datos privados, pagos y servicios conectados. Usa cuentas de prueba separadas para diferentes roles y confirma que cada cuenta pueda acceder solo a la información y acciones previstas para ella.

Si descubres un problema en producción que pueda exponer cuentas, datos privados, pagos o credenciales, primero deja de usar o restringe el acceso a la función afectada. Rota cualquier credencial que pueda haber quedado expuesta y luego contacta a Atoms Support con el Chat Link, la versión afectada, los pasos para reproducir el problema, la hora y la zona horaria, y una captura de pantalla censurada. No compartas la credencial expuesta en sí.

Si el análisis informa que una acción solo para administradores puede no estar protegida, trata el hallazgo como no resuelto hasta que confirmes que los usuarios no autorizados no pueden usarla. Ocultar un botón de administrador no es suficiente si la acción aún puede solicitarse de otra manera.

1. Abre el hallazgo e identifica la acción o ubicación que menciona.
2. Decide qué roles con sesión iniciada deberían poder usar esa acción.
3. Pídele al Agente que verifique el permiso del usuario cuando se solicite la acción, no solo cuando se muestre el botón.
4. Prueba la acción con la sesión cerrada, con una cuenta de prueba normal y con una cuenta de prueba de administrador autorizada.
5. Confirma que los intentos rechazados no revelen datos privados ni realicen cambios, y luego ejecuta nuevamente el análisis de seguridad.

No publiques la función afectada si una cuenta no autorizada aún puede usar la acción. Contacta a Atoms Support con el Chat Link, el texto del hallazgo, la versión afectada y una captura de pantalla censurada si no puedes resolverlo.

HTTPS protege la información mientras viaja entre un usuario y un servicio. Si el análisis informa un problema de HTTPS, usa el hallazgo exacto para identificar la dirección, recurso, callback o configuración de dominio afectada.

1. Abre el hallazgo y toma nota de la ubicación y la dirección exactas que informa.
2. Pídele al Agente que reemplace esa conexión específica por la dirección segura compatible con su proveedor, o que corrija la configuración de dominio relacionada.
3. No ignores las advertencias de certificados ni cambies una dirección a ciegas si el servicio externo no documenta un equivalente seguro.
4. Vuelve a probar el recorrido de usuario afectado y confirma que no se envíen contraseñas, tokens, detalles de pago ni información privada a través de una conexión insegura.
5. Ejecuta nuevamente el análisis de seguridad en la versión actualizada.

Si el hallazgo se refiere a un dominio personalizado o certificado que no puedes corregir, contacta a Atoms Support con el Chat Link, la URL afectada, el texto del hallazgo, la hora y la zona horaria, y una captura de pantalla censurada.

Row Level Security, o RLS, es una función de Conectar Supabase que controla qué filas de la base de datos puede leer o cambiar cada usuario. Este hallazgo es relevante solo cuando el proyecto usa Conectar Supabase y el análisis identifica una tabla cuyas reglas de acceso necesitan revisión.

1. Abre el hallazgo e identifica la tabla que menciona.
2. Anota quién debería poder ver, agregar, editar o eliminar los datos de esa tabla.
3. Pídele al Agente que cree las políticas de Conectar Supabase menos permisivas que admitan esos recorridos de usuario.
4. Prueba con la sesión cerrada y con una cuenta de prueba separada para cada rol. Confirma que cada cuenta pueda acceder solo a las filas y acciones previstas.
5. Ejecuta nuevamente el análisis de seguridad después de aplicar las políticas.

No desactives RLS ni permitas el acceso a todos los usuarios solo para eliminar la advertencia. Antes de hacer un cambio que pueda afectar datos existentes, confirma el plan y conserva una copia de seguridad o exportación segura cuando corresponda. Nunca compartas claves de Conectar Supabase ni credenciales de base de datos en Chat o en capturas de pantalla.