Forem: john jewski

Why I Stopped Writing Video Files to Disk and Route Everything Through /tmp

john jewski — Sun, 22 Feb 2026 21:35:12 +0000

When I built the first version of dltkk.to I made the obvious choice — download the video file, save it to a downloads folder, stream it to the user, clean up on a timer.

Within a week I had three problems:

Disk filling up when cleanup timers misfired on server restarts
Stale files from failed downloads accumulating
Potential privacy issue if a user's file sat on disk longer than it should

Here's how I fixed all three by routing everything through /tmp.

The Original Architecture (Wrong)

// Old approach — save to disk, cleanup later
const outputDir = './downloads';
const filename = `video_${Date.now()}.mp4`;
const outputPath = path.join(outputDir, filename);

const ytdlp = spawn('yt-dlp', ['-o', outputPath, url]);

ytdlp.on('close', (code) => {
  res.download(outputPath, () => {
    fs.unlinkSync(outputPath); // What if this fails?
  });
});

// Cleanup timer as fallback
setInterval(() => {
  // Delete files older than 10 minutes
  // But what if server restarts?
}, 60000);

Problems:

If the server restarts mid-download the cleanup never runs
res.download callback doesn't guarantee the file was sent successfully
Disk space is finite and permanent storage compounds

The /tmp Architecture (Right)

function streamViaTmp(videoUrl, format, res) {
  const tmpFile = `/tmp/dltkk_${Date.now()}_${Math.random().toString(36).slice(7)}.mp4`;

  function cleanup() {
    try { if (fs.existsSync(tmpFile)) fs.unlinkSync(tmpFile); } catch(e) {}
  }

  const ytdlp = spawn('yt-dlp', ['-o', tmpFile, videoUrl]);

  ytdlp.on('close', (code) => {
    if (code !== 0 || !fs.existsSync(tmpFile)) {
      cleanup();
      return res.status(500).json({ error: 'Download failed' });
    }

    res.setHeader('Content-Disposition', 'attachment; filename="video.mp4"');
    const stream = fs.createReadStream(tmpFile);
    stream.pipe(res);
    stream.on('end', cleanup);      // Delete after streaming
    stream.on('error', cleanup);    // Delete on error too
  });

  // Kill and cleanup if client disconnects
  res.on('close', () => {
    if (!res.writableEnded) {
      ytdlp.kill('SIGTERM');
      cleanup();
    }
  });
}

Why this works:

/tmp is RAM-based on Linux — no actual disk writes
cleanup() is called in every code path — success, error, and disconnect
File only exists for the duration of the download + stream — seconds at most
Server restarts clear /tmp automatically on most Linux systems

The Stdout Trap

Before landing on /tmp I tried streaming yt-dlp output directly via stdout:

yt-dlp -o - URL | pipe_to_client

This looks elegant but breaks silently on any format requiring merging. YouTube downloads almost always need merging — separate video stream (f137) and audio stream (f140) combined by ffmpeg into a single MP4.

When you pipe to stdout, ffmpeg can't write the merged file atomically. It either fails silently or produces a corrupted file. You won't notice until a user complains their video has no audio.

The rule: anything that might need ffmpeg merging must go through a real file path, even if that file path is in RAM.

GIF Conversion — Two /tmp Files

GIF conversion needs two passes — download as MP4 first, then convert:

const tmpMp4 = `/tmp/dltkk_${ts}_${rand}.mp4`;
const tmpGif = `/tmp/dltkk_${ts}_${rand}.gif`;

// Download to tmpMp4 first
ytdlp.on('close', () => {
  exec(`ffmpeg -y -i "${tmpMp4}" -vf "fps=10,scale=480:-1:flags=lanczos" -loop 0 "${tmpGif}"`, () => {
    // Stream tmpGif to client
    const stream = fs.createReadStream(tmpGif);
    stream.pipe(res);
    stream.on('end', () => {
      fs.unlinkSync(tmpMp4); // Delete both
      fs.unlinkSync(tmpGif);
    });
  });
});

