Qué es 'nivel producción' en una biblioteca 3D

“Nivel producción” suele llegar como un cumplido sin nada detrás. Aun así tiene un significado comprobable, y las pruebas son poco amables con casi todo lo que corre en un homelab, incluida parte de lo que yo defendería.

Con cuatro preguntas queda cubierto. ¿Sabe el sistema avisarte cuando ha perdido algo? ¿Ha recorrido su camino de restauración alguien que no sea su autor, o sea tú? ¿Se detiene cuando duda, en lugar de adivinar? ¿Puede decir quién cambió qué? Las herramientas de impresión 3D autoalojadas suelen calificarse por la cuarta pregunta, que es la más fácil, y suspender la primera, que es la que te cuesta una biblioteca.

¿Sabe avisarte cuando ha perdido algo?

Es la propiedad que nadie pide y que todo el mundo necesita. Una biblioteca de modelos se escribe una vez y se lee muy de tarde en tarde: importas una malla, la laminas, y luego no vuelves a abrir el original en año y medio. Ese es el peor patrón de acceso posible para detectar daños, porque el hueco entre la pérdida y el descubrimiento es tan largo que ninguna rotación de copias de seguridad conserva ya la copia buena.

La prueba es sencilla. Pídele a la herramienta que verifique que los bytes que cree tener son los bytes que hay en disco, y mira si puede. Una biblioteca que guarda un hash al subir el archivo y no lo vuelve a comprobar nunca no está haciendo integridad, está haciendo contabilidad.

PrintStash sí lo tiene, y llegó en la v0.11.1 como la auditoría de la bóveda. Una ejecución recorre los archivos que le pertenecen, compara cada uno con el tamaño y la suma de comprobación registrados, e informa de un blob que falta, de un tamaño que no cuadra, de un hash que no cuadra o de un objeto ilegible como hallazgo crítico. También comprueba los invariantes que una biblioteca puede romper por su cuenta: un modelo sin ningún archivo vivo, una revisión recomendada que ya no existe, dos revisiones marcadas las dos como recomendadas, metadatos que no se pudieron interpretar, una miniatura que ha desaparecido. Los hallazgos se conservan, puedes marcar uno como ignorado a propósito, y un conjunto reducido se puede reparar in situ. Gestionar una biblioteca grande explica cómo ejecutarla.

Lo que no hace es inspeccionar tu geometría. Una malla cuyo hash cuadra y que siempre estuvo rota sigue rota, y ninguna comprobación de integridad del almacenamiento tiene opinión sobre las aristas no manifold. Esa distinción se difumina lo bastante a menudo como para merecer decirla sin adornos.

¿Se ha probado la restauración, y la has probado tú?

Todos los proyectos llevan una función de copia de seguridad. Muchos menos llevan una restauración que haya ejecutado alguien de fuera del proyecto, y en ese hueco es donde ocurre de verdad la mayor parte de la pérdida de datos.

Vale la pena conocer con precisión el modelo que se ha publicado, porque dos de sus partes son límites y no funciones. Una copia completa contiene la base de datos, los archivos que PrintStash posee, los documentos, las miniaturas y un manifiesto, y se puede replicar a un bucket compatible con S3. No contiene los bytes de origen de nada indexado desde un volumen compartido, porque PrintStash no es su dueño, así que una carpeta de un NAS montada en su sitio queda cubierta por tu política de NAS y por nada más. Y la copia de seguridad de base de datos integrada solo admite SQLite en fichero: una instalación con PostgreSQL necesita un pg_dump gestionado por el operador, y la API de copias informa de esa capacidad en lugar de disimularla.

Las partes que de verdad defendería son más estrechas y más concretas que el nombre de la función. La creación de la copia falla en cerrado cuando un archivo propio falta, no se puede leer o cambia de tamaño mientras se escribe el archivo comprimido, así que una copia que habría quedado incompleta en silencio simplemente no existe. La v0.11.3 hizo que la copia de SQLite fuera transaccionalmente consistente y que la restauración fuera por fases y con vuelta atrás segura. El archivo pone su manifiesto al principio, para que listar las copias remotas no implique descargarlas.

La planificación y el ensayo corren de tu cuenta. Las copias se crean a demanda, así que un cron o una llamada externa es lo único que las hace regulares, y una restauración que nunca has ejecutado es un plan, no una capacidad. Copias de seguridad que sí se restauran recorre el camino de recuperación, y existe porque la alternativa es enterarte durante la emergencia.

¿Se detiene cuando duda?

Si ordenara estas cuatro por el daño que causa su ausencia, esta iría primero. Un sistema que adivina cuando no está seguro acabará adivinando en la dirección de borrar algo.

El ejemplo más claro en la versión publicada es el escaneo de volúmenes compartidos. Una carpeta replicada cuyo montaje se ha caído se ve, para el sistema de ficheros, exactamente igual que una carpeta cuyo contenido se ha borrado por completo, y la implementación obvia responde tirando a la basura tu biblioteca entera. PrintStash se niega: un escaneo aborta sin tocar el índice cuando la raíz falta, no se puede leer o está vacía mientras el volumen todavía tiene archivos indexados, y se marca a sí mismo como fallido. Los bytes externos enlazados también quedan fuera por completo del borrado definitivo de la papelera y de la recolección de almacenamiento, así que los únicos archivos que llegará a quitar del disco son copias que hizo él mismo.

