Técnico

Primero abre la página de estado de la build: cada etapa tiene un botón Logs que muestra exactamente dónde falló. La mayoría de fallos caen en tres categorías: un fallo transitorio de infraestructura (haz clic en Retry), un error de código que la IA puede arreglar (inicia un chat con "falló la build, el error es: …" y pega la línea relevante) o un problema con un servicio conectado (Stripe, GitHub, tu proveedor de dominio). Si nada de eso encaja, escribe a soporte con el ID del proyecto — podemos relanzar el pipeline manualmente.

Tres causas habituales. (1) El DNS aún no se ha propagado del todo — espera 5–15 minutos y haz hard refresh. (2) Tu navegador cacheó un asset antiguo — abre en una ventana de incógnito. (3) La salida de la primera build era sintácticamente válida pero lógicamente incorrecta — inicia un chat con "la home aparece en blanco al abrirla" y la IA lo arregla en la siguiente refinación. La consola del navegador (F12 → Consola) suele mostrar el error real.

Las builds corren en una cola compartida. Free y Starter tienen prioridad estándar y pueden esperar unos minutos en horas pico; Pro y Business obtienen huecos prioritarios y casi nunca esperan. Si tu build lleva más de 10 minutos en cola, no es normal — refresca la página (el estado se actualiza por websocket y a veces la conexión se cae), y si sigue sin arrancar, escribe a soporte con el ID del proyecto.

Sí. Abre el proyecto, pulsa el menú de tres puntos y elige "Redesplegar". Tu código se queda idéntico — pero se recogen las variables de entorno nuevas, los artefactos de build expirados se reconstruyen, y cualquier mejora del lado de la plataforma (parches de seguridad en el runtime, por ejemplo) se aplica. Un redespliegue sin cambios cuesta 1 crédito y termina en menos de un minuto.

En AWS, por defecto en la región us-east-1. Los assets estáticos se sirven desde la red global de edge de CloudFront, así que tus visitantes llegan a un PoP cercano sin importar dónde esté el origen. El renderizado en servidor corre en AWS Lambda, la base de datos de tu proyecto está en Amazon RDS Postgres, y los archivos subidos viven en S3. La residencia de datos en la UE está en la hoja de ruta pero no disponible todavía — avisa a soporte si es un requisito duro para ti.

Sí — el código de tu proyecto vive en un repo de GitHub que creamos a tu nombre. Abre Ajustes del proyecto → Repositorio para ver la URL y darle acceso de escritura a tu cuenta. Puedes clonarlo, forkearlo o moverlo a otra org de GitHub como cualquier repo. Lo mismo con tu base de datos (exponemos una cadena de conexión Postgres en Ajustes → Base de datos → Exportar). Mantienes la propiedad del código y los datos; FloopFloop es una capa de despliegue + IA por encima.

En Pro o superior: abre el proyecto, ve a Ajustes → Dominios, pulsa "Añadir dominio" e introduce tu dominio (raíz o subdominio). FloopFloop te muestra dos registros DNS que añadir en tu registrador — un CNAME (o A/ALIAS para un dominio apex) y un TXT para verificar. Una vez detectados los dos, el SSL se aprovisiona automáticamente y el dominio queda en vivo, normalmente en 5–30 minutos. Free y Starter no admiten dominios propios; necesitas subir de plan.

La mayoría de problemas son del DNS. Verifica que el registro CNAME (o A/ALIAS) exista, apunte al valor que te mostró FloopFloop y no esté detrás de un proxy que bloquee nuestra verificación (la "nube naranja" de Cloudflare debe estar apagada hasta que la verificación termine; después puedes volver a activarla). Usa `dig tu-dominio.com +short` desde la terminal para ver lo que ve el mundo. La verificación suele tardar menos de 15 minutos; si tras una hora sigue en "Pendiente", escribe a soporte con el dominio.

Todos los secrets se cifran en reposo con AES-256 en AWS Secrets Manager y solo se descifran en el runtime de tu proyecto en tiempo de petición; nunca se escriben a disco ni a los logs de build. Una vez que guardas un secret, el valor es de solo escritura: puedes actualizarlo o borrarlo, pero no volver a leerlo desde el panel. El personal de FloopFloop no tiene acceso a los valores en claro; solo vemos el nombre de la clave y los metadatos de auditoría.

Sí. Abre Ajustes → Secrets, busca la entrada, pulsa "Rotar" y pega el nuevo valor. En unos 30 segundos el runtime en ejecución empieza a leer el nuevo valor (los secrets se recargan en caliente y no reiniciamos la función). Si el secret forma parte de una config de build-time (poco común), verás un banner pidiéndote redespliegue — tarda alrededor de un minuto y cuesta 1 crédito.

Dile a la IA en el chat: "añade un cron job que corra cada día a las 9 AM y me envíe un correo con el resumen de nuevos registros". La IA genera una ruta `/api/cron/<nombre>` en tu código, registra el schedule (expresión cron o intervalo) y en cada redespliegue nuestro scheduler mantiene la inscripción sincronizada. Cada invocación llega con un bearer token con scope al proyecto, así solo nuestro scheduler puede dispararla. Las ejecuciones y los logs están en Ajustes → Schedules.

En macOS y Linux: `curl -fsSL https://floop.tech/install.sh | sh`. En Windows: descarga el último instalador desde la página de Releases de GitHub del repo floop-cli, o usa `winget install FloopFloopAI.floop`. Una vez instalado, ejecuta `floop login` — abrirá un navegador para autorizar este dispositivo. A partir de ahí, `floop new`, `floop refine`, `floop deploy` y el resto de comandos funcionan sin configuración extra.

Un token de CLI es la credencial que `floop login` escribe en tu config local — identifica al usuario humano en un dispositivo concreto y puedes revocarlo desde /account/devices cuando dejes de usar un portátil. Una API key es para acceso no atendido desde scripts, CI o apps de terceros — las creas en /account/api-keys, puedes acotarlas por proyecto si quieres y rotarlas cuando quieras. Ambas atacan la misma superficie `/api/v1/*`, pero solo las API keys deben quedar dentro de automatizaciones.

Sí — los ocho SDK oficiales (Node, Python, Go, Rust, Ruby, PHP, Swift, Kotlin) envuelven la misma superficie `/api/v1/*` y exponen nombres de método paralelos. Cuando añadimos un endpoint lo reflejamos en todos los SDK en la misma release. El servidor MCP (`@floopfloop/mcp`) reexpone el SDK de Node a agentes LLM y recibe el método nuevo automáticamente. Si detectas un hueco, es un bug — abre un issue en el repo del SDK correspondiente.