DEV Community: SDownloader

Engineering a 9-Platform Video Downloader on a $0 Budget: The Decoupled Serverless Edge Architecture

SDownloader — Sat, 05 Sep 2026 14:42:06 +0000

As software engineers, we often instinctively reach for AWS EC2 instances,
DigitalOcean droplets, or Kubernetes clusters the moment a project requires
compute. But what happens when you impose a strict $0 monthly infrastructure
budget?

Recently, I built and launched SDOWNLOADER, an
ad-clean, high-performance media downloader supporting 9 major social platforms.
Extracting videos—especially merging separate DASH video and audio streams from
Reddit—requires non-trivial CPU and memory resources. This makes it a difficult
fit for standard serverless environments with strict memory and execution
timeouts.

To solve this sustainably without expensive cloud server bills, the entire
platform is built around a decoupled serverless edge pipeline paired with a
custom ARM-optimized transcode worker.

Here is the comprehensive technical teardown of the decoupled architecture that
delivers high reliability and zero-cost scaling.

The 5-Layer Decoupled Architecture

To ensure enterprise-grade uptime, low latency, and continuous availability, the
system strictly decouples edge ingress from backend processing:

[User Browser]
       │
       ▼ (1. Static Edge Delivery)
[Cloudflare Pages] (SvelteKit 2 Static Export, zero blocking CSS, sub-second LCP)
       │
       ▼ (2. Edge Security Gateway & Ingress Protection)
[Cloudflare Worker] (api.sdownloader.online - KV rate limiting & URL allowlist
validation)
       │
       ▼ (3. Asynchronous Database Queue & State Engine)
[Supabase PostgreSQL] (video_jobs queue + automated retention pruning)
       ▲
       │ (4. Asynchronous Polling & Stream Processing)
[Custom ARM-Optimized Transcode Worker]
       ├── High-Throughput Reverse Proxy
       ├── Watchdog & Task Supervisor
       └── ARM Transcode Engine (Stream extraction & dynamic audio-video muxing)
       │
       ▼ (5. Edge Storage & Streaming)
[Backblaze B2 / Cloudflare Bandwidth Alliance]

Edge Frontend Layer

The frontend is built using SvelteKit 2 and exported statically onto Cloudflare
Pages:

· Sub-second LCP: Component styles are inlined at build time
(inlineStyleThreshold: 102400), completely eliminating render-blocking CSS
links.
· Interaction-Driven GA4 Telemetry: Analytics tracking is initialized on
user interaction (scroll, click, keydown), keeping Lighthouse Performance at
90+ without sacrificing conversion attribution.
· Direct Database Polling: To avoid burning edge worker invocation quotas,
the client frontend polls the database PostgREST API directly
(/rest/v1/video_jobs) using an anonymous read key.

Ingress & Security Gateway

The public API gateway runs on a Cloudflare Edge Worker
(api.sdownloader.online):

· Validates incoming URLs against strict allowlists across all 9 supported
platforms.
· Applies IP-based sliding window rate-limiting using Cloudflare KV to defend
against traffic spikes.
· Enqueues verified requests into the database queue and returns a lightweight
jobId in <100ms.

The Compute Layer: Custom ARM-Optimized Transcode Worker

Heavy compute is handled by a dedicated, low-power ARM worker architecture
optimized for audio-video transcoding:

· Energy-Efficient Dedicated Hardware: ARM-based architectures provide
exceptional performance-per-watt for multimedia operations, allowing
continuous 24/7 background execution without server rental costs.
· Sequential Chunk Streaming: By optimizing network payload streaming with
sequential chunk uploads and extended socket timeouts, large media files
upload reliably without packet drops or stream collapses.
· Process Watchdog Supervision: A lightweight process supervisor
continuously monitors task health, automatically restarting workers in the
event of transient errors.

Solving the Reddit DASH Audio Nightmare

Reddit hosts media on v.redd.it using Dynamic Adaptive Streaming over HTTP
(DASH). The video stream contains zero audio; the audio track is stored in a
separate fragmented stream.

Most free downloaders fail here, serving muted clips. In our custom ARM
transcode pipeline:

The engine fetches both video and audio manifests simultaneously.
The transcode worker multiplexes the streams into a unified high-definition MP4 with perfect lip-sync.
The resulting container is streamed directly to object storage via the Cloudflare Bandwidth Alliance.
Presigned download URLs are generated with a 20-hour cache TTL matching our 24-hour lifecycle deletion policy.

