Cómo configurar la transcodificación de vídeo de Cloudinary en Webflow Cloud

Integrar Cloudinary en una aplicación de Webflow Cloud para la distribución de vídeo saca a la luz dos fallos que nunca ocurren en el desarrollo local. El SDK de Node.js importa módulos que bloquean el entorno de ejecución de Cloudflare Workers, y solicitar una URL HLS antes de que Cloudinary termine la transcodificación inmediata devuelve un error 423 al primer espectador.

Ambos problemas tienen soluciones sencillas. Toda la infraestructura de subida y distribución de Cloudinary es accesible a través de su API REST y su CDN, sin necesidad de SDK. Las transformaciones inmediatas resuelven el problema del error 423 al pregenerar las versiones transcodificadas en el momento de la subida, de modo que el primer espectador siempre recibe un resultado almacenado en caché por la CDN en lugar de activar un procesamiento bajo demanda.

La combinación de subidas basadas en fetch, la configuración de ajustes preestablecidos de subida y las URL de transformación es lo que hace que esto funcione correctamente en el entorno de ejecución edge de Webflow Cloud.

En esta guía, exploramos cómo configurar un ajuste preestablecido de subida de Cloudinary con transcodificación inmediata, añadir un gestor de rutas para la subida de vídeos usando fetch estándar, crear una utilidad de URL para generar enlaces de distribución optimizados y configurar el streaming de tasa de bits adaptativa HLS con el perfil de streaming sp_auto de Cloudinary.

¿Qué necesitas para configurar la transcodificación de vídeo de Cloudinary en Webflow Cloud?

Necesitas una aplicación Next.js en Webflow Cloud, una cuenta de Cloudinary con un ajuste preestablecido de subida de vídeo configurado y tres variables de entorno. No se requieren paquetes npm adicionales más allá de los que ya tiene tu proyecto Next.js.

La transcodificación de vídeo de Cloudinary se ejecuta completamente a través de su API REST y su CDN, lo que significa que todo el proceso funciona sin problemas en el entorno de ejecución edge de Webflow Cloud sin necesidad de soluciones alternativas de compatibilidad.

Asegúrate de tener Node.js 22.13.0 o superior instalado localmente con node --version antes de empezar. Si vas a añadir vídeo a una aplicación más grande que ya incluye autenticación, base de datos y pagos, nuestra guía sobre cómo crear una aplicación full-stack en Webflow Cloud con Supabase, Auth0 y Stripe te muestra cómo integrar múltiples servicios en el mismo proyecto.

6 pasos para configurar la transcodificación de vídeo de Cloudinary en Webflow Cloud

La configuración se divide en tres partes:

• Una utilidad de URL que construye enlaces de distribución optimizados de Cloudinary
• Un gestor de rutas que sube vídeos a Cloudinary usando fetch
• La configuración del reproductor HLS que gestiona el streaming adaptativo en todos los navegadores principales. Las transformaciones inmediatas del ajuste preestablecido de subida son las que simplifican el gestor de rutas. En lugar de generar y pasar parámetros de transcodificación en cada solicitud, el ajuste preestablecido los aplica automáticamente y Cloudinary se encarga del resto de forma asíncrona.

Aquí tienes la configuración completa, desde las variables de entorno hasta la primera distribución HLS.

1. Crea una cuenta en Cloudinary y configura un ajuste preestablecido de subida de vídeo

Inicia sesión en Cloudinary, ve a Settings, luego a Upload y después a Upload presets. Haz clic en Add upload preset. Establece el nombre del ajuste preestablecido como webflow_video y el modo de firma (Signing mode) como Unsigned. En los ajustes de transformación del preset, añade la siguiente cadena de transformación inmediata:

• sp_auto,f_m3u8|vc_auto,f_mp4

El carácter de barra vertical (pipe) separa dos salidas inmediatas independientes:

(1) La primera, sp_auto,f_m3u8, le indica a Cloudinary que genere una lista de reproducción maestra HLS y todos los archivos de segmento necesarios utilizando el perfil de transmisión automática.

