Despliega Streamlit en Nodion

Despliega Streamlit paso a paso

1. Añade Streamlit y fija la versión de Python Incluye streamlit y tus librerías de datos en requirements.txt. Fija en .python-version una versión de Python que admitan tus librerías, porque un rango elige la versión más reciente. requirements.txt

   streamlit
   pandas

2. Arranca Streamlit desde un Procfile Sin esta línea, Nodion lanzaría python app.py, que ejecuta el script pero no arranca ningún servidor. Los flags hacen que Streamlit escuche en todas las interfaces y en el PORT que define Nodion, y evitan la pregunta interactiva del primer arranque. Procfile

   web: streamlit run app.py --server.port $PORT --server.address 0.0.0.0 --server.headless true

3. Guarda los secretos en variables de entorno No hagas commit de .streamlit/secrets.toml. Define las claves de API como variables secretas en la pestaña Environment y léelas con os.environ; existen en runtime, que es justo cuando Streamlit ejecuta tu script.
4. Crea la app y haz push Crea una aplicación desde tu repositorio de GitHub, GitLab, Bitbucket o Gitea en la región EU Central. Las apps que cargan DataFrames necesitan memoria, así que 1 GB es un buen punto de partida. Streamlit responde a / con 200, por lo que el health check por defecto funciona tal cual.

A tener en cuenta

• Una sola instancia más grandeStreamlit guarda el estado de cada sesión en la memoria del proceso que la atiende. Con varias instancias, un navegador que se reconecta puede acabar en otra y empezar de cero, así que una sola instancia más grande suele ser la opción más sencilla.
• Archivos y cachésst.cache_data y los archivos escritos en runtime viven en la instancia y desaparecen tras el siguiente despliegue o tras la sustitución diaria por una instancia nueva. Guarda los datos que necesites en una base de datos, un bucket o un volumen.

Lo que Nodion gestiona por ti

• Despliegues sin downtime Haz push a tu rama y Nodion construye una nueva release. El tráfico pasa a las nuevas instancias cuando superan el health check; si una release falla, la que está en marcha sigue activa. En cambio, las apps con un volumen local se reinician porque el disco pertenece a una sola instancia.
• Bases de datos junto a la app PostgreSQL, pgvector, MySQL, Valkey y ClickHouse gestionados en la misma región. Al vincular una base de datos, sus datos de conexión llegan como DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Previews por pull request Activa las previews: cada pull request de tu repositorio tendrá su propia app, con URL y bases de datos nuevas y vacías. Puedes crearla automáticamente o a mano. Se omiten las pull requests de forks y bots.
• Workers, cron jobs y escalado Ejecuta workers como procesos adicionales de la misma app, programa tareas en la pestaña Cron y escala cada proceso hasta 16 instancias.
• Paso de release Con buildpacks, una línea release: del Procfile se ejecuta con cada nueva build. Las apps con Dockerfile, así como los redeploys o rollbacks a una imagen anterior, usan un comando de release definido en la propia app, que además tiene prioridad sobre la línea del Procfile. En los sitios estáticos, el paso de release se ejecuta en una imagen que solo contiene los archivos generados por la build.
• Logs y métricas Logs de build, release y runtime, además de métricas de CPU, memoria, disco y red de cada instancia, en el dashboard.
• Dominios y HTTPS Un nombre de host predeterminado con HTTPS desde el primer despliegue; tus propios dominios reciben certificados automáticamente.

Para seguir leyendo

• ¿Qué es PaaS? Platform as a Service explicado De qué se encarga un PaaS, qué sigue siendo cosa tuya, cómo se compara con IaaS, SaaS, serverless y Kubernetes y qué comprobar antes de elegir uno.

Streamlit en Nodion: preguntas y respuestas