Introducing Transcodely Video Hosting

Until now, Transcodely was a video transcoding API. You pointed us at a file on S3, GCS, Azure, or any HTTP URL, we encoded it, and we wrote the renditions back to your bucket. You handled the CDN. You handled the player. You handled the signed URLs. It was a clean division of labor — and for developers who already had infrastructure, it was the right one.

Today, Transcodely ships a second product: Video Hosting. Enable it on an app, upload a file, and we handle everything from the bytes leaving the browser to the frames arriving in a player — transcoding, storage, CDN, signed delivery, embed code, analytics. All of it. Priced per GB stored and per GB delivered, with the same per-minute encoding rates you already know.

This post explains what shipped, why, and how to pick between the two products.

#Why two products instead of one

Every second founder I talk to wants one of two things. Either they already have S3 + CloudFront + a player integration and they just want transcoding that does not cost enterprise money — or they want to stop thinking about video infrastructure entirely and pay a metered bill.

The transcoding API serves the first group. It always has. It does not touch your storage, it does not force you onto our CDN, it does not care where the resulting bytes live. You keep ownership of the pipeline.

Video Hosting serves the second group. You do not need an S3 bucket. You do not need CloudFront. You do not need to integrate hls.js. You call three API methods and you get back a playback URL that works everywhere.

Both products run on the same transcoding engine, with the same presets, same quality tiers, and same per-minute rates. Hosting just adds the storage, delivery, and player layers on top.

#The three-call upload flow

The whole hosting API looks like this:

// 1. Get a presigned upload URL
const { video, uploadUrl } = await client.createUpload({
  filename: "demo.mp4",
  contentType: "video/mp4",
  sizeBytes: BigInt(file.size),
});

// 2. Upload the file directly to storage
await fetch(uploadUrl, {
  method: "PUT",
  body: file,
  headers: { "Content-Type": file.type },
});

// 3. Tell the API you're done — transcoding starts
const { video: ready } = await client.completeUpload({
  id: video.id,
});

For files over 5 MB or long-running uploads, createMultipartUpload gives you resumable chunked uploads up to 5 GB with cancel and retry support built in. The SDK handles the chunking; you just pass the file.

When completeUpload returns, the video is in processing. You can watch() its status over a streaming RPC if you want live updates, or just poll get() occasionally. When it flips to ready, it has:

• An HLS playback URL (m3u8) with every rendition your preset defined
• An embed URL and embed code (iframe + direct URL)
• A poster frame
• A full renditions table (codec, bitrate, resolution, bytes)
• Per-video cost and usage metadata

#Three ways to pick an encoding recipe

Every upload takes one of three preset modes — all managed from the dashboard, all producing the same playback URLs, all billed the same way.

Auto ladder (default). Upload with no preset field and we build a CMAF ABR ladder from your app’s auto-profile defaults — format (HLS / DASH / MP4), codec (H.264 / HEVC / VP9 / AV1), max resolution (480p–2160p), and quality tier (Economy / Standard / Premium). The out-of-the-box defaults produce an HLS + H.264 ladder up to 1080p at Standard quality. That plays on every modern browser, iOS, Android, and smart TV — no thinking required.

System presets. Curated templates for specific workflows. Pick one at upload time, or duplicate it as the starting point for a custom preset. System presets are read-only and always available; your duplicated version is yours to edit.

Custom presets. Define your exact encoding recipe once in the dashboard and reuse it on every upload. A preset carries a full ABR ladder — up to 20 variants, each with its own resolution, bitrate, CRF override, framerate override, and quality tier override. Encoder rate-control (CRF / CBR / VBR), content-type tuning, HDR, DRM, segment duration, and GOP alignment are all part of the preset.

#Multi-codec manifests — same ladder, two codecs

The trick hiding in HLS and DASH (via CMAF) is that a single manifest can reference variants in multiple codecs at the same resolutions. That means you can ship, for a single video:

• An AV1 ladder: 1080p + 720p + 480p
• An H.264 ladder at the same rungs: 1080p + 720p + 480p

