Migrar una app de Streamlit a producción: cuándo y cómo hacerlo
Streamlit es excelente para prototipar y malo para ser tu producto. Cómo saber cuándo migrar y qué arquitectura usar sin botar lo aprendido.
Streamlit es una de las mejores herramientas que existen para convertir un análisis de Python en una interfaz usable en horas. Y precisamente por eso muchas empresas terminan con Streamlit en producción sin haberlo decidido nunca: el prototipo funcionó, la gente lo empezó a usar, y un año después esa "prueba" es el sistema del que depende un proceso del negocio. Lo sé de primera mano: la primera versión de este mismo sitio fue una app de Streamlit.
Las señales de que ya toca migrar
Hay cuatro síntomas claros. Primero, Google no te ve: Streamlit entrega una página vacía que se pinta con JavaScript, así que tu contenido no existe para los buscadores. Segundo, la sesión se reinicia y los usuarios pierden trabajo. Tercero, cada usuario concurrente cuesta memoria del servidor de forma desproporcionada. Cuarto, quieres control fino de la interfaz —marca, velocidad, móvil— y peleas contra el framework en vez de trabajar con él.
Qué conservar de la app original
La lógica de Python casi siempre se salva completa. El error típico de la migración es reescribir todo; lo correcto es separar: la lógica de negocio y de datos se convierte en una API (FastAPI es la ruta natural, porque el código ya es Python), y solo la capa visual se reescribe en un framework web de verdad, como Next.js, que entrega HTML completo al navegador y a los buscadores.
La arquitectura de llegada
El patrón que uso: FastAPI sirviendo la lógica existente, Next.js sirviendo la interfaz con renderizado en servidor, PostgreSQL como fuente de datos, y todo desplegado con Docker detrás de un proxy con TLS automático. Con esa base, la app gana lo que Streamlit no puede dar: posicionamiento en Google, sesiones estables, control total del diseño y costos de servidor predecibles.
El error a evitar
No migres en caliente. Deja la app de Streamlit corriendo mientras la nueva versión se construye y se valida en un dominio temporal, y solo entonces cambia el dominio principal. La migración correcta es aburrida: el día del cambio no debería pasar nada visible, excepto que todo funciona mejor.