(2) La segunda, vc_auto,f_mp4, genera un MP4 normalizado para la web como formato de respaldo. Habilita el procesamiento asíncrono para las transformaciones inmediatas (eager) de modo que la respuesta de carga se devuelva al instante.

Si también estableces una carpeta predeterminada en el ajuste preestablecido, como webflow-cloud-videos, las cargas que utilicen este ajuste se organizarán en esa subcarpeta dentro de la Biblioteca de medios. Esto es importante para las URL de entrega: tus ID públicos incluirán la ruta de la carpeta, por ejemplo, webflow-cloud-videos/my-video, cuando construyas las URL en los pasos siguientes.

Elige un patrón de nomenclatura de carpetas coherente y tenlo presente a lo largo de toda la guía.

Antes de guardar el ajuste preestablecido, confirma dos cosas:

(1) El modo de firma (Signing mode) debe estar configurado como Sin firmar (Unsigned). Un ajuste preestablecido firmado requiere una marca de tiempo y una firma HMAC en cada solicitud de carga, algo que el controlador de ruta del Paso 4 no genera y no debería generar para este caso de uso.

(2) Confirma que el ajuste preestablecido esté en estado activo. Los ajustes inactivos devuelven un error 400 indistinguible de un ajuste faltante, y he visto que esto causa tiempo de depuración innecesario en las primeras implementaciones cuando el ajuste se desactivó accidentalmente durante la configuración.

2. Añadir las credenciales de Cloudinary a las variables de entorno de Webflow Cloud

Una vez creado el ajuste preestablecido de carga, añade las tres variables a .env.local en la raíz de tu proyecto de Next.js:

# .env.local
CLOUDINARY_CLOUD_NAME=your-cloud-name
CLOUDINARY_VIDEO_UPLOAD_PRESET=webflow_video
NEXT_PUBLIC_CLOUDINARY_CLOUD_NAME=your-cloud-name

Confirma que .env.local aparece en .gitignore antes de continuar. Luego, para producción, abre el panel de control de Webflow Cloud, navega a la configuración de tu proyecto, selecciona Variables de entorno y añade cada valor. El nombre de la nube y el nombre del ajuste preestablecido no necesitan marcarse como secretos.

3. Crear una utilidad de URL de video para Cloudinary

Cloudinary aplica transformaciones a nivel de URL. Tú construyes una URL con los parámetros de transformación integrados en la ruta, Cloudinary genera el video transformado en la primera solicitud y cada solicitud posterior para esa misma URL se sirve directamente desde la caché de la CDN.

Tu aplicación de Webflow Cloud nunca actúa como proxy de los bytes de video. Genera URL y Cloudinary se encarga por completo de la entrega y el almacenamiento en caché.

Crea lib/cloudinary-video.ts en tu proyecto:

// lib/cloudinary-video.ts

type VideoTransformOptions = {
  codec?: 'auto' | 'h264' | 'h265' | 'vp9' | 'av1'
  quality?: 'auto' | number
  width?: number
  height?: number
  streamingProfile?: 'auto' | 'hd' | 'full_hd' | 'sd'
  format?: 'mp4' | 'webm' | 'm3u8' | 'mpd'
}

export function cloudinaryVideoUrl(
  publicId: string,
  options: VideoTransformOptions = {}
): string {
  const cloudName = process.env.NEXT_PUBLIC_CLOUDINARY_CLOUD_NAME!
  const transforms: string[] = []

  if (options.streamingProfile) {
   // sp_auto selects representations automatically up to 1080p by default.
    // Named profiles like 'hd' or 'full_hd' use a predefined representation set.
    transforms.push(`sp_${options.streamingProfile}`)
  } else {
    if (options.codec) transforms.push(`vc_${options.codec}`)
    if (options.quality) transforms.push(`q_${options.quality}`)
  }
  if (options.width) transforms.push(`w_${options.width}`)
  if (options.height) transforms.push(`h_${options.height}`)

  const transformStr = transforms.length > 0 ? transforms.join(',') + '/' : ''
  // HLS uses .m3u8; MPEG-DASH uses .mpd; standard delivery defaults to .mp4
  const ext = options.format ?? (options.streamingProfile ? 'm3u8' : 'mp4')

  return `https://res.cloudinary.com/${cloudName}/video/upload/${transformStr}${publicId}.${ext}`
}

