Elige almacenamiento externo para flujos de Transloadit

Conclusiones clave

Elige el modelo de almacenamiento antes que el proveedor: el almacenamiento de objetos, el almacenamiento colaborativo de archivos y los servidores de transferencia de archivos resuelven problemas operativos distintos.
Trata la importación y la exportación como límites de confianza independientes, con credenciales de Template de mínimo privilegio solo para las rutas y acciones que necesita cada flujo de trabajo.
No infieras acceso público a partir de una URL devuelta; la política del bucket, la configuración de uso compartido, las URL firmadas y los permisos del servidor determinan si un resultado es recuperable.

Elegir una integración de almacenamiento es una decisión de arquitectura, no una búsqueda de un nombre de proveedor. Los almacenes de objetos, los servicios de archivos colaborativos y los servidores de transferencia de archivos exponen distintos modelos de permisos, garantías de URL, comportamientos de listado y modos de fallo. Esta guía agrupa los destinos compatibles según esas diferencias para que puedas elegir un flujo de trabajo de forma deliberada en lugar de copiar ejemplos casi idénticos.

Empieza por el modelo de almacenamiento, no por el logo del proveedor

El almacenamiento de objetos es la opción natural para bibliotecas multimedia propiedad de la aplicación. Amazon S3, Azure Blob Storage, Backblaze B2, Cloudflare R2, DigitalOcean Spaces, Google Cloud Storage, MEGA S4 Object Storage, MinIO, OpenStack Swift, Supabase Storage, Tigris, Wasabi y Rackspace Cloud Files exponen destinos orientados a buckets o contenedores mediante sus propios Robots de Transloadit. Aun así, difieren en credenciales, campos de endpoint o región, controles de acceso y las URL de resultado, de modo que «almacenamiento de objetos» describe la arquitectura y no un formato de configuración compartido.

Box y Dropbox son servicios de archivos en la nube orientados a cuentas y carpetas. Sus carpetas, enlaces y sistemas de permisos orientados al usuario pueden ser valiosos cuando las personas trabajan directamente con archivos exportados. FTP y SFTP, en cambio, apuntan a servidores de transferencia de archivos y a convenciones de sistema de archivos existentes. Elige estos modelos porque un socio o un sistema heredado los requiere, no porque sus cadenas de ruta se parezcan a claves de objeto.

Almacenamiento de objetos

Prefiere este modelo para los recursos de la aplicación direccionados por claves estables, reglas de ciclo de vida y una política de bucket o contenedor controlada por el proveedor.

Almacenamiento colaborativo

Prefiere Box o Dropbox cuando las carpetas de cuenta y los enlaces gestionados por el proveedor forman parte de la experiencia de producto requerida.

Transferencia de archivos

Prefiere SFTP o FTP cuando el sistema receptor está definido por una cuenta de servidor, un árbol de directorios y un contrato de transferencia establecido.

Empareja cada destino con su par de Robots de Transloadit correspondiente

El nombre del destino se corresponde con un Robot de importación y un Robot de almacenamiento: /s3/import y /s3/store, /azure/import y /azure/store, /backblaze/import y /backblaze/store, /box/import y /box/store, /cloudflare/import y /cloudflare/store, /digitalocean/import y /digitalocean/store, y /dropbox/import y /dropbox/store. La misma correspondencia se aplica a /ftp, /google, /mega, /minio, /sftp, /supabase, /swift, /tigris, /wasabi y /cloudfiles, como /sftp/import con /sftp/store.

Un Robot de importación crea archivos que Steps posteriores pueden procesar. Un Robot de almacenamiento consume resultados de Steps seleccionados y los escribe en el destino. Esa dirección importa al diseñar permisos y observabilidad: una transformación exitosa no demuestra que la exportación tuvo éxito, y una importación exitosa no demuestra que la fuente seguirá disponible después del procesamiento. Registra el estado final de la Assembly e inspecciona el resultado del Step de almacenamiento del que realmente dependes.

Entradas explícitas

La relación use selecciona los archivos de origen; el Robot de almacenamiento no exporta automáticamente todos los resultados de la Assembly.

Destino explícito

Un Step específico de un proveedor es el límite donde los requisitos de ruta, acceso, metadatos y credencial pasan a formar parte del contrato del flujo de trabajo.

Finalización explícita

La aplicación debería marcar un recurso como duradero solo después de que se haya completado el resultado de almacenamiento requerido y se haya registrado su identidad de destino.

Mantén las credenciales de almacenamiento acotadas y controladas por el servidor

Crea el acceso al proveedor en credenciales de Template y haz referencia al registro por nombre desde un Template guardado. El proveedor sigue determinando qué puede hacer esa credencial. Restríngela a las rutas, operaciones, buckets, contenedores o carpetas de origen y destino más pequeños que necesite el flujo de trabajo. Cuando un proveedor admite credenciales de lectura y escritura separadas, esa separación te da un límite de revocación más claro y reduce el efecto de un Template equivocado.

