If you are building any content site around frequently changing data, most of this applies directly.

1. Start With What the Visitor Wants

Before choosing tools, I wrote down the three things a visitor wants when they search for the Bojangles menu with prices 2026:

1. See the items and prices fast, usually on a phone.

2. Trust that the numbers are reasonably current.

3. Compare options (combos, sizes, categories) without hunting.

Every later decision, from layout to caching, comes back to these three.

2. Choose a Simple Architecture

For content like this, you do not need a heavy stack. The main options are:

• Static site generator: fastest, cheapest and easiest to keep secure. Great when data changes weekly, not minute by minute.

• CMS such as WordPress: easier for non-developers to edit, but needs care around plugins, caching and page weight.

• Custom app with a database: flexible, but usually overkill for a price reference site.

Whichever you choose, keep prices in one structured source (a spreadsheet, JSON file or database table) so pages are generated from data instead of hand-edited.

3. Model the Menu Data

A clean data model makes everything else easier:

{
  "category": "Chicken Combos",
  "items": [
    {
      "name": "Example Combo",
      "price_low": 7.49,
      "price_high": 9.99,
      "last_checked": "2026-10-01"
    }
  ]
}

I store a price range and a last checked date instead of a single number. Prices differ by location and franchise, so a range is more honest, and the date tells visitors how fresh the information is.

4. Use Semantic HTML for the Page

Search engines and screen readers both rely on structure. For price data, use real tables with a caption and headers:

<table>
  <caption>Chicken combos: typical price range</caption>
  <thead>
    <tr><th>Item</th><th>Price range</th></tr>
  </thead>
  <tbody>
    <tr><td>Example Combo</td><td>$7.49 - $9.99</td></tr>
  </tbody>
</table>

Add one clear <h1>, logical <h2> sections per category, and wrap wide tables in a container with overflow-x: auto so they scroll cleanly on small screens.

5. Add Structured Data (Carefully)

Schema.org has types for menus, which can help search engines understand your content:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Menu",
  "name": "Example Chicken Combos",
  "hasMenuSection": {
    "@type": "MenuSection",
    "name": "Chicken Combos",
    "hasMenuItem": {
      "@type": "MenuItem",
      "name": "Example Combo",
      "offers": {
        "@type": "Offer",
        "price": "7.49",
        "priceCurrency": "USD"
      }
    }
  }
}
</script>

Two honest caveats. First, structured data does not guarantee a rich result, so treat it as clarity for crawlers rather than a ranking trick. Second, only mark up what is actually visible on the page, and keep it in sync with your data. Mismatched markup does more harm than none.

6. Performance Is Part of the Product

Most visitors arrive on a phone, often while deciding where to eat. Practical wins:

• Compress images and set explicit width and height to avoid layout shift

• Lazy-load images below the fold

• Keep JavaScript minimal, since a price table needs almost none

• Serve fonts efficiently or use system fonts

• Cache aggressively, since pages change rarely

Test with Lighthouse and PageSpeed Insights, and focus on real-world mobile results rather than a perfect lab score.

7. Build Trust Into the Content

For a site about prices, trust is the whole point:

• Show a visible last updated date

• Say clearly that prices vary by location

• Point visitors to the official app or website to confirm

• Add short, genuinely useful context around the tables, such as value tips and combo comparisons

Content that only repeats a table is thin. Content that helps someone decide is useful.

8. Internal Linking and Site Structure

Group pages into clear topics (category pages, a main menu overview, a short FAQ) and link between them with descriptive anchor text. This helps visitors move around and helps crawlers understand how your pages relate.

9. Measure What Actually Happens

After launch:

1. Verify the site in Google Search Console and submit your sitemap.

2. Watch which queries bring impressions, then improve those pages.

3. Check mobile usability and Core Web Vitals reports.

4. Review pages quarterly and update prices and dates.

Rankings take time, and the useful signal early on is whether impressions and clicks are slowly growing, not whether you hit page one in a week.

Launch Checklist

• [ ] Prices stored in one data source

• [ ] Real HTML tables with captions

• [ ] Unique title and meta description on every page

• [ ] Visible update date and location disclaimer

• [ ] Sitemap submitted and site verified

• [ ] Mobile speed tested

• [ ] Structured data matches visible content

Conclusion

A menu price website is a small project with real engineering behind it: clean data, semantic markup, fast pages and honest content. None of it is exotic, but doing all of it consistently is what separates a useful reference from a thin one.

You can see how I applied these ideas in practice on the Bojangles menu with prices pages at bojanglesprice.com.

What is the most useful thing you have learned from building a data-driven content site? Let me know in the comments.

Here is what worked, in case you are building a similar data-heavy site.

The Goal

Visitors searching for the Carl's Jr menu with prices 2026 usually want one thing: a quick, accurate answer on their phone. That means the page has to load fast, show a clean table, and answer common questions without scrolling forever.

1. Use Real Tables for Price Data

It is tempting to build price lists with styled div elements. A real table is better for accessibility and for search engines, because the relationship between item, category and price is clear.

<table>
  <caption>Burgers: typical price range</caption>
  <thead>
    <tr><th>Item</th><th>Price range</th></tr>
  </thead>
  <tbody>
    <tr><td>Example burger</td><td>$5 - $9</td></tr>
  </tbody>
</table>

2. Add FAQ Structured Data

Common questions (like whether prices differ by location) can be marked up with JSON-LD so search engines understand them:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Are Carl's Jr. prices the same everywhere?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "No. Prices vary by city, state and franchise."
    }
  }]
}
</script>