La opción streamingProfile gestiona los dos patrones de entrega más importantes. Pasar streamingProfile: 'auto' genera una URL HLS usando sp_auto, lo que crea una escala de representaciones de hasta 1080p de forma predeterminada (la cantidad exacta depende de la resolución del video original) y cambia entre ellas en tiempo real a medida que varía el ancho de banda del espectador.

Los perfiles con nombre como 'hd' o 'full_hd' utilizan un conjunto predefinido de representaciones ajustadas a esos niveles de calidad, con variantes de códec H.264, H.265, VP9 y AV1 disponibles para cada uno.

Entrega de un respaldo MP4 optimizado

Para la entrega directa de MP4 sin transmisión adaptativa, pasar codec: 'auto' aplica la transformación vc_auto . Esto normaliza el video para la entrega web seleccionando el códec más adecuado para el navegador que realiza la solicitud, normalmente H.264, H.265 o VP9, y optimiza los ajustes de codificación sin necesidad de que especifiques manualmente los perfiles o niveles de códec.

Añadir quality: 'auto' ajusta la compresión por video según el contenido, lo que a menudo reduce el tamaño del archivo a más de la mitad sin una diferencia de calidad visible.

Aquí tienes ambos patrones en uso:

// HLS adaptive streaming: up to 1080p by default, bandwidth-adaptive
const hlsUrl = cloudinaryVideoUrl('webflow-cloud-videos/product-demo', {
  streamingProfile: 'auto',
})
// → https://res.cloudinary.com/your-cloud/video/upload/sp_auto/webflow-cloud-videos/product-demo.m3u8

// Optimized MP4 for direct playback or browsers without native HLS support
const mp4Url = cloudinaryVideoUrl('webflow-cloud-videos/product-demo', {
  codec: 'auto',
  quality: 'auto',
})
// → https://res.cloudinary.com/your-cloud/video/upload/vc_auto,q_auto/webflow-cloud-videos/product-demo.mp4

Estas dos URL son las que debes pasar a tu reproductor de video. La URL HLS ofrece streaming adaptativo. La URL MP4 sirve como alternativa para navegadores sin compatibilidad nativa con HLS.

4. Crea un controlador de ruta para la carga de videos

El controlador de ruta de carga acepta un archivo de video desde un formulario de cliente, lo envía a la API REST de Cloudinary mediante y devuelve el ID público y las URL de entrega.fetch

Debido a que las transformaciones inmediatas (eager) se configuran en el ajuste preestablecido de carga en lugar de generarse dinámicamente en la solicitud, el controlador de ruta es sencillo: sube el archivo, captura el ID público y devuelve las URL de entrega.

Crea :app/api/video-upload/route.ts

// app/api/video-upload/route.ts
export const runtime = 'edge'

import { NextRequest, NextResponse } from 'next/server'

// Videos larger than 100 MB exceed the Workers runtime request body limit.
// For large files, upload directly from the browser to Cloudinary's upload API
// using NEXT_PUBLIC_CLOUDINARY_CLOUD_NAME and the same unsigned upload preset.
const MAX_VIDEO_SIZE = 100 * 1024 * 1024 // 100 MB

type CloudinaryVideoUploadResult = {
  public_id: string
  secure_url: string
  playback_url: string
  format: string
  duration: number
  width: number
  height: number
  eager?: Array<{ secure_url: string; transformation: string }>
  error?: { message: string }
}