Both files stay in RAM, both get deleted after the GIF streams. At peak load you might have a few hundred MB in /tmp — fine for a VPS with 2GB+ RAM.

The res.on('close') vs req.on('close') Bug

One more trap worth mentioning. I had this:

req.on('close', () => {
  ytdlp.kill('SIGTERM'); // Kills yt-dlp immediately
  cleanup();
});

req fires close the moment the POST request body is fully read — which happens almost instantly after the request arrives. So I was spawning yt-dlp and killing it a fraction of a second later on every single download.

Fix: Use res.on('close') — that fires only when the actual browser connection drops.

res.on('close', () => {
  if (!res.writableEnded) {
    ytdlp.kill('SIGTERM');
    cleanup();
  }
});

What I Built With This

All of the above is running in production at dltkk.to — a free yt-dlp web frontend supporting 1000+ platforms.

Every TikTok Downloader Quirk I Hit Building dltkk.to (And How I Fixed Them)

john jewski — Sun, 22 Feb 2026 21:33:03 +0000

Building a TikTok downloader sounds simple until you actually try it. TikTok actively fights scrapers and downloaders at every level. Here's every problem I hit and the exact fix for each one.

Problem 1: TikTok Blocks All Non-Browser Requests
The most basic issue. Send a plain yt-dlp request to TikTok and you get a 403 immediately. TikTok checks the request signature against known browser fingerprints.
Fix:
bashyt-dlp --impersonate chrome-131 https://www.tiktok.com/@user/video/123
The --impersonate flag makes yt-dlp spoof a full Chrome 131 browser signature including headers, TLS fingerprint, and HTTP/2 settings. Without this nothing works.
This needs updating periodically as TikTok updates its detection. chrome-131 is current as of early 2026.

Problem 2: Format Selection Returns Wrong File
TikTok videos have multiple quality streams. Using --format best sometimes returns a format that requires merging, which then fails silently if you're not set up for it.
Fix:
bashyt-dlp --impersonate chrome-131 --format b -o output.mp4 URL
Format b (best single file, no merging) is the most reliable for TikTok. It returns a pre-merged file directly instead of separate video and audio streams.

Problem 3: Audio Extraction Fails
Extracting MP3 from TikTok using standard -x --audio-format mp3 flags sometimes produces a corrupted file.
Fix:
bashyt-dlp --impersonate chrome-131 --no-playlist -x --audio-format mp3 --audio-quality 0 -o output.mp3 URL
The --audio-quality 0 flag forces the highest available bitrate. Without it you sometimes get a low quality fallback.

Problem 4: Watermark on Downloaded Video
If you use certain format selectors TikTok serves the watermarked version of the video. The watermark-free version is available but requires the right format selection.
Fix:
Format b (best single stream) returns the watermark-free version. The watermarked version appears when you accidentally select a different format stream.

Problem 5: Private Videos Give Unhelpful Errors
When a video is private yt-dlp returns a generic error that's hard to parse into a user-friendly message.
Fix:
javascriptfunction parseYtdlpError(errorOutput) {
if (errorOutput.includes('Private video')) return 'This video is private and cannot be downloaded.';
if (errorOutput.includes('not available')) return 'This video is not available in your region or has been deleted.';
if (errorOutput.includes('Login required')) return 'This content requires login and cannot be downloaded.';
return 'Download failed. Check the URL and try again.';
}
Parse the stderr output and map specific error strings to user-friendly messages.

Problem 6: Rate Limiting Under Load
TikTok rate limits download requests from the same IP. Under moderate traffic this starts causing failures.
Fix:
Rate limit on your own server before TikTok sees too many requests:
javascriptconst rateLimitMap = new Map();
function rateLimit(ip) {
const now = Date.now();
const timestamps = (rateLimitMap.get(ip) || []).filter(t => now - t < 60000);
timestamps.push(now);
rateLimitMap.set(ip, timestamps);
return timestamps.length > 3; // 3 requests per minute per IP
}
3 requests per minute per IP keeps you under TikTok's detection threshold while still being usable.