Only mark up questions that are actually visible on the page. Hidden or mismatched FAQ markup can hurt more than help.

3. Fix the Mobile Basics

Most people check a menu while deciding where to eat, so mobile speed matters more than desktop polish:

• Compress and properly size images

• Use loading="lazy" for images below the fold

• Avoid heavy scripts that block rendering

• Keep layout stable so tables do not jump while loading

4. Show Freshness Honestly

Prices change, so I display an "updated" date on each page and remind readers to confirm in the official app. A guide to the Carl's Jr menu is only useful if visitors can trust it, and honest disclaimers build that trust.

Key Takeaways

1. Semantic HTML beats clever styling for data-heavy pages.

2. Structured data helps, but only when it matches visible content.

3. Mobile speed is a feature, not an afterthought.

4. Trust signals like update dates matter as much as design.

If you want to see how these ideas look in a real project, the finished pages are at carlsjrprices.com.

What is the biggest performance or SEO fix you have made on a content site? Share it in the comments.

Building a video streaming system that continues to perform when hundreds or thousands of users start watching at the same time is a very different problem.

A basic implementation might look like this:

User
  |
  v
Web Server
  |
  v
video.mp4

For a small application, this may be perfectly acceptable.

But as traffic increases, the architecture starts dealing with several challenges:

• large media files

• bandwidth consumption

• concurrent viewers

• buffering

• video transcoding

• multiple resolutions

• geographic latency

• storage capacity

• playback authorization

This article explores how to design a more scalable video delivery architecture using HLS, object storage, a CDN, background workers, and a web player.

Start by Separating the Application and Media Layers

One of the first architectural improvements is separating normal application traffic from media delivery.

Instead of:

             Web Server
                 |
     +-----------+-----------+
     |           |           |
    API       Database     Videos

consider:

                 User
                   |
          +--------+--------+
          |                 |
          v                 v
    Web Application      CDN
          |                 |
          v                 v
       Database         Video Storage

The application server handles:

authentication
authorization
metadata
business logic
API requests

The media infrastructure handles:

large video files
streaming
bandwidth
caching
video segments

This separation becomes increasingly useful as traffic grows.

Why Direct MP4 Delivery Can Become Limiting

An MP4 file can work well for many websites.

With HTTP Range Requests, a browser can request only a portion of the file:

Range: bytes=5000000-9999999

So direct MP4 delivery should not automatically be considered bad architecture.

However, streaming applications often need more flexibility.

Imagine a user on a 30 Mbps connection and another on a 2 Mbps mobile connection.

If both users receive the same high-bitrate video, the slower connection may experience repeated buffering.

This is where adaptive streaming becomes useful.

Enter HLS

HLS stands for HTTP Live Streaming.

Instead of treating a video as one large file, HLS uses playlists and smaller media segments.

A simplified structure might look like:

video/
├── master.m3u8
├── 1080p/
│   ├── playlist.m3u8
│   ├── segment001.ts
│   ├── segment002.ts
│   └── ...
├── 720p/
│   ├── playlist.m3u8
│   └── ...
└── 480p/
    ├── playlist.m3u8
    └── ...

The master playlist describes the available versions of the video.

A player can then select an appropriate stream.

Adaptive Bitrate Streaming

Suppose we encode three variants:

1080p -> 5 Mbps

720p  -> 2.5 Mbps

480p  -> 1 Mbps

A viewer with a fast connection may receive 1080p.

If network conditions become worse, the player can switch to 720p or 480p.

Conceptually:

Fast Network
     |
     v
   1080p

Network drops
     |
     v
    720p

Network drops again
     |
     v
    480p

The goal is not simply maximum image quality.

The goal is to balance quality and uninterrupted playback.

Build an Encoding Pipeline

Uploaded videos normally need processing before they become HLS streams.

A practical pipeline might be:

Upload
  |
  v
Original Storage
  |
  v
Queue
  |
  v
Encoding Worker
  |
  v
FFmpeg
  |
  +---- 1080p
  |
  +---- 720p
  |
  +---- 480p
  |
  v
HLS Packaging
  |
  v
Media Storage

The upload request should not wait for this entire process.

Instead:

POST /videos
      |
      v
Store original
      |
      v
Create processing job
      |
      v
Return 202 Accepted

The conversion happens asynchronously.

Track Processing State

A database record can represent the current video state.

For example:

{
  "id": 845,
  "status": "processing",
  "progress": 61
}

Useful states might include:

uploaded

queued

processing

ready

failed

The frontend can poll an API or receive updates through WebSockets.

Once the video becomes ready:

{
  "id": 845,
  "status": "ready",
  "playback_url": "/streams/845/master.m3u8"
}

Now the player can load the stream.

Don't Upscale Videos Unnecessarily

Before encoding, inspect the input.

FFprobe is useful:

ffprobe \
  -v quiet \
  -print_format json \
  -show_streams \
  -show_format \
  input.mp4

Suppose the input is only 720p.

Generating a 1080p version does not create additional real visual detail.

A better ladder could be:

4K Input
├── 1080p
├── 720p
└── 480p

1080p Input
├── 1080p
├── 720p
└── 480p

720p Input
├── 720p
└── 480p

This avoids unnecessary processing and storage.

Object Storage Is a Natural Fit

Media files can consume enormous amounts of disk space.

Instead of keeping every video on the application server:

Web Server
└── 10 TB videos

we can separate them:

Web Application
      |
      v
   Metadata DB

Object Storage
      |
      +--- originals
      |
      +--- HLS
      |
      +--- thumbnails