export async function POST(request: NextRequest) {
  const formData = await request.formData()
  const file = formData.get('file') as File | null

  if (!file) {
    return NextResponse.json({ error: 'No file provided' }, { status: 400 })
  }

  if (file.size > MAX_VIDEO_SIZE) {
    return NextResponse.json(
      { error: 'File exceeds 100 MB. Upload large videos directly from the browser.' },
      { status: 413 }
    )
  }

  const cloudName = process.env.CLOUDINARY_CLOUD_NAME!
  const uploadPreset = process.env.CLOUDINARY_VIDEO_UPLOAD_PRESET!

  const uploadData = new FormData()
  uploadData.append('file', file)
  uploadData.append('upload_preset', uploadPreset)

  const response = await fetch(
    `https://api.cloudinary.com/v1_1/${cloudName}/video/upload`,
    { method: 'POST', body: uploadData }
  )

  const result = (await response.json()) as CloudinaryVideoUploadResult

  if (!response.ok) {
    return NextResponse.json(
      { error: result.error?.message ?? 'Cloudinary upload failed' },
      { status: response.status }
    )
  }

  return NextResponse.json({
    publicId: result.public_id,
    url: result.secure_url,
    format: result.format,
    duration: result.duration,
    width: result.width,
    height: result.height,
    // Eager transforms run asynchronously. These URLs are valid immediately
    // but return 423 until transcoding completes.
    hlsUrl: `https://res.cloudinary.com/${cloudName}/video/upload/sp_auto/${result.public_id}.m3u8`,
    mp4Url: `https://res.cloudinary.com/${cloudName}/video/upload/vc_auto,q_auto/${result.public_id}.mp4`,
  })
}

El segmento en la URL de la API de Cloudinary especifica que el tipo de recurso es video, por lo que no necesitas pasar un campo por separado en el cuerpo de FormData. El valor vincula la solicitud a la configuración de transformación inmediata del paso 1./video/uploadresource_typeuploadPreset

Cuando Cloudinary recibe la carga, aplica automáticamente las transformaciones inmediatas definidas en el ajuste preestablecido y las procesa de forma asíncrona. El entorno de ejecución de Webflow Cloud aplica en el tamaño del cuerpo de la solicitud, razón por la cual los archivos de más de 100 MB devuelven un error 413 antes de que se ejecute el controlador.

Para aplicaciones de producción que manejan videos más largos, el patrón correcto es la carga directa desde el navegador. El cliente llama directamente a la API de carga de Cloudinary usando y el nombre del ajuste preestablecido sin firma.NEXT_PUBLIC_CLOUDINARY_CLOUD_NAME

Las transformaciones inmediatas del ajuste preestablecido de carga siguen aplicándose, por lo que la canalización de transcodificación no cambia.

Desde un componente de cliente, una carga directa a Cloudinary se ve así:

// In a Client Component — for large video files
async function uploadVideoDirectly(file: File) {
  const cloudName = process.env.NEXT_PUBLIC_CLOUDINARY_CLOUD_NAME!
  const preset = 'webflow_video'

  const formData = new FormData()
  formData.append('file', file)
  formData.append('upload_preset', preset)

  const res = await fetch(
    `https://api.cloudinary.com/v1_1/${cloudName}/video/upload`,
    { method: 'POST', body: formData }
  )

  const { public_id, secure_url } = await res.json()
  // Store public_id in Webflow CMS, a KV Store, or SQLite for later use.
  return { publicId: public_id, url: secure_url }
}

El devuelto es lo que almacenas en tu capa de datos para usarlo más tarde. Regenera las URL de entrega a partir de él en el momento de la renderización usando la utilidad , en lugar de almacenar las URL completas. Esto significa que puedes cambiar los parámetros de transformación más adelante sin tener que migrar los datos almacenados.public_idcloudinaryVideoUrl

5. Entrega video transcodificado desde la CDN de Cloudinary

Con la carga gestionada y la transcodificación inmediata en cola en segundo plano, entregar el video solo requiere la URL correcta de Cloudinary. Tu aplicación de Webflow Cloud construye la URL y el navegador obtiene el video directamente desde la CDN de Cloudinary. Ningún byte de video pasa por tu servidor.

Un componente de servidor que renderiza una página de video se ve así:

// app/videos/[slug]/page.tsx
import { cloudinaryVideoUrl } from '@/lib/cloudinary-video'

type Props = { params: { slug: string } }