What I Built With This
dltkk.to — a free yt-dlp web frontend that handles TikTok, YouTube, Instagram, Twitter and 1000+ other platforms. Everything above is in production.
Relevant guides if you're building something similar:

Why TikTok downloaders stop working and how to fix them
Why TikTok downloaders stop working and how to fix them

Happy to answer questions about any of this in the comments.

I Built a Free yt-dlp Web Frontend That Supports 1000+ Sites — Here's How

john jewski — Sat, 21 Feb 2026 23:38:26 +0000

A few weeks ago I got tired of every video downloader site being a minefield of fake download buttons, popup ads, and malware redirects. So I built dltkk.to — a clean, no-BS web frontend for yt-dlp that anyone can use without installing anything.
Here's what I built, how it works technically, and what I learned shipping it.

What It Does
dltkk.to is a browser-based video downloader powered by yt-dlp on the backend. Paste any video URL, pick a format, hit download. That's it.
Supported formats: MP4, MP3, FLAC, WAV, AAC, MKV, GIF, and thumbnail extraction.
Supported platforms: Anything yt-dlp supports — TikTok, YouTube, Twitter/X, Instagram, Twitch, Vimeo, Facebook, and 1000+ more.
Extra features:

Batch mode — paste up to 10 URLs at once, processes sequentially
GIF conversion — converts video to optimized GIF via ffmpeg
No ads, no watermark, no signup — ever

The Stack
Simple Node.js + Express backend, plain HTML/CSS/JS frontend. No frameworks, no build step. Runs on a single VPS.
javascript// Core download flow — everything routes through /tmp
function streamViaTmp(videoUrl, platform, format, quality, req, res) {
const tmpFile = /tmp/dltkk_${Date.now()}_${rand}.${outputExt};

const ytdlp = spawn('yt-dlp', buildArgs(platform, format, quality, tmpFile, videoUrl));

ytdlp.on('close', code => {
if (code !== 0) return res.status(500).json({ error: parseError(errorOutput) });

// Stream file to client then delete immediately
res.setHeader('Content-Disposition', `attachment; filename="dltkk.${outputExt}"`);
const stream = fs.createReadStream(tmpFile);
stream.pipe(res);
stream.on('finish', () => fs.unlinkSync(tmpFile)); // deleted instantly

});
}

Key Technical Decisions
Why /tmp Instead of a Downloads Folder
My first version saved files to a downloads directory and cleaned them up on a timer. This caused two problems — disk space filling up under load, and files occasionally not getting cleaned up if the server restarted.
The fix was writing everything to /tmp which is RAM-based on Linux. Files never touch the main disk, and cleanup is instant after the stream finishes. Zero disk space issues since.
Why Not Stream Directly via stdout
yt-dlp can pipe directly to stdout with -o - which sounds ideal for streaming. The problem is any format that requires merging separate video and audio streams (most YouTube downloads, many others) needs ffmpeg to write a temp file first. Trying to stream this causes silent failures on certain platforms.
The solution: everything goes through /tmp. It's RAM anyway so there's no meaningful performance difference, and it works reliably across all platforms.
GIF Conversion
javascriptexec(ffmpeg -i "${tmpMp4}" -vf "fps=10,scale=480:-1:flags=lanczos" -loop 0 "${tmpGif}")
Download as MP4 first, convert with ffmpeg, stream the GIF, delete both files. The lanczos scaling algorithm gives the best quality at small file sizes. fps=10 keeps the GIF smooth without bloating the file.
Rate Limiting
3 requests per minute per IP using a simple in-memory Map. Cleans itself up every 5 minutes. Good enough for the current traffic level.
javascriptconst rateLimitMap = new Map();
function rateLimit(ip) {
const now = Date.now();
const timestamps = (rateLimitMap.get(ip) || []).filter(t => now - t < 60000);
timestamps.push(now);
rateLimitMap.set(ip, timestamps);
return timestamps.length > 3;
}