The application database only needs references to the objects.

For example:

{
  "video_id": 845,
  "master_playlist":
    "videos/845/hls/master.m3u8",
  "thumbnail":
    "videos/845/thumb.webp"
}

This keeps the application layer much lighter.

Put a CDN in Front of Storage

Serving every HLS segment directly from origin storage can generate a huge number of origin requests.

Consider a 30-minute video divided into 6-second segments:

30 minutes
=
1800 seconds

1800 / 6
=
300 segments

One viewer may request hundreds of objects.

Now multiply that by thousands of viewers.

A CDN can cache frequently requested segments closer to users.

              Origin
                |
                v
               CDN
          /      |      \
         /       |       \
        v        v        v
      User     User      User

If multiple users request the same segment, the CDN may serve cached copies rather than repeatedly contacting the origin.

Cache Immutable Segments Aggressively

HLS VOD segments generally do not change after encoding.

That makes them good caching candidates.

Conceptually:

Cache-Control:
public, max-age=31536000, immutable

Whether this exact policy is appropriate depends on your URL/versioning strategy.

The important idea is that immutable media objects can usually use long cache lifetimes.

Use Unique Paths for New Encodes

Suppose you replace a video's encoding but keep:

/video/845/segment001.ts

A CDN may still have the old object cached.

A safer approach can be versioned paths:

/video/845/v1/segment001.ts

/video/845/v2/segment001.ts

Now new media receives a new URL.

This reduces cache invalidation problems.

Keep the Player Independent of Storage

The frontend should not need to understand the internal storage provider.

Instead of returning:

bucket-name.internal-provider.example/...

return a stable playback URL:

{
  "playback_url":
    "https://media.example.com/v/845/master.m3u8"
}

Now the backend infrastructure can change:

Local Storage
      ↓
Object Storage A
      ↓
Object Storage B

without requiring major frontend changes.

HLS Playback in the Browser

Safari supports HLS natively.

Other modern browsers can commonly use hls.js.

A basic implementation:

import Hls from 'hls.js';

const video =
    document.querySelector('#player');

const source =
    'https://media.example.com/v/845/master.m3u8';

if (Hls.isSupported()) {

    const hls = new Hls();

    hls.loadSource(source);
    hls.attachMedia(video);

} else if (
    video.canPlayType(
        'application/vnd.apple.mpegurl'
    )
) {

    video.src = source;

}

This provides a basic cross-browser strategy.

Startup Time Matters

A streaming system can technically work and still feel slow.

One of the most noticeable metrics is startup time:

User clicks Play
       |
       v
Manifest request
       |
       v
Segments requested
       |
       v
Enough buffer
       |
       v
First frame

If this takes several seconds, users notice.

Useful measurements include:

manifest latency

segment latency

time to first frame

buffer level

CDN cache hit ratio

Optimizing the player alone may not solve slow startup.

Segment Duration Is a Tradeoff

Suppose HLS segments are:

2 seconds

You get many small files and more HTTP requests.

With:

10 seconds

you get fewer, larger segments.

There is no universal perfect value.

The right choice depends on:

latency requirements

content type

CDN behavior

encoding setup

player behavior

For normal video-on-demand, several-second segments are a common starting point.

Measure rather than guessing.

Protect Private Streams

If a video is private, putting it on an obscure URL is not sufficient.

A better architecture is:

User
 |
 v
Authentication
 |
 v
Authorization
 |
 v
Temporary Playback Access
 |
 v
CDN
 |
 v
HLS

The backend checks whether the user can watch the video.

Only then does it issue temporary playback access.

Signed URLs and Tokens

A playback URL might include:

video ID
expiration
signature

For example:

/stream/845/master.m3u8
?expires=1786400000
&signature=...

The media layer verifies the request before serving content.

For private subscription services, temporary access is generally more useful than permanent public media URLs.

Protect More Than the Master Playlist

HLS consists of multiple resources.

master.m3u8
     |
     v
playlist.m3u8
     |
     v
segment001.ts
segment002.ts
segment003.ts

If only master.m3u8 is protected while all segments remain permanently public, the protection may be incomplete.

Access-control architecture should account for the entire media path.

Self-Hosted Streaming vs a Video Platform

Once we combine everything, our infrastructure includes:

Upload API

Queue

FFmpeg workers

Object storage

HLS packaging

CDN

Playback security

Player

Monitoring

Cleanup

For a product where video infrastructure is a core engineering competency, owning this stack may be worthwhile.

For other applications, developers can evaluate a dedicated video streaming platform such as FileMoon, alongside other available media infrastructure providers.

The architectural decision should be based on operational requirements rather than simply whether self-hosting is technically possible.

Ask:

Do we need custom encoding?

How much traffic do we expect?

Who manages storage?

Who manages CDN delivery?

How important is private playback?

How much engineering time can we spend on media infrastructure?

The answers determine whether building or outsourcing parts of the streaming stack makes more sense.

Monitor Playback, Not Just Servers

Traditional monitoring might tell you:

CPU = 45%

RAM = 62%

Server = online

But users may still be experiencing terrible video playback.

Streaming-specific metrics are also useful:

startup_time

buffering_count

buffering_duration

playback_errors

average_bitrate

watch_time

completion_rate

For example:

Server uptime:
99.99%

Average startup:
8.2 seconds

Technically the system is available.

From the user's perspective, it may still be poor.

Measure Buffer Ratio

A useful metric is:

buffer ratio
=
buffering duration
/
watch duration

Suppose:

Watch time:
600 seconds

Buffering:
30 seconds

Then:

30 / 600
=
5%

Tracking this across users, countries, ISPs, devices, and video qualities can reveal delivery problems.

Monitor the Encoding Queue

Playback is only one part of the system.

Upload-to-ready time matters too.

Suppose:

Upload completed:
10:00

Encoding started:
10:28

Video ready:
10:36

The encoding itself took only eight minutes.

But the user waited 36 minutes.

The real problem was queue delay.

Track:

queue_wait_time

encoding_time

total_processing_time

separately.

Avoid Unlimited Encoding Concurrency

A common scaling mistake is simply adding more FFmpeg processes.

Suppose one server has:

8 CPU cores

and you run:

8 simultaneous FFmpeg jobs

Each FFmpeg process may itself use multiple threads.

The result can be:

CPU saturation
      |
      v
slower encoding
      |
      v
longer queues
      |
      v
unstable server

Benchmark different concurrency levels.

More simultaneous jobs do not always mean higher total throughput.

Separate Worker Capacity From Web Capacity

A useful production architecture might be:

              Application
                   |
        +----------+----------+
        |                     |
        v                     v
    Web Servers             Queue
                              |
                  +-----------+-----------+
                  |                       |
                  v                       v
              Worker A                Worker B
                  |                       |
                  +-----------+-----------+
                              |
                              v
                          Storage
                              |
                              v
                             CDN

Now video processing can scale independently from API traffic.

If encoding demand increases, add worker capacity.

If website traffic increases, scale the web tier.

Design for Failure

Distributed video systems will eventually experience failures.

Examples:

upload interrupted

worker crashes

FFmpeg fails

storage request times out

CDN origin unavailable

database update fails

Jobs should be retryable where appropriate.

But retries should also be bounded.

For example:

Attempt 1
   |
 failure
   |
 wait 60 sec

Attempt 2
   |
 failure
   |
 wait 5 min

Attempt 3
   |
 failure
   |
 mark failed

Permanent errors should not consume worker capacity forever.

Clean Up Temporary Files

Encoding workers can generate large temporary files.

Always account for cleanup:

Download source
      |
      v
Encode
      |
      v
Upload result
      |
      v
Verify upload
      |
      v
Delete temporary files

Cleanup should run on success and failure.

Otherwise, a worker with hundreds of failed jobs can eventually run out of disk space.

A More Complete Architecture

Putting everything together:

                    Users
                      |
                      v
                  Application
                      |
          +-----------+-----------+
          |                       |
          v                       v
       Database                Upload
                                  |
                                  v
                           Original Storage
                                  |
                                  v
                                Queue
                                  |
                       +----------+----------+
                       |                     |
                       v                     v
                    Worker                Worker
                       |                     |
                       +----------+----------+
                                  |
                                  v
                               FFmpeg
                                  |
                                  v
                           HLS Variants
                                  |
                                  v
                           Object Storage
                                  |
                                  v
                                 CDN
                                  |
                                  v
                         Playback Security
                                  |
                                  v
                                Player
                                  |
                                  v
                                 User

Each layer has a clear responsibility.

Final Thoughts

A scalable video streaming system is much more than a <video> element.

As an application grows, the architecture may need to handle:

• asynchronous transcoding

• HLS packaging

• multiple qualities

• object storage

• CDN caching

• secure playback

• queue management

• monitoring

• failure recovery

But this does not mean every project should start with a complex distributed architecture.

For a small application:

MP4
+
Object Storage
+
CDN

may be enough.

As requirements grow:

Upload
↓
Queue
↓
FFmpeg
↓
HLS
↓
Storage
↓
CDN
↓
Player

can become the next stage.

The most important principle is separation of responsibilities.

Keep application logic, CPU-intensive processing, media storage, delivery, and playback loosely coupled.

Then each part of the system can evolve as the product grows instead of forcing the entire video stack to be rebuilt at once.

Serving a video that should only be available to a specific user, subscriber, customer, or organization introduces a different set of engineering problems.

A common first implementation looks like this:

<video controls>
    <source
        src="https://cdn.example.com/videos/course-101.mp4"
        type="video/mp4"
    >
</video>

The problem is not the <video> element.

The problem is that the media URL may be publicly accessible.

If someone copies that URL and shares it, your application-level permission checks may no longer matter.

In this article, we'll design a more practical architecture for private video delivery.

Start With the Threat Model

Before implementing security controls, define what you are trying to prevent.

For a subscription video application, common concerns might include:

Unauthorized users

Shared media URLs

Expired subscriptions

Automated scraping

Excessive account sharing

Permanent public links

Notice that "prevent anyone from ever copying a video" is not on the list.

If a legitimate user can watch media on a device, completely preventing capture is not a realistic browser security model.

The goal is to control access and make unauthorized reuse more difficult.

Authentication Is Not Authorization

These two concepts are often mixed together.

Authentication answers:

Who is the user?

Authorization answers:

Can this user watch this video?

A logged-in user should not automatically have access to every video.

A typical request flow might be:

User
 |
 v
Authentication
 |
 v
Video Request
 |
 v
Authorization
 |
 v
Playback Permission

Your backend should make the authorization decision.

A Simple Laravel Example

Suppose we have:

users
videos
subscriptions

A playback endpoint could look like:

Route::get(
    '/videos/{video}/play',
    [VideoPlaybackController::class, 'show']
)->middleware('auth');

Then:

public function show(
    Request $request,
    Video $video
) {
    $user = $request->user();

    if (! $user->can('view', $video)) {
        abort(403);
    }

    return response()->json([
        'playback_url' =>
            $this->createPlaybackUrl($video)
    ]);
}