Full 9-Platform Production Scope

SDOWNLOADER handles:

· Twitter / X: Original 1080p HD MP4 streams.
· Reddit: Complete DASH audio + video synchronization.
· SoundCloud & Bandcamp: Pure audio stream extraction to MP3 with bitrate
labeling.
· Pinterest & Threads: Direct video and pin saving.
· Bluesky & Twitch: Live clips and VOD streams.
· Dailymotion: Direct stream redirect delivery.

The Zero-Popunder Policy & User Experience

Legacy downloaders monetize by opening shady popunders, triggering deceptive
download alerts, or pushing unwanted software.

Because our architecture eliminates cloud server overhead, we do not engage in
predatory monetization:

· 0 popunders or deceptive redirects
· 0 fake download buttons
· No software, app, or browser extension installations
· Only clean, non-intrusive display banners to offset yearly domain
registration.

Live Demo & Feedback

The entire stack is running live right now. You can test the latency and speed
of our decoupled pipeline yourself:

👉 https://sdownloader.online

Try downloading a Reddit clip with audio or an original 1080p Twitter video.

If you have questions about designing decoupled serverless edge pipelines,
optimizing ARM transcode workloads, or building zero-budget microservices, drop
your questions in the comments below!

Note: The GitHub repositories for this project are not public yet due to
ongoing security audits, database migrations, and documentation updates. They
will be open-sourced once these processes are completed.

How I Built a Video Downloader Running on My Android Phone ($0/Month)

SDownloader — Fri, 17 Jul 2026 12:38:44 +0000

A backend engineer's field notes on running a real, publicly-used web service entirely on a phone in a drawer — because every "proper" host either charged money or violated a ToS I actually wanted to keep.

The premise

I wanted to build SDOWNLOADER — a browser-based tool to download videos from Vimeo, Twitter/X, Twitch, Dailymotion, SoundCloud, TikTok, and Facebook. No app, no account, no watermark.

The catch: I had no server budget. Not "cheap VPS" budget — zero dollars. So the whole thing had to run on free tiers, with one very unconventional piece: the actual video-processing backend runs on an Android phone, in Termux, sitting on my desk.

This is the story of what broke, why, and how the final architecture holds together.

The architecture

Browser
  │  POST /api/metadata
  ▼
Cloudflare Worker    ← validates URL, rate-limits, inserts job
  │
  ▼
 Postgres    ← job queue (FOR UPDATE SKIP LOCKED)
  ▲
  │  polls directly (no server round-trip)
  │
  └── Cloudflare Worker ──HTTP──▶ Cloudflare Tunnel ──▶ nginx:8080 ──▶ Node.js
                                  (named, persistent)      (Alpine        (the actual
                                                             proot)        yt-dlp worker)

Three Cloudflare Workers (100k free requests/day each), one free Postgres + job queue, one S3 bucket (free egress-friendly storage for the rare file that needs re-hosting), and a phone running Alpine Linux inside proot-distro inside Termux.

The phone is the backend. No VPS, no Render, no Railway. Just a device that happens to always be plugged in and on WiFi.

Problem 1: Android doesn't let you bind to port 80

Trivial once you know it, infuriating the first time you hit it: Android's kernel blocks unprivileged processes — including everything inside proot, since proot doesn't grant real root — from binding to ports below 1024. nginx -p 80 just... fails.

Fix: nginx listens on 8080. A Cloudflare Named Tunnel (cloudflared tunnel run) maps proc.yourdomain.com → localhost:8080 from inside the phone's network, so nothing needs to be port-forwarded or exposed to the internet directly. The tunnel is outbound-only, which also means the phone never needs a static IP or open inbound port — good, because it's on residential mobile data/WiFi with neither.

Problem 2: `proot-distro` kills your whole process tree on exit

Every one-shot command like proot-distro login alpine -- some-command tears down everything spawned inside it the moment some-command exits — including background children you explicitly backgrounded with &. This makes running a persistent Node.js server "inside a temporary shell" a non-starter unless you understand this up front.

Fix: nohup proot-distro login alpine -- long-running-command & from the Termux side. nohup makes the whole proot session immune to hangup signals, so it survives the parent shell (and Termux itself) closing.

Problem 3: pm2's daemon mode doesn't survive proot