export default function VideoPage({ params }: Props) {
  const publicId = `webflow-cloud-videos/${params.slug}`

  const hlsUrl = cloudinaryVideoUrl(publicId, { streamingProfile: 'auto' })
  const mp4Url = cloudinaryVideoUrl(publicId, { codec: 'auto', quality: 'auto' })

  return (
    <video controls width={1280} height={720}>
     {/* HLS: natively supported in Safari macOS/iOS, Chrome 142 and later, Edge, and Chrome for Android. */}
      <source src={hlsUrl} type="application/x-mpegURL" />
      {/* MP4 fallback for Chrome desktop and Firefox, which require hls.js for HLS. */}
      <source src={mp4Url} type="video/mp4" />
    </video>
  )
}

El tipo MIME en la primera fuente le indica al navegador que se trata de un manifiesto HLS.application/x-mpegURL

Safari en macOS e iOS, Chrome y Edge 142 o posterior en escritorio, y Chrome para Android 147 o posterior admiten HLS de forma nativa y se reproducirán desde la primera fuente. Firefox, Chrome de escritorio anterior a 142 y Chrome para Android anterior a 147 recurren al formato MP4.

Esa alternativa utiliza , que normaliza el video a H.264 y ajusta la compresión automáticamente.vc_auto,q_auto

Si estás sirviendo imágenes adaptativas desde Cloudinary en el mismo sitio junto con videos, la guía sobre cómo servir imágenes adaptativas desde cubre los parámetros de entrega , , y para imágenes que complementan la configuración de video aquí descrita.f_autoq_autow_auto

6. Habilita el streaming de tasa de bits adaptativa HLS con sp_auto

Para páginas de marketing, demostraciones de productos o cualquier video de más de unos pocos segundos que se vea en conexiones con ancho de banda variable, la entrega de archivos MP4 únicos funciona mal. Un MP4 estático no puede adaptarse durante la reproducción cuando el ancho de banda disminuye.

El streaming de tasa de bits adaptativa HLS soluciona esto generando múltiples representaciones de video en diferentes resoluciones y tasas de bits, para luego cambiar automáticamente entre ellas según el ancho de banda disponible del espectador en cada momento.

El parámetro de Cloudinary maneja automáticamente la complejidad de la selección de perfiles. Por defecto, genera representaciones de hasta 1080p usando el formato CMAF, que es compatible tanto con HLS como con MPEG-DASH, seleccionando de un conjunto de representaciones basado en la resolución de origen.sp_auto

Puedes limitar la resolución máxima para controlar cuántas representaciones genera Cloudinary. establece el tope en 720p, lo que produce menos representaciones y reduce el consumo de tu cuota de transformación.sp_auto:maxres_720p

Para la entrega en 4K, está disponible, aunque la transcodificación inicial para representaciones 4K es asíncrona y devuelve un error 423 hasta que finaliza. Precisamente por esto, el ajuste preestablecido de carga define estas como transformaciones "eager" (ansiosas) en lugar de depender del procesamiento bajo demanda.sp_auto:maxres_2160p

Reproducción de video HLS con hls.js

La reproducción nativa de HLS funciona sin una biblioteca de JavaScript en Safari para macOS e iOS. Firefox y Chrome en escritorio anteriores a la versión 142 requieren un reproductor que implemente HLS en JavaScript, e incluso en versiones más recientes de Chrome, la reproducción nativa no es totalmente fiable en todos los flujos. La opción más segura entre navegadores es hls.js.

Un componente de cliente que utiliza hls.js con una alternativa HLS nativa:

'use client'

import { useEffect, useRef } from 'react'

type HlsVideoProps = { src: string }

export function HlsVideo({ src }: HlsVideoProps) {
  const videoRef = useRef<HTMLVideoElement>(null)

  useEffect(() => {
    const video = videoRef.current
    if (!video) return

  if (
  video.canPlayType('application/vnd.apple.mpegurl') &&
  'ManagedMediaSource' in window
) {
  // Safari on macOS and iOS: ManagedMediaSource is the reliable signal for
  // stable native HLS. Chrome 147+ also reports canPlayType support but
  // may fail on certain CMAF streams.
  video.src = src
} else {
  // Chrome, Firefox, Edge, and other browsers: load hls.js dynamically
  // to keep the initial bundle small.
  import('hls.js').then(({ default: Hls }) => {
    if (!Hls.isSupported()) return
    const hls = new Hls()
    hls.loadSource(src)
    hls.attachMedia(video)
    return () => hls.destroy()
  })
}
  }, [src])

  return <video ref={videoRef} controls width={1280} height={720} />
}