The frontend never decides whether the user is allowed to watch the video.

It only requests permission from the backend.

Use Policies for Authorization

Laravel Policies can keep access rules out of controllers.

For example:

class VideoPolicy
{
    public function view(
        User $user,
        Video $video
    ): bool {
        if ($video->is_public) {
            return true;
        }

        return $user
            ->subscriptions()
            ->where('status', 'active')
            ->exists();
    }
}

Now the authorization logic is reusable.

$this->authorize(
    'view',
    $video
);

This becomes especially useful when access rules become more complicated.

Avoid Permanent Public Media URLs

Consider:

https://media.example.com/private/video-101/master.m3u8

If that URL works indefinitely for anyone, your application loses much of its control once the URL leaks.

A better model is temporary access.

For example:

https://media.example.com/play/video-101
?expires=1786400000
&signature=abc...

The URL works only until a particular time.

After that:

Request
  |
  v
Expiration Check
  |
  +--- valid ---> Video
  |
  +--- expired -> 403

This doesn't make copying impossible.

It limits how useful a leaked URL remains.

Signed URLs

A signed URL normally contains information that the server can verify.

Conceptually:

video_id
+
expiration
+
secret
=
signature

A simplified PHP example:

function createSignature(
    int $videoId,
    int $expires,
    string $secret
): string {
    return hash_hmac(
        'sha256',
        $videoId . ':' . $expires,
        $secret
    );
}

Generate an expiration time:

$expires = now()
    ->addMinutes(10)
    ->timestamp;

Then:

$signature = createSignature(
    $video->id,
    $expires,
    config('video.secret')
);

The media layer can verify the signature before allowing playback.

In production, use the signing implementation provided by your CDN, object storage, or media infrastructure where possible rather than inventing your own protocol.

Never Send Signing Secrets to the Browser

This would defeat the entire design:

const VIDEO_SECRET =
    'super-secret-key';

Anything sent to browser JavaScript should be treated as visible to the user.

The correct flow is:

Browser
   |
   | video ID
   v
Backend
   |
   | authorization
   |
   | signing secret
   v
Temporary Playback URL
   |
   v
Browser

The secret remains on trusted server infrastructure.

Short-Lived Playback Tokens

Instead of putting authorization data directly into a URL, another option is a short-lived token.

For example:

{
  "video_id": 101,
  "user_id": 42,
  "expires_at": 1786400000
}

The media server validates the token before delivering content.

The exact mechanism could involve:

JWT

opaque token

signed query parameters

CDN signed cookies

application session

Each approach has different tradeoffs.

The important principle is that playback permission should expire.

Protect HLS Playlists and Segments

With HLS, protecting only master.m3u8 may not be enough.

Consider:

master.m3u8
   |
   +--- 1080p/index.m3u8
   |       |
   |       +--- segment001.ts
   |       +--- segment002.ts
   |
   +--- 720p/index.m3u8
           |
           +--- segment001.ts

If the playlists require authorization but every segment is permanently public, someone who discovers the segment URLs may still request them directly.

Your security design needs to consider the complete delivery path.

Depending on the infrastructure, authorization might happen through:

signed CDN requests

signed cookies

tokenized paths

edge authorization

temporary URLs

Don't Treat Hidden URLs as Security

This is not access control:

const hiddenVideoUrl =
    '/secret-folder/x92hd82/video.mp4';

Neither is:

robots.txt

or disabling right-click.

Obscurity can make a URL less obvious, but it should not be the authorization layer.

Assume that a determined user can inspect browser network requests.

Separate Application and Video Responsibilities

A clean architecture could look like:

              User
                |
                v
        Web Application
                |
       Authentication
                |
       Authorization
                |
                v
        Playback Access
                |
                v
          Video Layer
                |
        +-------+-------+
        |               |
      Storage          CDN

The application answers:

Who is this user?

What can they watch?

The media layer answers:

How should the video be delivered efficiently?

Keeping these responsibilities separate makes the system easier to reason about.

Build the Video Layer or Use Dedicated Infrastructure?

A private video system can eventually require:

Upload handling
Storage
Transcoding
HLS packaging
CDN delivery
Signed playback
Expiration
Access control
Monitoring
Cleanup

If video infrastructure is central to the product, operating this stack yourself may make sense.

For applications where video is only one feature, developers may instead evaluate a dedicated secure video hosting service such as FileMoon or another media provider and keep authorization and application-specific business rules within their own backend.

The useful architectural question is not whether one approach is universally better.

It is which responsibilities your team actually needs to own.

Rate-Limit Playback Authorization

Suppose your application exposes:

POST /api/videos/101/playback-token

Without rate limiting, an authenticated account might generate huge numbers of tokens.

Laravel provides rate-limiting tools that can help control this.

Conceptually:

User
 |
 v
Rate Limit
 |
 v
Authorization
 |
 v
Generate Token

For example, you might limit how frequently a client can request fresh playback authorization.

The exact threshold should reflect your player behavior and expected user activity.

Log Important Playback Events

Security controls become much more useful when you can observe what is happening.

Useful events may include:

user_id

video_id

token_created_at

token_expires_at

authorization_result

IP address

user agent

playback request

Be deliberate about privacy and retention when collecting these fields.

The purpose is not to collect everything forever.

The purpose is to have enough visibility to investigate abuse and operational problems.

Detect Suspicious Patterns

Once useful events are available, you can look for patterns.

For example:

Account A

10:00 -> IP A
10:01 -> IP B
10:02 -> IP C
10:03 -> IP D

