Why Orilla

Orilla brings media ingestion, processing, playback, and observation into one on-demand workflow. Your team can manage content in the dashboard, integrate it into a product through the API, and run the platform on its own infrastructure.

Start here if you are deciding how Orilla fits your application. For a working integration, publish your first video.

Own the workflow and its infrastructure

A media file needs more than an upload endpoint. It must finish processing, expose the right playback resources, and reach viewers under your access policy. Orilla connects those steps around an asset, with a dashboard for people and an API for applications.

The repository includes a deployment stack with the gateway, API and dashboard, processing and webhook workers, PostgreSQL, and SeaweedFS media storage. You choose the installation’s domains and operate its data and media services. The documentation and landing page can be published separately as static sites.

This makes Orilla useful when your team wants to keep the media workflow alongside the rest of its infrastructure and can operate the services behind it. Deploy Orilla explains the stack and configuration.

Use the dashboard and API together

An editor can upload a local file, import a media URL, review processing, attach subtitles, and share an asset in the dashboard. A backend can create and retrieve assets, manage playback IDs, and react to processing events through the TypeScript SDK.

Both paths work with the same environment’s content. You can begin with a manual publishing workflow and automate individual steps as your product needs them. Organizations, roles, and environments give teams a shared place to manage access.

Follow your first video in the dashboard for the manual path or the API quickstart for the backend path. The fundamentals explain the resources they share.

Choose how the player enters your product

Use an iframe when you want to place a ready video on a page. Use the React component or HTML element when your application needs to configure the player more directly. These surfaces share Orilla’s adaptive HLS player and support the ready resources associated with the content, including subtitles and alternate audio.

The workflow also accepts audio-only sources. Downloads are generated separately as MP4 or M4A; they have their own processing state and availability.

See player integration, track uploads, and current formats and limits. The SDK and player are currently built from the repository; their guides explain local installation.

Make publication an explicit decision

Asset management credentials and viewer access serve different purposes. Your backend keeps the credentials used to create and manage content. Viewers receive a playback ID and, for signed access, temporary authorization.

A public playback ID lets anyone with its link watch while that ID remains active. A signed playback ID lets your backend authorize playback with an expiration and claims. In the dashboard, creating a permanent public link requires an explicit action; opening Share & embed does not publish the asset.

Choose the policy for the content you are delivering. Access control covers signed links, restrictions, and revocation. Revocation cannot remove copies a viewer has already saved.

Understand playback and resource use

When collection is enabled, playback analytics help you investigate startup, buffering, errors, and engagement. Usage reports describe observed storage, delivery, and ingest. These are separate views: bytes delivered do not tell you how long someone watched.

The reports expose coverage and unknown values so you can distinguish a measured zero from missing observations. Use analytics to understand playback and Usage to examine resources and export CSV.

Plan for operating the service

Running Orilla means your team owns capacity planning, HTTPS and proxy configuration, updates, restorable backups, and monitoring. Workers need processing capacity and temporary disk space. Email recovery and notification destinations need their respective providers and keys. A CDN, redundancy, and availability planning depend on your deployment.

The included Compose stack starts one instance per service; validate it against your workload before relying on it. Check deployment responsibilities, supported formats and limits, and implementation status to understand the available workflows and their verification coverage.

Start with one video

For an existing installation, the API quickstart takes you from backend credentials to a ready asset and a public demo iframe. If you need an installation first, follow deployment. If your team already has dashboard access, follow the dashboard guide.