All in one manifest. A capable player picks the AV1 1080p variant and streams roughly half the bytes of H.264. An older device can’t decode AV1, so it picks the H.264 1080p variant at the same resolution and keeps playing — no quality drop, just a less efficient codec. If its network gets worse, it adapts down its own codec ladder (H.264 1080p → 720p → 480p) without ever touching AV1.

You’re not paying extra for the compatibility safety net beyond the encoding cost of both ladders. CMAF segments stay shared between HLS and DASH packaging — we’re not duplicating storage per protocol.

All of it is configured in the preset. Open the dashboard, click New preset, pick your codec mix, define the shared resolution ladder, save. The next upload that references the preset gets the multi-codec manifest.

#Visibility and signed URLs

Every hosted video has one of three visibility modes:

• Public — anyone with the URL can play it. Fully edge-cached.
• Unlisted — playable, but requires a fresh signed URL. Not indexed.
• Private — playable only via short-lived signed URLs issued by the API, validated at the CDN edge.

You can also whitelist the domains allowed to embed the player via CORS rules. This matters for paid content: if someone scrapes your embed URL and drops it into their own site, the CDN refuses the request.

Signed URLs work the way you would expect. The API issues a token with an expiry, the token is validated at the edge, and it cannot be reused beyond its lifetime. No secret leaves the server.

#Pricing — three metered line items

Hosting bills three things:

• Encoding: €0.010/output minute (standard H.264 1080p/30fps). Same rates as the transcoding API, with the same codec, resolution, framerate, and quality multipliers.
• Storage: €0.020/GB per month. Metered daily against average bytes stored — uploading or deleting mid-month only charges for the portion the bytes existed.
• Egress (CDN delivery): €0.010/GB delivered. Global edge, metered hourly. No per-request fees.

For a typical workload of 60 minutes uploaded per month and 10,000 views at ~4 Mbps average bitrate, that works out to:

• Encoding: €0.60
• Storage: ~€0.35 (≈17 GB across renditions)
• Egress: ~€17.50 (1,750 GB delivered)

Total: about €18.45/month. You can tune the numbers to your own workload on the pricing page calculator.

#What this replaces

If you built a DIY video hosting stack in the last five years, you probably chained something like:

• S3 or GCS for original and rendition storage
• AWS MediaConvert, Zencoder, or a custom FFmpeg pipeline for transcoding
• CloudFront, Cloudflare, or Fastly for CDN delivery
• CloudFront signed URLs for private content
• hls.js + a custom-skinned player for playback
• A usage tracker to know what any of it actually cost

Each of those has its own dashboard, its own billing surprises, and its own integration work. MediaConvert alone can easily run hundreds of dollars a month for modest workloads, before you add storage and egress.

Video Hosting replaces that whole stack with one API, one bill, and one integration. You are not renting EC2 capacity you do not need. You are not provisioning a CloudFront distribution. You are not configuring an origin. You are not writing signed URL code. You call createUpload, PUT the file, call completeUpload, and you are done.

#When to skip hosting

If you already have a working video stack — storage, CDN, player, signed URLs — do not migrate just because hosting exists. Use the transcoding API directly. Hosting is opt-in per-app; your existing jobs keep working exactly the same way.

The transcoding API and hosting are not alternatives to each other. Hosting uses the transcoding API under the hood. If tomorrow you outgrow hosting and want to take over the storage and delivery layers yourself, every rendition we produced is the same rendition you would get from a raw transcoding job.

#Getting started

Head to your dashboard (sign in at /login or create an account), open an app, and click Enable hosting. That provisions a CDN hostname and a storage bucket for the app. From there, upload a video from the Videos tab or via the SDK, and watch it go from uploading to processing to ready.

If you want to understand how everything fits together before clicking any buttons, the Video Hosting product page walks through the full capability set, and the pricing page has the full metering breakdown.

As always, if you have questions or hit something weird, email me directly — still a one-person company, still the guy who wrote the code.

Happy hosting.