This does not automatically prove abuse.

Users can legitimately change networks or use VPNs.

But unusual activity can contribute to a risk signal.

Other patterns might include:

hundreds of playback tokens per minute

many simultaneous sessions

repeated authorization failures

extremely high playback volume

Avoid building aggressive blocking rules from one weak signal.

Combine context.

Subscription Expiration

Suppose a user has a subscription that expires at 12:00.

If you issue a playback URL valid for 24 hours at 11:59, that user may retain access long after the subscription ends.

A better expiration rule could be:

token expiration
=
min(
    default token lifetime,
    subscription expiration
)

For example:

$expiresAt = min(
    now()->addMinutes(15)->timestamp,
    $subscription->expires_at->timestamp
);

Now playback authorization cannot outlive the user's entitlement.

Revocation Is Harder Than Expiration

Short-lived tokens are useful because they naturally expire.

But what if access must be revoked immediately?

For example:

User account suspended

A stateless signed URL that remains valid for another hour may continue working.

Possible solutions include:

very short token lifetimes

server-side token records

revocation lists

edge authorization

session validation

Each adds operational complexity.

This is a tradeoff between performance, simplicity, and immediate control.

Domain Restrictions Are an Additional Layer

Some video systems allow playback to be restricted to specific domains.

For example:

Allowed:
app.example.com

Not expected:
random-site.example

This can help discourage simple hotlinking.

But it should not replace proper authentication and authorization.

Request headers are not a strong identity mechanism by themselves.

Think of domain restrictions as defense in depth.

CORS Is Not Video Authorization

CORS is frequently misunderstood.

Configuring:

Access-Control-Allow-Origin:
https://app.example.com

controls which browser origins can access certain responses through browser cross-origin rules.

It does not transform a public media URL into a securely authenticated resource.

Someone can still make requests outside normal browser JavaScript.

Use CORS for its intended browser security purpose, not as your primary media authorization system.

Consider Concurrent Session Limits Carefully

A subscription service may want to limit simultaneous playback.

You could maintain active playback sessions:

user_id
video_id
session_id
started_at
last_seen_at

Then apply a policy such as:

Maximum active sessions = 2

However, session tracking has edge cases:

browser crashes

device sleeps

network disconnects

user closes laptop

heartbeat request fails

So concurrent-session enforcement needs expiration and cleanup logic.

Player Heartbeats

One possible approach is a heartbeat.

Player
  |
  | every 30-60 seconds
  v
Playback API

The server updates:

last_seen_at

A session that hasn't sent a heartbeat for a defined period can be considered inactive.

This can also provide useful watch-time information.

But avoid extremely frequent heartbeats; they can create unnecessary backend load.

Security Is Layered

A practical private-video architecture may combine several controls:

Authentication
      |
      v
Authorization
      |
      v
Rate Limiting
      |
      v
Short-Lived Access
      |
      v
Media Delivery
      |
      v
Logging
      |
      v
Abuse Detection

No single feature solves every problem.

Signed URLs alone do not verify subscription logic.

Authentication alone does not protect a permanently public media URL.

Domain restrictions alone do not prove user identity.

Layering controls produces a stronger design.

Don't Promise Impossible Protection

A web application should avoid claims such as:

"This video can never be downloaded."

A legitimate viewer ultimately receives enough information to render the media.

A determined user may capture network traffic, use recording tools, or otherwise reproduce what is displayed.

The realistic goals are:

prevent unauthorized access

limit URL sharing

make access temporary

enforce subscriptions

reduce hotlinking

detect abuse

revoke access when practical

Those are engineering problems we can meaningfully address.

A Practical Final Architecture

A more mature system could look like:

                     User
                       |
                       v
                Authentication
                       |
                       v
                 Application
                       |
                  Authorization
                       |
                 Rate Limiting
                       |
                       v
              Playback Token API
                       |
                       v
                Signed Access
                       |
                       v
                    CDN
                       |
                       v
                HLS Playlist
                       |
                       v
                 HLS Segments
                       |
                       v
                    Player

                       |
                       v
                Access Logging

This keeps application-specific permission logic under your control while allowing the media delivery layer to focus on streaming.

Final Thoughts

Secure private video delivery is not about hiding an MP4 URL.

It is an authorization architecture.

Start with:

Authentication
+
Authorization

Then add controls according to the actual threat model:

short-lived playback URLs

signed requests

rate limiting

subscription-aware expiration

access logging

domain restrictions

session controls

And remember that browser-delivered video cannot be made impossible to capture.

The practical objective is to make sure the right users can access the right videos for the right amount of time, while keeping unauthorized access observable and difficult to reuse.

That is a much more useful definition of secure video streaming.

Processing that video reliably at scale is where things become more interesting.

A simple application may start with:

User
  |
  v
Laravel
  |
  v
video.mp4

This works when the application handles a few small videos.

But once users begin uploading larger files, several problems appear:

• HTTP requests can time out

• FFmpeg can consume significant CPU

• large uploads consume local disk space

• multiple conversions can overload the server

• failed jobs need retry logic

• users need to know whether a video is ready

• streaming a large MP4 is not always ideal

A more maintainable system separates uploading, processing, storage, and playback into different responsibilities.

In this article, we will design a practical Laravel video pipeline using queues, FFmpeg, HLS, and dedicated media infrastructure.

The Architecture

A reasonable starting architecture looks like this:

                 User
                   |
                   v
             Upload API
                   |
          +--------+--------+
          |                 |
          v                 v
     Original File      Database
                            |
                            v
                        Queue Job
                            |
                            v
                       FFmpeg Worker
                            |
                            v
                        HLS Output
                            |
                            v
                         Storage
                            |
                            v
                           CDN
                            |
                            v
                         Player