No envíes claves de proveedor sin procesar en Assembly Instructions controladas por el navegador ni uses campos del cliente para seleccionar un destino sin restricciones. El código de servidor confiable debería autorizar al usuario, elegir un Template revisado y proporcionar solo campos de negocio acotados, como un identificador de recurso. Si varios inquilinos o destinos comparten la forma de un flujo de trabajo, mantén la asignación de inquilino a Template o credencial aprobados en ese límite de confianza.

Privilegio mínimo

Concede el listado y la lectura solo donde una importación los necesite, y la escritura solo donde una exportación tenga permitido crear objetos.

Dominios de confianza separados

Usa registros de credencial distintos cuando los entornos, inquilinos, prefijos de origen o permisos de destino deban poder revocarse de forma independiente.

Selección de confianza

Mantén los nombres de Robot arbitrarios, los hosts de endpoint y la elección de credencial fuera de las solicitudes controladas por un navegador o agente que no sea de confianza.

Diseña deliberadamente la entrega pública, privada, firmada y con URL personalizada

Las integraciones de proveedores no comparten un mismo vocabulario de control de acceso. Amazon S3 expone tanto acl como sign_urls_for, mientras que Cloudflare R2 expone sign_urls_for pero no la opción acl. Azure utiliza firmas de acceso compartido. El valor predeterminado del Robot de Amazon S3 es public-read; en un bucket con Block Public Access habilitado, ese valor predeterminado puede fallar con un error de permisos en lugar de publicar el objeto. Para una entrega privada en S3, usa private en buckets que respeten las ACL de objeto, o usa bucket-default cuando las ACL estén deshabilitadas o Block Public Access esté habilitado. El valor bucket-default se rige por la política del bucket y elimina la necesidad de s3:PutObjectAcl. El Robot de almacenamiento de Wasabi, en cambio, normaliza un acl sin definir a private; define explícitamente public-read solo para una entrega pública en Wasabi. Wasabi no admite bucket-default. Box y Dropbox pueden crear enlaces de uso compartido del proveedor. Otros destinos dependen principalmente de la configuración del bucket, contenedor, carpeta o servidor, fuera del Step de la Assembly.

Mantén separadas las preguntas sobre permisos y sobre generación de direcciones. Un prefijo de URL o una plantilla de URL puede hacer que un resultado apunte a un nombre de host de CDN o de la aplicación, pero reescribir una dirección no configura el origen, no otorga acceso de lectura ni copia el archivo. Por el contrario, un objeto privado puede tener una URL sintácticamente válida que devuelva correctamente un error de autorización. Verifica la ruta exacta del consumidor, el comportamiento de expiración y el proceso de revocación del proveedor seleccionado.

Objetos públicos

Usa la política del proveedor o una ACL explícita solo después de decidir si la recuperación anónima forma realmente parte del contrato del producto.

Acceso firmado

Para un acceso controlado, prueba la expiración de la firma, el desfase de reloj, las respuestas en caché y qué ocurre después de reemplazar o eliminar un objeto.

URL personalizadas

Trata los nombres de host de CDN y las plantillas de URL personalizadas como configuración de enrutamiento que debe coincidir con los permisos de lectura reales del proveedor.

Construye un Step de exportación claro antes de añadir variaciones por proveedor

Un flujo de trabajo de almacenamiento debería dejar claro su flujo de datos. El siguiente Template recibe una subida, crea un derivado WebP acotado y exporta solo ese derivado a Cloudflare R2. El nombre de la credencial se resuelve dentro de la cuenta de Transloadit, mientras que la ruta usa Assembly Variables para evitar claves de proveedor elegidas por el cliente. Un Template de producción debería añadir la validación, el nombrado, los metadatos y la política de sobrescritura que requiera la aplicación.

La misma forma de grafo puede servir de referencia para otro destino, pero el Step del proveedor no es configuración intercambiable. Reemplaza el Robot de almacenamiento solo después de leer su esquema y decidir cómo deberían funcionar las credenciales, la selección de bucket o carpeta, el acceso, las URL y las colisiones. Mantén Templates revisados por separado cuando las diferencias sean operativamente importantes, incluso si sus Steps de transformación siguen siendo idénticos.

Exportar un derivado optimizado a un destino Cloudflare R2 acotado

{
  "steps": {
    ":original": {
      "robot": "/upload/handle"
    },
    "optimized": {
      "use": ":original",
      "robot": "/image/resize",
      "resize_strategy": "fit",
      "width": 1600,
      "height": 1600,
      "format": "webp"
    },
    "exported": {
      "use": "optimized",
      "robot": "/cloudflare/store",
      "credentials": "my-r2-credentials",
      "path": "media/${assembly.id}/${file.id}.${file.ext}"
    }
  }
}

