Skip to main content
A production media system should separate the public API from CPU-heavy processing. Deploy the API as a Springwinter Web server and deploy FFmpeg consumers as Springwinter Workers. Updated October 9, 2026. Do not proxy multi-gigabyte uploads or long transcodes through an HTTP request. Upload to S3 and process asynchronously.

​
Request flow

  1. The client requests an upload session.
  2. The API validates file type, size, tenant quota, and intended operation.
  3. The API returns a short-lived S3 signed upload URL.
  4. The client uploads directly to private S3 storage.
  5. The API or object event creates a durable processing job.
  6. A Worker transforms the media and writes outputs to S3.
  7. The client polls a status endpoint or receives a webhook.
  8. The API returns a signed download or CloudFront URL.
This design keeps request latency predictable and prevents web containers from becoming temporary file servers.

​
Deploy the API

Use a Springwinter Web server with a health endpoint and stateless handlers. Store job records in a database. Keep S3 object keys opaque and scoped by organization or project. Recommended endpoints include:
Return 202 Accepted when processing begins. Do not hold the request open until FFmpeg finishes.

​
Deploy processing Workers

Use a separate Springwinter Worker per resource profile when workloads differ significantly. Thumbnail extraction, audio normalization, and 4K transcoding should not necessarily share one queue or compute size. Workers should use an allowlist of operation profiles. Validate media with ffprobe, enforce maximum duration and resolution, use execution timeouts, and delete temporary files after upload.

​
Security controls

  • Keep buckets private.
  • Use short signed-URL expirations.
  • Validate actual media, not only filename extensions.
  • Apply tenant quotas before accepting uploads.
  • Never interpolate user input into a shell command.
  • Treat parsers and codecs as attack surfaces and patch images regularly.
  • Restrict outbound network access when the workload does not need it.

​
Streaming is a different workload

This architecture covers upload, processing, and delivery. Real-time WebRTC, RTMP ingest, UDP media, TURN, and long-lived bidirectional sessions require specialized networking. Current Springwinter Web servers target ordinary HTTP services and are not a first-class real-time media-server product.

​
Frequently asked questions

Direct upload removes large request bodies from the API, avoids duplicate network transfer through the web container, and gives retries a durable destination independent of a deployment.
Usually no. Keep S3 private and issue signed URLs or use CloudFront with private-origin controls. Public buckets make authorization, revocation, and audit harder.
Not as a current first-class workload. WebRTC commonly needs UDP, TURN, multiple ports, stable session routing, and specialized load balancing beyond the standard Springwinter HTTP Web server model.

​
Sources and further reading

Last modified on October 8, 2026