ChatGPT Sites lleva Codex a apps internas: publicar ya no es lo mismo que prototipar
OpenAI documentó Sites para Codex como plugin en preview para crear, guardar, desplegar e inspeccionar apps hospedadas. La lectura útil para builders es separar prototipo, versión guardada, deploy productivo, acceso y storage antes de compartir una URL interna.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
OpenAI ya documenta Sites como plugin de Codex para crear, guardar, desplegar e inspeccionar sitios, apps web y juegos hospedados por OpenAI. En la práctica, el mensaje es bastante directo: Codex no solo quiere escribir código; también quiere cerrar el loop de prototipo a URL usable dentro del workspace.
Eso suena cómodo, pero la lectura importante para builders es menos glamorosa: publicar no es lo mismo que prototipar. La propia documentación insiste en que cada URL de Sites es un deploy de producción. Si quieres revisar antes, debes pedirle a Codex que guarde una versión deployable sin publicarla.
Qué resuelve Sites
Sites apunta a un dolor muy real en equipos internos. Muchas ideas útiles mueren entre “hagamos un mini dashboard” y “¿dónde lo hospedamos, quién lo mantiene y cómo le damos acceso al equipo?”. El plugin intenta empaquetar ese tramo:
- Codex crea o adapta el proyecto;
- valida si el build es compatible;
- guarda versiones deployables;
- despliega una versión aprobada;
- permite revisar estado y URL;
- y puede asociar storage cuando la app necesita datos persistentes.
OpenAI menciona formas de sitio con D1 para datos estructurados y R2 para archivos. No es solo una landing sin estado. Puede servir para dashboards internos, formularios, herramientas operativas simples o juegos con progreso.
La frontera que no debes cruzar a ciegas
La tentación obvia es pedir: “hazme una app y despliega”. Mala idea.
Si Sites publica una URL productiva, el checklist tiene que venir antes:
- revisar el código y cualquier migración;
- confirmar que el build pasó;
- verificar qué versión guardada vas a desplegar;
- definir quién puede acceder;
- configurar secretos desde el panel de Sites, no en archivos del repo;
- confirmar el estado del deploy antes de compartir la URL.
Ese orden parece burocrático hasta que una app interna expone datos o una versión equivocada queda abierta a todo el workspace.
Dónde sí tiene sentido para Latinoamérica
Para equipos pequeños en Latinoamérica, Sites puede ser interesante porque baja fricción en herramientas internas que no justifican un stack completo desde el día uno. Piensa en:
- tablero de solicitudes operativas;
- mini CRM interno;
- monitor de tareas;
- formulario de QA;
- dashboard de contenido;
- demo funcional para validar un flujo.
La clave es tratarlo como app interna con dueño, no como juguete generado. Si la herramienta guarda datos o influye en decisiones, necesita revisión, permisos y rollback.
Qué preguntas haría antes de usarlo
Antes de pedir un deploy, yo respondería cuatro preguntas:
- ¿La app necesita datos durables o solo estado temporal?
- ¿Quién debe verla: solo dueño, admins, todo el workspace o un grupo?
- ¿Qué secretos o variables de entorno necesita?
- ¿Cómo sabré que la versión desplegada es la aprobada?
Si no puedes contestar eso, todavía estás en modo prototipo. Pide a Codex guardar una versión revisable, no desplegarla.
Por qué es noticia de agentes
Sites no es solo hosting. Es otra señal de que los coding agents están absorbiendo piezas del ciclo de software: crear, iterar, validar, versionar, desplegar y controlar acceso. Eso conecta con temas que ya cubrimos como Codex Developer mode para depurar frontend: el agente no solo escribe; observa, corrige y ahora también publica.
En español casi toda la conversación se queda en “hacer una app con IA”. La parte útil es otra: cómo decidir si esa app merece producción y qué controles activar antes de compartirla.