Instala hls.js con npm install hls.js. El import('hls.js') dinámico dentro del efecto lo mantiene fuera del paquete inicial, cargándolo solo cuando el navegador lo necesita. La comprobación canPlayType asegura que Safari utilice su reproductor integrado.

Este patrón funciona de forma fiable en Safari, iOS, Chrome, Firefox y Edge en implementaciones de Webflow Cloud. La comprobación ManagedMediaSource es la clave: sin ella, Chrome 147 y versiones posteriores indican incorrectamente que están listos para HLS nativo mediante canPlayType, pero pueden fallar con ciertos flujos CMAF.

¿Qué causa que la transcodificación de video de Cloudinary falle en Webflow Cloud?

La mayoría de los fallos en esta integración provienen de cuatro causas: el SDK de Node.js de Cloudinary importa módulos principales que el entorno de ejecución de Workers no admite, la transcodificación "eager" devuelve un 423 antes de que el procesamiento finalice, un ajuste preestablecido de carga configurado en modo "Signed" en lugar de "Unsigned", y archivos de video que superan el límite del cuerpo de la solicitud del entorno de ejecución antes de llegar a Cloudinary.

Cada problema a continuación relaciona el síntoma que verás con su solución específica.

El SDK de Node.js de Cloudinary arroja un error de compilación o de ejecución

El síntoma es un error en el registro de compilación que dice Could not resolve 'http' o Unexpected external import of 'http', o una entrada Worker threw a JavaScript exception en los registros de implementación.

El SDK de Node.js de Cloudinary realiza importaciones desde node:http y node:https para su transporte HTTP. Estos módulos no están totalmente disponibles en todas las implementaciones de Webflow Cloud, y cualquier método del SDK que active una solicitud HTTP puede fallar durante la ejecución.

La solución es eliminar el SDK y reemplazarlo con llamadas directas fetch a la API REST de Cloudinary, tal como demuestra el controlador de ruta en el paso 4. Cada operación que expone el SDK, incluyendo la carga, la generación de URL de transformación, la gestión de activos y las solicitudes firmadas, tiene un equivalente directo en REST.

No se pierde ninguna funcionalidad al cambiar a fetch. Si necesitas ejecutar operaciones por lotes basadas en el SDK o scripts de migración, hazlo fuera de Webflow Cloud en un entorno estándar de Node.js donde el SDK funcione sin problemas.

La transcodificación "eager" devuelve un 423 en la primera solicitud de entrega

Un código de estado 423 de Cloudinary significa que el recurso existe, pero la transformación solicitada aún no ha terminado de procesarse. Esto ocurre cuando se solicita una URL de entrega antes de que finalice el trabajo de transformación asíncrona.

Con el procesamiento asíncrono habilitado en el ajuste preestablecido de carga, Cloudinary pone en cola el trabajo de transcodificación después de la carga y devuelve la URL del video original inmediatamente. Si una solicitud de entrega llega a la URL de transformación HLS o MP4 antes de que el trabajo termine, Cloudinary devuelve un 423.

Existen dos enfoques limpios:

(1) El primero consiste en pasar un eager_notification_url en el FormData de carga que apunte a un controlador de rutas (Route Handler) de webhook en tu aplicación de Webflow Cloud. Cloudinary llama a ese endpoint cuando todas las transformaciones inmediatas (eager transforms) se han completado.

Tu aplicación marca entonces el vídeo como listo en el CMS de Webflow, en un almacén KV o en una base de datos, y el reproductor solo muestra la URL HLS una vez que el estado cambia a listo. Para aplicaciones que también necesiten actualizaciones de estado en tiempo real, el enfoque en una aplicación serverless con Neon y Webflow Cloud puede adaptarse para persistir la información del estado de transcodificación.