Platform-Specific Quirks
TikTok requires --impersonate chrome-131 or downloads fail. TikTok actively detects and blocks non-browser requests.
Reddit blocks all datacenter IPs at the network level. No amount of header spoofing fixes this — it's an IP range block. Currently showing a friendly error message for Reddit URLs.
Instagram needs a Referer: https://www.instagram.com/ header or it returns 403.
YouTube limits to 10 minutes to prevent abuse and requires specific format selection to get the best quality MP4 merge.

What I'd Do Differently
Proxy layer for Reddit — Reddit blocking is the most common complaint. A residential proxy for Reddit specifically would fix it but adds cost and complexity.
Progress indicator — right now users just see "Processing..." with no feedback on how long it'll take. A server-sent events progress stream from yt-dlp would improve UX significantly.
Caching popular downloads — if 50 people download the same viral TikTok in an hour, processing it 50 times is wasteful. A short TTL cache keyed by URL + format would reduce server load.

Results So Far
Launched 3 weeks ago. Currently at 180+ daily users growing consistently, driven entirely by organic Reddit posts and word of mouth. No paid ads outside of a small TikTok ad test.
The "no ads" positioning has resonated strongly — the most common feedback is people being surprised a downloader site can actually be clean and fast.

Try It
https://dltkk.to — free, no signup, works on any device.
Built with Node.js, Express, yt-dlp, and ffmpeg. Happy to answer any questions about the implementation.

How I Handle Platform Detection and URL Validation for Multiple Video Sources in Node.js

john jewski — Fri, 13 Feb 2026 15:31:05 +0000

One of the trickiest parts of building
dltkk.to was handling URL validation
across TikTok, YouTube and Instagram.

Each platform has completely different
URL structures and each needs different
validation logic. Here's how I solved it.

The Problem

Users paste all kinds of URLs:

\https://www.tiktok.com/@user/video/123 https://vm.tiktok.com/abc123 https://youtube.com/watch?v=abc123 https://youtu.be/abc123 https://www.instagram.com/reel/abc123 https://instagram.com/p/abc123 \\

All valid. All need different handling.

Platform Detection

First step is detecting which platform
the URL belongs to:

\`javascript
function detectPlatform(url) {
if (!url || typeof url !== 'string') {
return null
}

if (url.includes('tiktok.com')) {
return 'tiktok'
}

if (
url.includes('youtube.com/watch') ||
url.includes('youtu.be/')
) {
return 'youtube'
}

if (url.includes('instagram.com')) {
return 'instagram'
}

return null
}
`\

Simple but effective. Returns null for
unsupported platforms which we handle
gracefully in the response.

URL Normalization

TikTok specifically has a problem with
shortened URLs (vm.tiktok.com). These
need to be expanded before processing.

YouTube has the same issue with
youtu.be short links.

\`javascript
function normalizeYouTubeUrl(url) {
const match = url.match(
/(?:youtube.com\/watch\?v=|youtu.be\/)([^&\n?#]+)/
)

if (match) {
return https://www.youtube.com/watch?v=${match[1]}
}

return url
}
`\

This extracts the video ID from any
YouTube URL format and rebuilds a
clean standardized URL.

Duration Validation (YouTube Only)

YouTube is the only platform where
we check duration before processing.
Long videos could hammer the server
so we cap at 10 minutes:

\javascript function checkDuration(url) { return new Promise((resolve, reject) => { const command =yt-dlp --get-duration "${url}"`

exec(command, { timeout: 10000 }, (error, stdout) => {
  if (error) {
    // Continue anyway if check fails
    resolve(true)
    return
  }

  const duration = stdout.trim()
  const parts = duration.split(':').map(Number)
  let totalSeconds = 0

  if (parts.length === 2) {
    totalSeconds = parts[0] * 60 + parts[1]
  } else if (parts.length === 3) {
    totalSeconds = parts[0] * 3600 + 
                  parts[1] * 60 + 
                  parts[2]
  }

  if (totalSeconds > 600) {
    reject(new Error('Video exceeds 10 minute limit'))
    return
  }

  resolve(true)
})

})
}
`\

Note: we resolve true even on error
rather than blocking the user. The
actual download will fail naturally
if something is wrong.

Error Classification

Different errors need different user
facing messages:

\`javascript
function classifyError(errorOutput) {
if (errorOutput.includes('Sign in to confirm')) {
return 'YouTube requires verification.
Try a different video.'
}

if (errorOutput.includes('Unable to extract')) {
return 'Unable to download.
Check the URL and try again.'
}

if (errorOutput.includes('HTTP Error 429')) {
return 'Too many requests.
Wait a moment and try again.'
}

if (errorOutput.includes('Private video')) {
return 'This video is private.'
}

return 'Download failed.
Check the URL and try again.'
}
`\

Generic errors are confusing for users.
Classifying them makes the experience
much better.

File Cleanup

Temporary files auto delete after
2 minutes to prevent storage issues:

\javascript setTimeout(() => { if (fs.existsSync(outputPath)) { fs.unlink(outputPath, (err) => { if (err) { console.error('Failed to delete:', err) } }) } }, 120000) \\

Request Timeout

Long running downloads get killed
after 5 minutes:

\javascript const timeout = setTimeout(() => { process.kill() res.status(500).json({ error: 'Download timeout. Video may be too large.' }) }, 300000) \\

Putting It Together

\`javascript
app.post('/api/download', async (req, res) => {
const { url, format } = req.body

// Detect platform
const platform = detectPlatform(url)
if (!platform) {
return res.status(400).json({
error: 'Unsupported platform'
})
}

// Normalize URL
let videoUrl = url
if (platform === 'youtube') {
videoUrl = normalizeYouTubeUrl(url)

// Check duration
try {
  await checkDuration(videoUrl)
} catch (err) {
  return res.status(400).json({ 
    error: err.message 
  })
}

}

// Process download
processDownload(videoUrl, format, platform, res)
})
`\

What I'd Do Differently

Add rate limiting per IP immediately
Use a queue system for heavy traffic
Add Redis for caching duplicate requests
Implement proper logging from day one

Try the Live Version

Everything above is running at dltkk.to
Free, no signup required.

Questions about any part of the
implementation? Happy to go deeper.

I Built a Free Video Downloader With Node.js - Here's How

john jewski — Fri, 13 Feb 2026 03:32:13 +0000

I recently built dltkk.to - a free browser-based
video downloader for TikTok, YouTube and Instagram.

Here's the tech stack and what I learned building it.

What it does

Downloads TikTok videos without watermark
Converts YouTube videos to MP3
Saves Instagram Reels
Browser based (no app installation)
Completely free

Tech Stack

Backend: Node.js + Express
Video Processing: Custom built processing engine
Server: Linux VPS
Frontend: HTML, CSS, Tailwind

How it works

User pastes a TikTok/YouTube/Instagram URL into
the input box. The Node.js backend receives the
URL, validates the platform, then passes it to
my custom video processing engine.

The processing engine handles each platform
differently. For TikTok it strips the watermark
during the download process. For YouTube it
extracts and converts the audio stream to MP3.

Files are temporarily stored on the server and
automatically deleted after 2 minutes to save
storage space.

Building the Processing Engine

This was the hardest part of the project.
Each platform has different:

URL structures
Authentication requirements
Video stream formats
Rate limiting behavior

Had to reverse engineer how each platform
serves video content and build handlers
for each one separately.

What I learned

Always validate URLs server side not just client
Set timeouts on downloads (5 min max)
Auto delete temp files (learned this the hard way)
Each platform needs completely different handling logic
User agent spoofing is necessary to avoid being blocked

The YouTube Problem

YouTube was by far the hardest platform.
They actively fight against third party
downloading tools. Had to build in:

Format selection logic
Video and audio stream merging
Age restriction handling
Rate limit detection and backoff

Try it

Check it out at dltkk.to

Feedback welcome especially on the Node.js
backend architecture!