La v0.11.4 añadió otro, y se lee como una limitación hasta que piensas en lo que evita. La topología admitida es un proceso de API por bóveda, y el arranque reclama un cerrojo y falla rápido si ya hay otro proceso activo. Levantar dos réplicas contra una misma bóveda sería de esas configuraciones que parecen funcionar durante semanas y luego entrelazan dos escritores sobre los mismos archivos. Negarse a arrancar es el mejor de los dos fallos.

El mismo instinto aparece en cómo se describen los proveedores de impresora. Moonraker es estable, los otros cuatro están en beta, y sus diferencias de capacidad se declaran proveedor por proveedor en lugar de promediarse en una afirmación de marketing: Bambu LAN no tiene inventario remoto de archivos, Elegoo Centauri tiene subida en beta sin inventario, y el consumo de filamento y la duración medidos solo vuelven de Moonraker. Una herramienta que presentara estimaciones como mediciones sería más fácil de vender y peor para llevar un negocio. La matriz de compatibilidad es la versión actual de esa tabla.

¿Puede decir quién cambió qué?

La más fácil de las cuatro, y la que la mayoría de los proyectos pone por delante. PrintStash registra las entradas de auditoría en la capa de persistencia y no en el handler, así que una creación, una actualización o un borrado sobre una fila vigilada produce una entrada de log con el actor, la IP del cliente y un diff campo por campo de lo que se movió, sin depender de que alguien se acuerde de añadir la llamada de registro a un endpoint nuevo. Los campos de credenciales están en una lista de redacción, así que las claves de API, los códigos de acceso de las impresoras, los hashes de contraseña y los secretos de los canales de notificación aparecen redactados en el diff en lugar de aparecer en el log.

El control de acceso tiene alcance por colección, con roles de Ver, Editar y Administrar; los roles por impresora para estado, impresión, control y administración llegaron en la v0.11.1, y el inicio de sesión OIDC contra Authentik o Authelia aterrizó en la v0.11.0, para que las cuentas puedan vivir donde viven el resto de las cuentas de tu homelab. Montar una biblioteca compartida cubre cómo se comportan esos roles cuando hay más de una persona implicada.

Dónde esto sigue siendo un proyecto de aficionado

Ser justo con las cuatro primeras obliga a ser directo con el resto, porque un texto que se puntuara bien a sí mismo con sus propios criterios no merecería leerse.

No hay alta disponibilidad ni plan para tenerla. Un proceso, una bóveda y un cerrojo que te impide hacer otra cosa. Si el host muere, el servicio está caído hasta que lo levantes, y el tiempo de recuperación es lo que tarde tu restauración.

Los secretos de los canales de notificación, las credenciales de las impresoras y el resto de secretos configurados se guardan sin cifrar en la base de datos, como en la mayoría de las herramientas autoalojadas de esta forma. Es un compromiso deliberado apoyado en la suposición de una red de confianza, y es un compromiso real: un fichero de base de datos que sale de tu red se lleva consigo un token de bot de Telegram y un juego de códigos de acceso de impresora. Qué significa aquí una red de confianza es la versión larga.

La cobertura de proveedores sigue necesitando hardware. Cuatro de los cinco proveedores están en beta, y beta en este contexto significa que los caminos de código funcionan contra las máquinas que había disponibles, no contra cada revisión de firmware y cada montaje de red que pueda tener la tuya. Las vistas previas de STEP y STP eran solo para amd64 cuando se escribió esto; la v0.12.0 añadió wheels de ARM para la dependencia de teselado, con evidencia de CI desde una imagen ARM64 bajo QEMU y no desde hardware Pi físico.

Y la categoría entera tiene un problema de validación que no arregla ninguna cantidad de cobertura de tests interna. Las integraciones con impresoras fallan de formas que solo aparecen contra hardware real a lo largo de meses, y la base instalada de un proyecto autoalojado es a la vez su flota de pruebas y la población que absorbe los fallos.

La parte que no es trabajo del software

La mitad incómoda de autoalojar algo de lo que piensas depender es que el nivel producción también es una propiedad del operador, y esa mitad no viene dentro de un contenedor.

Un servicio gestionado hace planificación de capacidad, parcheo, verificación de copias y respuesta a incidentes con gente cuyo trabajo es eso. Autoalojar te pasa todo eso a ti, y el software solo puede hacer el trabajo posible, no innecesario. Una auditoría que nadie ejecuta no informa de nada, una copia que nadie ha restaurado es un fichero en un disco, y una actualización aplicada seis meses tarde es una vulnerabilidad conocida con tu nombre puesto. Todo lo anterior sirve porque hace manejable el trabajo del operador, no porque lo elimine.

Que es también la respuesta honesta a si la infraestructura de impresión 3D autoalojada es de nivel producción. El software puede serlo. Que lo sea tu instalación depende de cuatro horas de trabajo por trimestre que nadie te va a recordar.