(2) El segundo enfoque consiste en entregar el vídeo original sin procesar utilizando la secure_url de la respuesta de carga como alternativa inmediata, y luego cambiar a la URL HLS una vez que el trabajo inmediato se complete.

El controlador de rutas de carga devuelve un error 400 con un preset de carga

El síntoma es una respuesta 400 de Cloudinary con un mensaje de error indicando que no se encontró el preset de carga o que falta una firma. Esto casi siempre se debe a una de estas dos razones: el nombre del preset de carga en CLOUDINARY_VIDEO_UPLOAD_PRESET no coincide exactamente con el nombre en la configuración de Cloudinary, o el modo de firma del preset está configurado como "Signed" (firmado) en lugar de "Unsigned" (sin firmar).

Abre la configuración de Cloudinary, ve a "Upload" y luego a "Upload presets", y confirma que el modo de firma sea "Unsigned". Si aparece como "Signed", edita el preset, cambia el modo a "Unsigned" y guarda los cambios. Luego, confirma que el nombre del preset en tu variable de entorno coincida carácter por carácter con el nombre de la lista, incluyendo guiones bajos, guiones y mayúsculas o minúsculas.

Copia el nombre del preset directamente desde el panel de control de Cloudinary en lugar de escribirlo. Vuelve a probar la carga después de realizar ambas correcciones.

Los archivos de vídeo grandes fallan antes de llegar a Cloudinary

El síntoma es una respuesta 413 o un reinicio de conexión al cargar un vídeo a través del controlador de rutas, sin que aparezca ningún error o registro de carga en la biblioteca multimedia de Cloudinary. Esto no es un error de Cloudinary.

El entorno de ejecución de Webflow Cloud impone un límite de tamaño al cuerpo de la solicitud, y las solicitudes que lo superan son rechazadas antes de que se ejecute el controlador. Cloudinary nunca llega a recibir el archivo.

Para aplicaciones en producción que manejan vídeos de larga duración, el patrón correcto es la carga directa desde el navegador: el navegador llama directamente a la API de carga de Cloudinary con el preset sin firmar, evitando el controlador de rutas para la transferencia del archivo.

Las transformaciones inmediatas del preset siguen aplicándose y la canalización de transcodificación no cambia. El controlador de rutas del paso 4 se utiliza entonces solo para archivos más pequeños o como capa de coordinación para metadatos. Nuestra guía sobre el envío de correos electrónicos transaccionales y SMS cubre un patrón relacionado de cómo desviar operaciones pesadas fuera del controlador de rutas perimetral para mantenerse dentro de los límites del entorno de ejecución.

Empieza a ofrecer vídeo de calidad profesional en Webflow Cloud

El vídeo es uno de los tipos de contenido con mayor impacto en páginas de producto y sitios de marketing, pero solo funciona bien cuando se carga rápidamente, se adapta al ancho de banda del espectador y no sobrecarga tu servidor.

La configuración de esta guía maneja los tres aspectos: Cloudinary aloja y transcodifica el vídeo, las transformaciones inmediatas generan previamente cada formato antes de que llegue el primer espectador, y tu aplicación de Webflow Cloud solo genera URLs, sin que los bytes de vídeo pasen por el entorno de ejecución perimetral.

Explora Webflow + Cloudinary para obtener plantillas de entrega, parámetros de transformación basados en URL y patrones de integración adicionales más allá de lo que cubre esta guía.

Si estás añadiendo observabilidad mientras lanzas funciones de vídeo, añadir el seguimiento de errores de Sentry a una aplicación de Webflow Cloud muestra cómo capturar fallos de carga y errores del reproductor en producción antes de que afecten a los usuarios a gran escala.

Y para los equipos que están creando un panel de control en tiempo real con Supabase y Webflow Cloud para realizar un seguimiento de las visualizaciones de vídeo, el estado de carga o las métricas de interacción, las notificaciones de webhook de Cloudinary para la finalización de transformaciones inmediatas pueden alimentar esa canalización utilizando los mismos patrones de controlador de rutas de esta guía.