Trata las importaciones de carpetas como trabajo de inventario reanudable

Una importación de un solo archivo puede ocultar la parte difícil de una migración. Los proveedores difieren en cómo se representan las carpetas o prefijos, en si el recorrido es recursivo por defecto u opcional, en cuántas entradas devuelve cada página y en qué valor de continuación solicita la siguiente página. Lee el esquema del Robot de importación seleccionado y usa un conjunto de datos de prueba anidado, con varias entradas y de un tamaño mayor a una página, antes de confiar en él para una migración masiva.

Guarda la intención y el progreso de la migración en tu propio sistema. Registra la identidad de origen, la página o el lote actual, la identidad de destino esperada, el ID de la Assembly y el resultado final. Reintenta de forma idempotente y concilia los recuentos en lugar de asumir que volver a listar una raíz cada vez más grande identificará todos los objetos omitidos de forma económica. Para la incorporación continua, prefiere eventos duraderos o un manifiesto respaldado por una base de datos en lugar de repetidos escaneos completos del bucket.

Datos de prueba representativos

Prueba carpetas vacías, nombres anidados, caracteres inusuales, nombres base duplicados y un listado que cruce al menos un límite de página.

Puntos de control duraderos

Guarda el progreso fuera del proceso para que el reinicio de un proceso en segundo plano no obligue a un relistado completo ni omita silenciosamente la página actual.

Conciliación

Compara los registros de origen esperados con los registros de destino completados y muestra explícitamente los objetos faltantes, duplicados o reemplazados.

Valida la recuperación de fallos y la responsabilidad sobre el ciclo de vida

Prueba credenciales incorrectas, un origen faltante, un endpoint no disponible, una ruta de destino denegada, una colisión de nombres, una firma vencida y una exportación multiarchivo parcial. Las notificaciones se pueden reintentar, por lo que el manejo de finalización debe ser idempotente. Conserva el ID de la Assembly junto con el recurso de la aplicación y decide qué estados terminales pueden reintentarse automáticamente, requerir revisión de un operador o deberían dejar el origen intacto.

El almacenamiento exportado y el almacenamiento temporal de Transloadit tienen distintos responsables y ciclos de vida. El resultado de una Assembly completada no es una copia de seguridad, y eliminar un registro de la aplicación no elimina automáticamente las copias en cada proveedor, caché o ubicación de procesamiento temporal. Documenta la retención, el reemplazo y la eliminación del origen, el derivado, los metadatos del resultado y la dirección pública, y luego prueba esas operaciones con tanto cuidado como el flujo principal inicial.

Finalización segura ante duplicados

Usa una regla de idempotencia a nivel de aplicación para que un callback repetido o un reintento no cree un segundo recurso duradero no deseado.

Observabilidad a nivel de Step

Supervisa la importación, la transformación y la exportación por separado, de modo que un Step previo exitoso no pueda ocultar un traspaso duradero fallido.

Contrato de ciclo de vida

Anota qué sistema elimina cada origen, resultado temporal, derivado, respuesta en caché y registro de la aplicación, incluido el momento en que ocurre.

Detalles técnicos que conviene conocer

Los destinos compatibles usan pares de Robots de importación y almacenamiento, incluidos Amazon S3, Azure Blob Storage, Backblaze B2, Box, Cloudflare R2, DigitalOcean Spaces, Dropbox, FTP, Google Cloud Storage, MEGA S4 Object Storage, MinIO, SFTP, Supabase Storage, OpenStack Swift, Tigris, Wasabi y Rackspace Cloud Files.
Un Step de almacenamiento exporta solo los resultados seleccionados por su valor use, por lo que exportar un original, un derivado o ambos lo determina el grafo de la Assembly, no el proveedor de destino.
Las credenciales de Template son registros a nivel de cuenta a los que se hace referencia por nombre, lo que mantiene las claves del proveedor fuera de los paquetes del navegador y de las Assembly Instructions, aunque la credencial misma deba seguir estando delimitada en el proveedor.
Los controles de acceso son específicos de cada proveedor: en Amazon S3 se exponen tanto acl como sign_urls_for, en Cloudflare R2 se expone sign_urls_for pero no la opción acl, Azure puede generar firmas de acceso compartido, y Box o Dropbox pueden crear enlaces para compartir.
Un prefijo de URL personalizado o una plantilla de URL cambia la dirección indicada en el resultado de una Assembly; por sí solo no otorga acceso, no configura una CDN, no sube otra copia ni prueba que el objeto sea legible públicamente.
Los Robots de importación difieren en el recorrido de directorios, el listado recursivo, el tamaño de página y el comportamiento del token de continuación, por lo que una migración masiva debe seguir el esquema del Robot seleccionado y guardar el progreso fuera de un único bucle en memoria.
FTP y SFTP almacenan archivos en un sistema de archivos del servidor en lugar de en un espacio de nombres de almacenamiento de objetos; SFTP admite autenticación basada en claves y configuración del modo de archivo, mientras que FTP depende de su propio transporte y su propio modelo de permisos del servidor.
Los resultados temporales de una Assembly no son almacenamiento duradero de la aplicación, por lo que todo resultado que deba sobrevivir a la ventana de retención temporal debería exportarse y conciliarse con el sistema de registro de la aplicación.