Lo que se publicó después de escribir esto

Esta sección describía la pull request 68 como dirección y no como capacidad, porque en ese momento era una rama abierta apuntando a la v0.12.0. Esa versión se publicó el 19 de agosto de 2026, así que el trabajo ya se puede instalar: trabajos de importación duraderos que no pueden dar la tarea por terminada antes de que sus salidas sean verificables, hash de contraseñas con Argon2 que actualiza los hashes bcrypt heredados al iniciar sesión, teselado de STEP acotado en un proceso hijo desechable y el cambio que más importa para el argumento de arriba, que es que el arranque y el mantenimiento horario ya no deducen la propiedad de los archivos borrando del almacenamiento los objetos no indexados. Las notas de la v0.12.0 cubren el resto. Las valoraciones que se dan más arriba en este artículo describen la v0.11.4, que es contra lo que se midieron.

El trabajo de una tarde

Si quieres la versión honesta de esto en lugar del ensayo, cuatro cosas:

1. Ejecuta una auditoría completa de la bóveda y lee los hallazgos, incluidos los que decidas ignorar.
2. Restaura una copia de seguridad en una instalación de usar y tirar y abre tres modelos en ella.
3. Confirma que tu política de NAS cubre las carpetas que PrintStash indexa pero no posee.
4. Pon la creación de copias en un planificador, porque la API no lo va a hacer por ti.

Nada de eso es trabajo interesante y todo eso es la diferencia entre una biblioteca y una carpeta que esperas que esté bien.

Preguntas que suelen surgir

¿Está la gestión autoalojada de archivos de impresión 3D lista para producción?

Para un taller o una granja pequeña, la parte de software está más cerca de lo que sugiere la reputación de la categoría: la verificación de integridad, la copia de seguridad transaccionalmente consistente con restauración por fases, el control de acceso por colección y por impresora y el registro de auditoría están todos en versiones publicadas desde la v0.11.4, y la v0.12.0 añadió encima el arreglo de la propiedad del almacenamiento y los resultados de importación duraderos. Lo que no hay es alta disponibilidad, y lo que no es automático es la parte del operador, es decir copias programadas, restauraciones probadas y actualizaciones aplicadas. Si tu definición de listo para producción incluye sobrevivir a un host muerto sin que te enteres, ninguna herramienta autoalojada de un solo proceso la cumple, esta incluida.

¿Qué diferencia hay entre una suma de comprobación al subir el archivo y una comprobación de integridad de verdad?

Un hash registrado al subir el archivo demuestra cómo eran los bytes cuando llegaron. Comprobar la integridad significa volver a leerlos más tarde y comparar, que es la única forma de detectar un disco que falla, una copia mala o un objeto que perdió el backend de almacenamiento. La distinción importa sobre todo en las bibliotecas de modelos porque el patrón de acceso esconde el daño durante meses: no vas a volver a abrir ese STL hasta que quieras reimprimirlo, y para entonces la copia buena ya ha salido de la rotación de tus copias de seguridad. Una verificación que puedes lanzar cuando quieras es la diferencia entre enterarte cuando tú decidas y enterarte el peor día posible.

¿Necesita alta disponibilidad un montaje autoalojado?

Casi con seguridad no, y perseguirla suele ser dedicarle el trimestre de esfuerzo equivocado. Que una biblioteca de impresión se caiga durante dos horas te cuesta dos horas de molestia, mientras que una biblioteca de impresión que pierde archivos te cuesta los archivos. Gasta el esfuerzo en el tiempo de recuperación y en copias verificadas antes que en redundancia, porque el fallo que vas a vivir de verdad es un disco lleno, una actualización chapucera o un recurso compartido sin montar, y ninguno de esos se resuelve con una segunda réplica. Se resuelven con un sistema que se niega a actuar cuando no está seguro, y con que tú tengas una restauración que ya has practicado.

¿Qué debería comprobar antes de confiar a una herramienta autoalojada la única copia de algo?

Si puede verificar su propio almacenamiento, qué excluye su archivo de copia de seguridad y qué hace cuando no consigue saber qué está pasando. La tercera es la más reveladora y la más fácil de probar: desmonta la carpeta que indexa y lanza su sincronización. Una herramienta que informa de un error y no cambia nada la ha construido alguien que pensó en esto. Una herramienta que amablemente elimina todo lo que ya no ve te ha dicho lo que es. Nueve criterios para elegir una cubre el resto de la evaluación.

Fuentes

• Las limitaciones conocidas de PrintStash para la topología de un solo proceso, la copia de seguridad integrada solo para SQLite y el tratamiento de los secretos almacenados.
• Los hallazgos de la auditoría de la bóveda, el registro de auditoría y el escaneo de bibliotecas externas de PrintStash en la versión publicada v0.11.4, en el repositorio.
• La pull request 68 para el trabajo de la v0.12.0 sin publicar y su propia lista de requisitos pendientes para la versión. Abierta y sin etiquetar a 19 de agosto de 2026.