The most important principle is simple:

Do not make the web request responsible for the entire video-processing workflow.

Step 1: Accept the Upload

A simplified Laravel controller might look like this:

public function store(Request $request)
{
    $request->validate([
        'video' => [
            'required',
            'file',
            'mimetypes:video/mp4,video/quicktime'
        ]
    ]);

    $path = $request
        ->file('video')
        ->store('videos/originals');

    $video = Video::create([
        'source_path' => $path,
        'status' => 'pending',
    ]);

    ProcessVideo::dispatch($video->id);

    return response()->json([
        'id' => $video->id,
        'status' => 'pending'
    ], 202);
}

Notice that we are not running FFmpeg here.

The upload request performs only a few responsibilities:

1. validate the file

2. store the original

3. create a database record

4. dispatch a background job

5. return a response

The user does not need to keep the HTTP request open while the server processes the video.

Step 2: Track Processing State

Video processing is asynchronous, so the application needs to know what is happening.

A simple status model might be:

pending
processing
ready
failed

A database table could include:

Schema::create('videos', function (Blueprint $table) {
    $table->id();

    $table->string('source_path');

    $table->string('playback_path')
        ->nullable();

    $table->string('status')
        ->default('pending');

    $table->unsignedTinyInteger('progress')
        ->default(0);

    $table->text('error_message')
        ->nullable();

    $table->timestamps();
});

Now the frontend can request:

GET /api/videos/123

and receive:

{
  "id": 123,
  "status": "processing",
  "progress": 42
}

The UI can show a proper processing state instead of presenting a broken player.

Step 3: Process the Video in a Queue

Create a Laravel job:

php artisan make:job ProcessVideo

A simplified version:

class ProcessVideo implements ShouldQueue
{
    use Dispatchable;
    use InteractsWithQueue;
    use Queueable;
    use SerializesModels;

    public int $tries = 3;

    public function __construct(
        public int $videoId
    ) {
    }

    public function handle(): void
    {
        $video = Video::findOrFail(
            $this->videoId
        );

        $video->update([
            'status' => 'processing'
        ]);

        // FFmpeg processing
    }
}

Passing the ID instead of relying on a large serialized model also keeps the job payload simple.

Step 4: Inspect the File Before Encoding

Before running an expensive transcode, inspect the source with ffprobe.

Example:

ffprobe \
  -v quiet \
  -print_format json \
  -show_format \
  -show_streams \
  input.mp4

This can tell us:

duration
codec
width
height
bitrate
frame rate
audio streams

That information can influence the encoding pipeline.

For example, there is usually no reason to upscale a 720p source into 1080p.

A simple rule might be:

2160p source
  -> 1080p
  -> 720p
  -> 480p

1080p source
  -> 1080p
  -> 720p
  -> 480p

720p source
  -> 720p
  -> 480p

This saves processing time and storage.

Step 5: Generate HLS

For a basic test, FFmpeg can produce HLS output with:

ffmpeg \
  -i input.mp4 \
  -c:v libx264 \
  -c:a aac \
  -hls_time 6 \
  -hls_playlist_type vod \
  output.m3u8

This generates a playlist and smaller media segments.

Conceptually:

video-123/
├── playlist.m3u8
├── segment000.ts
├── segment001.ts
├── segment002.ts
└── ...

For adaptive bitrate streaming, the structure becomes more complex:

video-123/
├── master.m3u8
├── 1080p/
│   ├── playlist.m3u8
│   └── segments...
├── 720p/
│   ├── playlist.m3u8
│   └── segments...
└── 480p/
    ├── playlist.m3u8
    └── segments...

The player can then choose an appropriate quality based on network conditions.

Step 6: Execute FFmpeg Safely

Avoid constructing a shell command by concatenating raw user input.

Using Symfony Process is cleaner:

use Symfony\Component\Process\Process;

$process = new Process([
    'ffmpeg',
    '-y',
    '-i',
    $inputPath,
    '-c:v',
    'libx264',
    '-c:a',
    'aac',
    '-hls_time',
    '6',
    '-hls_playlist_type',
    'vod',
    $outputPath,
]);

$process->setTimeout(3600);

$process->run();

if (! $process->isSuccessful()) {
    throw new RuntimeException(
        $process->getErrorOutput()
    );
}

The job can then mark the video as ready:

$video->update([
    'status' => 'ready',
    'progress' => 100,
    'playback_path' => $relativePath
]);

Step 7: Handle Failures Properly

Encoding can fail for many reasons:

corrupt file
unsupported codec
disk full
timeout
FFmpeg crash
worker restart
storage failure

Do not leave the video permanently stuck in processing.

try {

    $this->encodeVideo($video);

    $video->update([
        'status' => 'ready',
        'progress' => 100,
    ]);

} catch (Throwable $e) {

    $video->update([
        'status' => 'failed',
        'error_message' => mb_substr(
            $e->getMessage(),
            0,
            5000
        )
    ]);

    throw $e;
}

Users and administrators can now distinguish a failed conversion from one that is simply still running.

Retry With Backoff

Laravel jobs support retry strategies.

public int $tries = 3;

public function backoff(): array
{
    return [
        60,
        300,
        900
    ];
}

That gives us:

Failure
  |
  v
Wait 60 seconds
  |
Retry
  |
  v
Wait 300 seconds
  |
Retry

But not every error should be retried.

A temporary storage error may succeed later.