pm2 normally daemonizes itself and detaches — which doesn't work inside proot's constrained process model; the daemon dies with its parent. The fix is pm2-runtime, pm2's foreground/container mode, designed exactly for environments like Docker (or proot) where you want pm2's process supervision — auto-restart, memory limits, exponential backoff — without the daemonization. Wrap that in the nohup proot-distro login ... & pattern above, and it survives Termux being closed entirely.

Problem 4: musl libc doesn't retry DNS

This one cost me the most debugging time. Every time the processor restarted, the first postgres query would fail with EAI_AGAIN, then recover on the next attempt 60 seconds later. Looked like a flaky network. It wasn't.

Alpine uses musl libc instead of glibc. glibc silently retries a failed UDP DNS query a few times before giving up. musl does not — one failed query, one immediate EAI_AGAIN, no retry, ever, unless you explicitly configure options timeout:2 attempts:5 in resolv.conf. Combine that with a real startup race condition — Android hasn't always finished registering a freshly-spawned proot process for network access in the first few hundred milliseconds — and you get a DNS failure on every single restart, not just occasionally.

The fix has two layers:

Bind-mount a Termux-controlled resolv.conf into the Alpine session on every start, with options timeout:2 attempts:5 forcing musl to actually retry.
Run a tiny DNS warm-up loop before starting the Node process — poll nslookup against the real postgres hostname until it resolves, then exec into pm2-runtime. No more racing the OS.

Problem 5: some platforms block the network your phone is on

TikTok and Facebook return degraded or blocked responses to requests coming from IP ranges they've flagged — this affects some cloud/datacenter ranges more aggressively than residential ones, but neither is bulletproof, and the specifics change constantly on both sides.

Rather than fight an arms race on the phone itself, I moved just the metadata extraction step for those two platforms into a Cloudflare Worker. Workers execute from Cloudflare's own edge network, which behaves differently than either a residential connection or a typical datacenter block-list entry. The Worker fetches the platform's public metadata, normalizes it into a schema my downstream code already understands (mirroring yt-dlp's format shape), and hands it back to the phone — which then either redirects the user straight to a CDN URL, or downloads and re-hosts the file if the CDN link turns out to be session-bound.

This turned into a genuinely useful pattern beyond just this one problem: use the edge worker as your "clean room" fetcher for anything IP-sensitive, and keep your actual compute wherever's cheapest.

Problem 6: the "server" is also someone's phone

A phone has a battery and a data cap in ways a VPS doesn't. So the processor checks a small JSON status file — written every 30 seconds by a battery/WiFi monitor script — before starting any full download:

Battery under 20% and unplugged → downloads pause (metadata/stream-redirect jobs still work; only the heavier download-and-reupload path is gated).
On mobile data instead of WiFi → the max file size for a full download is cut roughly in half.

If the status file is missing or stale, the guard fails open, not closed — a monitoring hiccup should never be able to silently break the product for users.

What actually keeps this running

A watchdog script polls every 30 seconds: is nginx alive and answering? Is the Node processor alive? Is the tunnel actually passing traffic (not just "is the process running," but "does an end-to-end request through the tunnel succeed")? Any no, and it restarts just that component. It self-daemonizes with nohup so it survives the Termux app being swiped away, and a single flag file acts as the kill switch so stop actually means stop - including for the watchdog itself, which is trickier than it sounds when the watchdog's whole job is restarting things that go down.

The stack, for the curious

Frontend: SvelteKit, adapter-static, deployed to Cloudflare Pages
API layer: Cloudflare Workers (no cold starts, generous free tier)
Queue/DB: Postgres, atomic job claiming via FOR UPDATE SKIP LOCKED
Storage: S3 bucket for the minority of jobs that need re-hosting
Processor: Node.js + yt-dlp, running in Alpine Linux under proot-distro, under Termux, under Android
Ingress: Cloudflare Named Tunnel — outbound-only, no port forwarding
Monetization: a single ad-supported free tier, no subscriptions

Total infrastructure cost: $0/month. Total uptime dependency: my phone staying charged and connected, same as anyone's home router.

Why write this up

Mostly because "run your backend on a phone" sounded like a joke when I started, and turned out to be a legitimately solid free-tier architecture once each of the six problems above got solved properly instead of papered over. If you're bootstrapping something with genuinely zero budget, a phone is a surprisingly capable, always-on Linux box that most people already own.

If you want to see the result: sdownloader.online.

Questions about any specific piece — the DNS fix, the Worker-as-clean-fetcher pattern, the battery-aware queue — happy to go deeper in the comments.