Host Your Business Videos: When Dedicated Hosting Fits, and How the Workflow Works

Most businesses end up with video before they end up with a video strategy: a product demo, a webinar recording, a few explainers, a training module. The question that follows is not "which platform is best" but something narrower and more answerable — does this video need to live on a page we own, under rules we set, or is a public platform genuinely fine? Dedicated hosting is the answer to the first case only, and it is worth being honest about which case you are in before you move anything.

This article covers three things: the conditions under which dedicated hosting is the right call, the conditions under which it will not give you what you want, and the actual workflow from upload to verified playback. Where something depends on your plan, it says so rather than guessing on your behalf.

When dedicated video hosting is the right fit

The case for a hosting platform is structural rather than promotional. It is a fit when one or more of the following is true of your video, and it is worth checking them individually rather than accepting the category as a whole.

• The video belongs on pages you own — a product page, a members area, an intranet, a course, an app — rather than on somebody else's destination where the audience is theirs.
• Advertising you did not choose, recommendations for other people's content, or a third-party logo on the player would be unacceptable next to this material.
• Your team needs a repeatable upload-to-embed workflow that several people can run, rather than one person handling files by hand.
• Access needs bounding: playback restricted to the domains you list, encrypted on-demand delivery, signed links that expire, or access tied to a subscription your own system controls.
• You need aggregate evidence that playback is actually working and that people are watching to the end, rather than a public view counter.
• The video is part of your product — inside an application or a course — so uploads, organisation and access have to be driven from your own code.

Dedicated hosting is strongest when you already bring the audience and want playback to stay inside your own product, course or website. That keeps the brand, next action and viewer journey under your control while DynTube handles the media workflow.

Connect video hosting to the rest of your business workflow

DynTube supplies the video layer. Pair it with the systems that already own customer identity, enrolment, conversion and page-level search content so each source of data has a clear job.

• Use plays, watch time, completion and playback-quality reporting to improve the library. On Plus and larger plans, pass your own user identifier or email through the supported embed workflow when per-user video reporting is required.
• Connect player events with your own product analytics when you want to relate video engagement to a signup, sale, renewal or lesson milestone.
• Publish useful page copy, metadata and a crawlable embed around the video when organic discovery matters; the surrounding page continues to own the search intent.
• Layer encrypted delivery, approved origins and managed links around protected playback, then add viewer-specific watermarking where attribution is valuable.
• Confirm plan-entitled features such as certified DRM, dynamic or IP watermarking and player branding against the current plan before designing the rollout.
• For sensitive live events, confirm the stream and plan are eligible for HLS segment encryption and test that exact viewer path before broadcast.

The workflow, end to end

The mechanics are short, and the order is worth following: settling the project configuration before you upload avoids rework later, because several project settings apply to what is processed after they are saved rather than to what already exists.

1. Decide the project before you upload anything

The project is the first configuration an upload inherits: it carries the encryption and output settings a conversion is planned from, the restriction rules that apply to playback, and the default player configuration for the videos in it. A video is not locked to all of that — a video can carry its own player preset, which resolves video first, then project, then the account default — but the processing and protection decisions are taken at the project level, so the project is worth choosing before the first upload rather than after it.

Two behaviours make that sequencing matter. Encryption is read when a video is converted, so turning it on governs conversions that run after the save; already-converted output is not re-encrypted, and protecting an existing video means putting it through a fresh conversion. And a video moved to a different project changes the set of project settings it inherits — where the destination project overrides the restriction rules, its own allowed domains and country rules apply instead of the account defaults, so playback that worked before a move can be refused afterwards. Check access on a real page after moving anything protected. One further constraint is settled at this point too: a project uses one protection mode, and certified DRM and AES-128 are rejected together on the same project.

2. Upload the master, and let it process

Open the project, choose Upload and select the source file; several can be queued at once. Upload the highest-quality master you have, because the streaming versions are derived from it. Leave the page open until each upload reports that it has been received — closing the tab mid-transfer cancels that transfer.

The video then shows as processing while the streaming renditions and thumbnails are generated, and becomes ready when playback is available. How long that takes depends on the duration and resolution of the source and on how much is queued ahead of it, so plan around a status rather than around a number. You can rename, describe and re-thumbnail a video while it is still processing; it simply cannot be played yet.

If uploads should come from your application rather than by hand, that is the API's job: server-side upload from a URL or from a file, and browser-side upload through an HTML form, are all documented in the developer reference. That is the path to take if video is inside your product rather than beside it.

