PrintStash v0.5.0: la primera versión etiquetada
La primera versión etiquetada añadió importación por URL y ZIP, previsualizaciones de STEP, enlaces compartidos y trabajos medidos por Moonraker.
PrintStash v0.5.0 fue la primera versión etiquetada. Estableció el flujo básico que va del modelo a la impresión: ingerir un archivo de origen, guardar con él las revisiones de G-code, enviar una a través de Moonraker y guardar el resultado.
Era una versión beta para redes autoalojadas de confianza. Las notas de abajo describen la v0.5.0 tal y como salió, no el conjunto de funciones actual.
Importación, CAD y compartir
La cadena de ingesta aceptaba STL, 3MF, OBJ, STEP/STP y G-code a través de subidas desde el navegador, del hook de posprocesado de OrcaSlicer, de URL directas y de archivos ZIP. Las descargas de URL en el servidor incluían comprobaciones contra SSRF, y el manejo de archivos comprimidos rechazaba el path traversal y la expansión desmedida.
Los archivos STEP y STP se teselaban con OpenCASCADE para previsualizarlos en el navegador. El archivo CAD original seguía disponible para descarga.
Los enlaces compartidos públicos exponían un modelo a través de una página de solo lectura con caducidad. Las descargas eran opcionales, los tokens se guardaban como hashes y las peticiones públicas quedaban limitadas al modelo compartido.
Revisiones y registros de impresión
Los archivos de G-code se podían guardar como revisiones de un modelo, con los metadatos del slicer interpretados, notas, estado y una elección de recomendada. Un trabajo correcto podía marcar automáticamente como verificada una revisión elegible. Las revisiones individuales usaban el mismo ciclo de borrado suave y papelera que el resto de archivos.
Moonraker aportaba la duración y el consumo de filamento de los trabajos completados para el historial de impresión y los registros de coste. Las entradas manuales de historial también funcionaban sin una impresora registrada.
El proveedor de Moonraker incluía estado en vivo, subida y arranque, inventario remoto, pausar, reanudar, cancelar, historial de trabajos y diagnósticos del proveedor. El soporte de Bambu LAN en ese momento se limitaba al estado local en beta y a los controles de pausar, reanudar y cancelar. Todavía no subía ni arrancaba archivos.
Funciones de servidor en la primera versión
La v0.5.0 también incluía:
- configuración de primer arranque y autenticación JWT;
- claves de API con nombre y roles a nivel de colección;
- restaurar y purgar la papelera;
- copia de seguridad y restauración completas más exportación de metadatos en JSON o CSV;
- comprobaciones de salud y registros de auditoría;
- SQLite y disco local por defecto, con Postgres y almacenamiento compatible con S3 como opciones.
La extracción de metadatos seguía dependiendo de lo que cada slicer escribiera en el archivo, y el visor de G-code era una ayuda para inspeccionar y no un simulador de impresión. Exponerlo directamente al público quedaba fuera del modelo de despliegue previsto.
Notas históricas de actualización
El flujo de Compose de la v0.5.0 requería un paso explícito de Alembic:
docker compose downdocker compose pulldocker compose run --rm api uv run alembic upgrade headdocker compose up -dLas imágenes de la versión eran:
ghcr.io/xiao-villamor/printstash-api:0.5.0ghcr.io/xiao-villamor/printstash-frontend:0.5.0
Para un servidor nuevo, usa la guía de instalación actual. El changelog de la 0.5 conserva el detalle original de configuración y migración.