Un enfoque práctico

1
Clasifica el destino según el modelo de almacenamiento, la región requerida, el límite de responsabilidad y la ruta de recuperación esperada.
2
Crea credenciales de Template con privilegios mínimos y prueba los permisos de importación y almacenamiento por separado.
3
Verifica el comportamiento de objetos privados, públicos, firmados, caducados, reemplazados y eliminados con archivos representativos.
4
Prueba la paginación, las importaciones recursivas, los reintentos, las exportaciones duplicadas y los fallos parciales antes de migrar el tráfico de producción.

Un flujo de trabajo multimedia de cuatro etapas

Cuándo resulta útil Transloadit

Usa un Robot nativo de importación o almacenamiento de Transloadit cuando un flujo de trabajo deba mover archivos entre el procesamiento y un servicio de almacenamiento compatible sin que tu aplicación tenga que pasar los bytes. Elige primero el destino según los requisitos operativos y luego configura explícitamente sus credenciales y su comportamiento de acceso.

Límite de la arquitectura

Transloadit importa archivos, los procesa y exporta los resultados seleccionados mediante el Robot configurado. El destino sigue siendo responsable del almacenamiento duradero, la política del bucket o carpeta, el ciclo de vida de los objetos, la replicación y la entrega. Tu aplicación sigue siendo responsable de la autorización de usuarios, los registros de recursos, las decisiones de publicación y la eliminación en todas las copias.

Preguntas frecuentes

¿Una URL de resultado significa que el archivo exportado es público?

No. La dirección en un resultado de la Assembly describe dónde dice un proveedor o una asignación de URL configurada que se encuentra el objeto. Que un llamador pueda recuperarlo sigue dependiendo de la política del bucket, una ACL del objeto, un enlace de uso compartido del proveedor, una firma válida, o los permisos del sistema de archivos y del servidor web. Prueba el acceso desde un cliente no autenticado en lugar de tratar la presencia de url o ssl_url como una comprobación de permisos.

¿Deberían las importaciones y exportaciones compartir una credencial?

Generalmente no. Otorga a una credencial de importación solo acceso de lectura y listado al prefijo de origen necesario, y a una credencial de exportación solo acceso de escritura a su prefijo de destino. Tener registros separados limita el impacto de una credencial filtrada o mal configurada y facilita la interpretación de los registros de auditoría del proveedor. Una única credencial más amplia puede ser conveniente, pero la conveniencia no es evidencia de que ambas direcciones requieran los mismos permisos.

¿Cuándo debería usar SFTP o FTP en lugar de almacenamiento de objetos?

Usa una integración nativa cuando coincida con el proveedor y el flujo de trabajo deba evitar el paso de bytes de archivos por los servidores de la aplicación. Elige SFTP cuando un contrato existente con un socio requiera transferencia de archivos por SSH o un sistema de archivos de servidor. Usa FTP solo por compatibilidad con un endpoint que no pueda ofrecer una ruta compatible más sólida, y luego restringe la cuenta, la ruta de destino y la exposición de red tanto como el servidor lo permita.

¿Cómo debería mi aplicación hacer seguimiento de los archivos entre proveedores?

Guarda en tu base de datos el ID de la Assembly, el ID de recurso independiente del proveedor, la clave o ruta de destino y la versión prevista. Trata las notificaciones como eventos que se pueden reintentar y haz que el manejo de finalización sea idempotente. En una importación grande, conserva el progreso por página o lote y concilia los recursos esperados con las exportaciones completadas. Los nombres de carpeta del proveedor y las URL para compartir son datos de presentación útiles, pero son identificadores primarios frágiles.

¿Puedo cambiar de proveedor cambiando solo el nombre del Robot?

No de forma segura sin revisar el contrato. El grafo de la Assembly puede permanecer similar, pero las credenciales, los campos de bucket o contenedor, las reglas de rutas, la configuración de acceso, los campos de URL de resultado, la recursión y la paginación pueden diferir. Crea un adaptador de proveedor en código de aplicación confiable o mantén Templates revisados por destino. No permitas que un navegador seleccione un Robot arbitrario ni inyecte credenciales de almacenamiento en Instructions que de otro modo serían confiables.

Elige almacenamiento externo para un flujo de trabajo multimedia