3. Embed it on your own page

Open the video in the dashboard, choose Embed, and copy the iframe snippet marked Recommended. It is generated for you with that video's embed key already filled in, and it is self-contained — no script to add, no initialisation step, nothing else required on the page. Paste it into your page, your CMS block or your course platform's embed field.

Paste the whole snippet, wrapper included. The outer div is what makes the embed responsive: it fills the width available and reserves a 16:9 box, while the iframe is pinned to all four of its sides. Drop the wrapper and the box has no height, because the iframe is absolutely positioned and has no size of its own. While you are there, change the title attribute to something that describes the video — screen readers announce it, and "Video" tells a listener nothing.

A JavaScript version is also offered. It is the same iframe plus a module script that attaches the player SDK so your own code can hold a reference to the player; take it when you need that reference, and take the plain iframe otherwise. Note that embedding a whole channel is a separate workflow with its own embed code — a video embed key cannot be used for it.

4. Verify it, including the failure you want

Verification is where a hosting decision is actually settled. Three checks, of which the second is the only direct evidence about your access rules.

1. Open the page on your own site and confirm playback starts.
2. If the video is protected, open the same embed from a domain that is not on your allowed list. It should fail to play. Note the precondition: an allowed-domains list that is empty applies no origin restriction at all, so this check is only meaningful once your domains are actually listed.
3. Open the page on a phone. The wrapper should scale to the column width without a horizontal scrollbar, keeping its 16:9 shape.

When something does not play, the table below lists possible causes to check. It is a subset of the documented failure modes; the upload and embed documentation carries the full list.

5. Read the aggregate reporting

Once real viewers are watching, the reporting available to you is aggregate: plays, watch seconds and completion rate per video, plus account-level audience, engagement, playback-quality and bandwidth views. Watch seconds against plays, and completion alongside both, is what separates a video people finish from a video people merely open — a play count on its own reports those two outcomes identically.

The quality and bandwidth views can help investigate whether a drop-off has a technical explanation, but they do not establish causation on their own — they narrow where to look rather than settle why. What the reporting will not do is tell you that the video worked commercially: it describes playback, not campaign success.

What only the live catalogue can tell you

Plans, prices, storage and delivery allowances, and which capabilities are included at which tier are catalogue data rendered by the pricing page from the current billing catalogue. This article deliberately names none of them: a second copy of a plan fact can go stale without anything signalling that it has, and a stale inclusion may not surface until a launch depends on it.

Two consequences for your evaluation. First, estimate your actual storage and monthly delivery from your own library and publishing rate, and compare those figures against the current catalogue rather than against a description of it. Second, if a specific entitlement is decisive — DRM, dynamic watermarking, player branding, a particular storage region — confirm it for your plan in writing before a launch depends on it. One further boundary worth knowing early: a branded video domain is a hosted-site entitlement rather than part of hosting or the player.

How to evaluate it properly

A feature comparison answers less than a small, real rehearsal of your own workload, run on the material you would actually publish.

1. Choose two or three representative videos and the actual pages they would live on — not a test clip on a blank page.
2. Create a project configured the way the real thing would be: the protection mode you would use, and the domains those pages are served from.
3. Upload the masters and wait for processing to complete, so you see the real turnaround rather than an estimate.
4. Embed them on the real pages, in the real CMS or course platform field, and check they survive that field intact.
5. Verify playback on the devices your audience actually uses, and confirm the embed refuses to play from an origin you did not list.
6. Let real viewers watch, then read the aggregate reporting and decide whether it answers the questions you would need it to answer.
7. Only then compare your measured storage and delivery against the current catalogue, and ask for anything entitlement-gated in writing.

If you want to run that rehearsal here, the free trial is the entry point: you create an account, confirm your email address, and the trial is then ready to activate. Run the seven steps above against your own material — the answer will be clearer than any comparison table.

Conclusion

Dedicated video hosting earns its place when the video needs to sit on pages you own, free of advertising and third-party branding, behind access rules you set, with a workflow your team can repeat and aggregate evidence that playback is working. It does not earn its place by being cheaper, easier or better for search — those were claims this article used to make and cannot support. Decide the project settings first, upload the master, verify both the playback you want and the refusal you want, read the aggregates for what they are, and take every plan fact from the live catalogue. That is a decision you can defend afterwards.