A corrupt input file probably will not.

Production systems should eventually classify retryable and permanent failures separately.

Step 8: Keep Heavy Processing Away From the Web Server

At first, the queue worker may run on the same machine:

Server
├── nginx
├── PHP-FPM
├── Database
└── FFmpeg Worker

This is easy to operate.

As traffic grows, FFmpeg becomes a noisy neighbor.

A more scalable architecture is:

Web Server
├── nginx
└── PHP-FPM

Worker Server
├── Queue Worker
└── FFmpeg

Storage
└── Video Files

Now CPU-intensive encoding does not directly compete with web requests.

Be Careful With Worker Concurrency

More workers do not automatically mean more throughput.

Imagine an 8-core server running:

Worker 1 -> FFmpeg
Worker 2 -> FFmpeg
Worker 3 -> FFmpeg
Worker 4 -> FFmpeg
Worker 5 -> FFmpeg
Worker 6 -> FFmpeg

FFmpeg itself can use multiple threads.

Running too many simultaneous jobs may result in:

CPU = 100%
load average increases
encoding slows down
web requests suffer

Start with conservative concurrency and measure.

For example:

2 FFmpeg jobs

may complete more reliably than six jobs fighting over the same CPU resources.

Step 9: Move Video Storage Out of the App Server

Video files grow quickly.

A better long-term model is:

Application Server
       |
       v
Metadata Database

Object Storage
       |
       +--- originals
       |
       +--- streams

The application server does not need to hold every media file locally.

Temporary local storage can still be useful during processing.

After encoding:

Local Temporary Files
       |
       v
Upload to Object Storage
       |
       v
Delete Temporary Files

Always clean up temporary data, even when a job fails.

Use finally for Cleanup

Example:

try {

    $this->processVideo();

} finally {

    $this->cleanupTemporaryFiles();
}

A forgotten temporary directory can eventually fill the entire worker disk.

Video processing systems need explicit storage lifecycle management.

Step 10: Keep Playback Infrastructure Abstract

The frontend should not need to know whether media is stored:

locally
on object storage
behind a CDN
on another media server

Have your backend return a playback URL:

{
  "id": 123,
  "title": "Example Video",
  "playback_url": "https://media.example.com/123/master.m3u8"
}

Then the frontend simply loads it.

async function loadVideo(id) {
  const response =
    await fetch(`/api/videos/${id}`);

  const data =
    await response.json();

  player.src =
    data.playback_url;
}

This abstraction allows the video layer to evolve without rewriting the frontend.

Build the Entire Pipeline or Use Dedicated Infrastructure?

At this point, notice how many components we have introduced:

Upload API
Database
Queue
FFprobe
FFmpeg
Workers
HLS
Object Storage
CDN
Cleanup
Monitoring
Retries

For applications where video infrastructure is core technology, building and operating this pipeline may make sense.

For applications where video is only one feature, maintaining the whole media stack may be unnecessary.

In that case, developers can also evaluate a dedicated video hosting platform such as FileMoon, or another media service, and keep their application focused on authentication, business logic, and user experience.

The architectural decision is not simply “self-hosted vs platform.”

The real question is:

Which parts of the video pipeline provide unique value to your application, and which parts are infrastructure you would rather not operate?

Step 11: Add Access Control

If videos are private or paid, avoid exposing permanent public URLs.

A better request flow is:

User
  |
  v
Authentication
  |
  v
Authorization
  |
  v
Playback Access
  |
  v
Video

Depending on the infrastructure, this might use:

signed URLs
expiring tokens
session validation
domain restrictions

Do not treat a hidden frontend URL as security.

Authorization should happen on trusted backend infrastructure.

Step 12: Monitor the Pipeline

A video system needs more than uptime monitoring.

Useful metrics include:

upload failures
queue wait time
encoding duration
failed jobs
CPU usage
memory usage
disk usage
output size
playback errors
startup time
buffering

Imagine the average queue wait grows from:

20 seconds
   ↓
5 minutes
   ↓
35 minutes

The player may still work perfectly, but users are waiting too long for uploaded videos to become ready.

That is an infrastructure problem worth detecting.

A Practical Final Architecture

A more mature version might look like:

                    User
                      |
                      v
                Web Application
                      |
          +-----------+-----------+
          |                       |
          v                       v
      Database                Upload API
                                  |
                                  v
                            Original Storage
                                  |
                                  v
                               Queue
                                  |
                       +----------+----------+
                       |                     |
                       v                     v
                   Worker 1              Worker 2
                       |                     |
                       +----------+----------+
                                  |
                                  v
                              FFmpeg
                                  |
                                  v
                              HLS Output
                                  |
                                  v
                           Object Storage
                                  |
                                  v
                                 CDN
                                  |
                                  v
                               Player

This gives every part of the system a clear responsibility.

Final Thoughts

A scalable video pipeline is not really an FFmpeg problem.

FFmpeg is only one component.

The difficult parts are usually:

• controlling asynchronous work

• managing CPU-intensive jobs

• tracking state

• handling failures

• managing storage lifecycle

• separating infrastructure responsibilities

• monitoring the user experience

Start with the simplest architecture that works.

For a small project:

MP4
+
Object Storage
+
CDN

may be enough.

When the product needs adaptive streaming and automated processing:

Upload
↓
Queue
↓
FFmpeg
↓
HLS
↓
Storage
↓
CDN

becomes a reasonable next step.

And when maintaining that pipeline starts consuming more engineering time than your actual product, it may be worth deciding whether the media infrastructure should remain an internal system at all.