How to Host Online Courses

Hosting a course is really two problems wearing one name. There is the course itself — lessons, ordering, enrolment, progress, assessment, the thing a student signs into — and there is the video, which has to be stored, processed, delivered and played back on whatever connection and device the student happens to have. Almost every decision that feels difficult comes from treating those two as one purchase.

There are two shapes that work. You can buy one product that covers the whole thing, or you can run your own site or LMS and give the video to a service built for it. This article is about choosing between them honestly, and then about what the second one looks like in practice.

The two shapes

An all-in-one course platform owns the whole chain: authoring, enrolment, student identity, payments, the student interface and video delivery. You get one vendor, one bill and one support line, and you can be selling in days. In exchange, you work inside its model of what a course is — and if your model matches, that constraint costs you nothing at all.

The assembled shape puts the course in a site or LMS you control — WordPress with an LMS plugin, a hosted LMS, or something your team wrote — and puts the video with a hosting service. You decide the model, the branding, where the student data lives and which payment path you use. In exchange, you own the integration between the pieces, and you own it permanently, not just on launch day.

The questions that actually decide it

• How unusual is your course model? Cohorts, prerequisites, graded assessment, accreditation, compliance reporting or an unusual enrolment flow are the things that either fit a platform or fight it. Sequential video lessons fit almost anywhere.
• Who owns the student relationship and the data? If you need the list, the records and the analytics under your own control — or a regulator does — that pushes toward the assembled shape.
• What already exists? An audience, a site, an LMS or a working payment setup changes the arithmetic completely. Replacing a working system is a real cost that never appears on a pricing page.
• Who is on the hook when a lesson will not play? With one vendor the answer is obvious. With an assembled stack the answer has to be a person on your side who can tell a hosting problem from an LMS problem.
• What does leaving look like? Ask, before you commit, how you export your content, your student records and your revenue relationships. That answer is worth more than most feature comparisons.
• What are the total costs at your real volume? Video delivery scales with watch time; most other components scale with students. Those two grow at different rates, so the cheaper option at a hundred students is not always the cheaper option at ten thousand.
• Who maintains it? An assembled stack needs someone who can update plugins, renew certificates and re-test the embed after a platform release. If nobody has that time, the platform buys it for you.

If most of those answers point at "standard course, small team, want to sell this quarter", an all-in-one platform is a good decision, not a compromise. If they point at "our model is specific, we have a site and an audience, and we intend to keep the data", assemble it — and read on, because the video is the part people underestimate.

What a video host is responsible for

DynTube is the video layer. You upload a source file, it is processed into adaptive renditions, and it is delivered and played back through a player you embed wherever your lessons live. Playback engagement is reported back so you can see what is actually being watched.

It is worth being equally clear about what that does not include. DynTube is not, by itself, your LMS. It is not a course-authoring tool, it does not build your website or your mobile app, it is not the payment processor, it is not your identity provider, and it does not supply the whole student experience. Those are real jobs, and hosting the video does not do them for you.

Some of them can be covered by DynTube features rather than by your LMS, and this is where the boundary is genuinely blurry. Depending on your plan and how the account is configured, DynTube can also provide:

• Members and plans as an access layer. A plan describes the set of content a member may play; your own backend creates the member, attaches the plan when someone becomes entitled, and removes it when they stop being entitled. DynTube does not operate a consumer checkout, does not collect money from your students and does not run recurring billing — the offer, the payment and the customer record stay in your system.
• Login protection on a video or as a project default, so playback requires a signed-in member. Authentication and plan coverage are separate: a video that requires login but is not covered by any plan is closed to everyone, including the students you meant to let in.
• Playback restricted to the domains you allow-list on the project, so an iframe lifted out of a lesson page does not play somewhere else.
• Viewer attribution: pass your own identifier as a userId parameter on the page or iframe URL, and DynTube reports that engagement against your identifier in its own analytics rather than against an anonymous session. It does not read or write anything in your LMS.

A practical workflow

1. Decide the shape first. Everything below assumes you are assembling, with the course in your own site or LMS.
2. Create the project for the course library first, and set its video options — including encryption and the domains allowed to play — before anything is uploaded. Settings are per project, not per video, and a video does not pick up another project's rules if you move it later without re-checking them. Saving a project's video options also rewrites the published videos in it, so do that deliberately.
3. Upload the best source file you have, and wait until it reports Ready. Processing can only produce renditions the source can support; it cannot add detail that was never recorded, so the master, not the export you already compressed for someone else, is what to upload. A video can be renamed, described and given a thumbnail while it is still processing; it simply cannot be played yet.
4. Copy the iframe from that video's Embed dialog — the snippet marked Recommended, wrapper div included — and paste it into the lesson in your own site or LMS. In WordPress and LearnDash that means a Custom HTML block: a paragraph or rich-text field sanitises the iframe away on save, and only users holding the unfiltered_html capability keep raw HTML at all.
5. Keep the two gates straight. Your LMS decides who reaches the lesson or page — that is what LearnDash is doing — and the project's playback rules decide who can play the video. They are separate: LearnDash enrolment alone does not stop a copied iframe playing elsewhere, and login protection alone grants nobody access until a plan's access scope covers the video.
6. If you need engagement tied to a student, pass your own identifier as the userId parameter on the page or iframe URL, and read it back in DynTube analytics.
7. Verify as a student, not as an admin. Sign in as a real enrolled account, on a phone on mobile data as well as a desktop, and play a lesson from the middle of the course, not just the first one.
8. Check the current pricing page before you model costs. Storage, delivery and features are priced there, and that page is current in a way a blog post cannot be.

The exact steps for each of those live in the documentation, and the members-and-plans boundary — what your backend owns and what DynTube owns — is set out in full on the video subscriptions page:

• How to upload and embed videos — /docs/videos/how-to-upload-and-embed-videos
• How to embed DynTube videos in LearnDash — /docs/tips-and-tricks/how-to-embed-dyntube-videos-in-learndash
• How to embed a DynTube video channel in WordPress LearnDash — /docs/tips-and-tricks/how-to-embed-dyntube-video-channel-in-wordpress-learndash
• How to add login protection on my videos — /docs/security/how-to-add-login-protection-on-my-videos
• Tracking video viewers with custom user IDs and emails — /docs/videos/tracking-video-viewers-with-custom-user-ids-emails
• How video subscriptions work, and where the seam sits — /video-subscriptions

Layer protection around the course experience

Course video is worth stealing, so this question comes up early. Depending on your plan and configuration, DynTube can encrypt HLS delivery so segments are useless without a key request, restrict playback to domains you allow-list, harden the key request against download tooling, overlay an animated shield intended to deter screen capture, and draw a per-viewer watermark overlay — optionally carrying the viewer's IP — over the video while it plays.

Use each control for a specific job. Encryption protects delivered segments, approved origins keep browser playback on the sites you configure, your LMS or application decides which enrolled learner reaches the lesson, and managed links bound direct sharing. A per-viewer watermark is drawn during playback to discourage redistribution and help an investigation connect a capture with the viewing session. Test the complete learner journey with representative course content before publishing the full library.

The short version

Pick the shape that matches your course model and your team, not the one that sounds more independent. If you assemble, keep the boundary clean: your site or LMS owns the course, the enrolment and the student, and the video host owns storage, processing, delivery and playback. Get that boundary right and both halves are replaceable later, which is the real thing you are buying.