Forem: Maxim Osovsky

How I Designed a Content Distribution Pipeline — 9 Content Types, 20+ Platforms, One Interactive Diagram

Maxim Osovsky — Thu, 05 Mar 2026 20:38:42 +0000

The Copy-Paste Problem

Every time I publish a dev.to article, I share it on X and Mastodon — but why not also Bluesky and Threads? I keep meaning to, but it's manual work every time.

My podcast goes to Apple Podcasts — but I want it on Spotify and YouTube Podcasts too. I just never get around to setting it up for each episode.

When I shoot a vertical video, it goes to TikTok — but I skip Instagram Reels, YouTube Shorts, and Facebook Stories. Same content, different platforms, and I don't have the time to upload it four times.

And when I create an event — it's a 2-hour ordeal. Luma, LinkedIn Events, Facebook Events, Meetup. Each one needs its own format, its own description, its own image.

That's 20+ platforms. For 9 different content types. And I'm doing maybe half of it manually, skipping the rest.

During one of the strategy sessions with my team, I mapped out every content type I produce, every platform I post to, and every connection between them. The result was a mess of arrows on a whiteboard. So I turned it into code.

What I'm Building

An open-source content distribution hub — one dashboard that handles all 9 content types across 20+ platforms. Write in Markdown, and the system routes everything to the right platforms automatically.

Feature	Details
Content types	9 (articles, book chapters, photos, vertical/horizontal video, podcasts, events)
Platforms	20+ (LinkedIn, Medium, Dev.to, Substack, YouTube, X, Mastodon, Bluesky, Threads, TikTok, Instagram, Facebook, Reddit, Luma, Meetup, Spotify, Apple Podcasts)
Price	$0 (self-hosted on Vercel)
Stack	Vanilla JS + Vercel Serverless + Upstash Redis

The project is called Autoposting Dashboard and it's open source: github.com/maximosovsky/avtoposting.

The Diagram That Maps It All

Before writing any API integration, I needed to see the full picture. The first attempt was a Mermaid diagram:

graph LR
    Write --> Storage --> Dashboard --> Publish --> API --> Crosspost --> Track

Mermaid was great for a quick sketch, but it fell apart with 50+ nodes and complex routing. I couldn't control layout, colors, or icons. So I switched to custom HTML + SVG — a single diagram.html file with pan, zoom, and real connection lines drawn via JavaScript.

Then the icons broke.

I was loading platform SVGs from Simple Icons via CDN — LinkedIn, Medium, Dev.to, YouTube, etc. Some rendered fine. Some didn't. Some loaded on Chrome but not Firefox. Some showed as blank squares.

The fix was boring but effective: download all 21 icons into a local icons/ folder and reference them directly. No CDN, no CORS, no surprises.

icons/
├── bluesky-0085FF.svg
├── devdotto-0A0A0A.svg
├── googledrive-4285F4.svg
├── luma.svg
├── mastodon-6364FF.svg
├── medium-000000.svg
├── meetup-ED1C40.svg
├── youtube-FF0000.svg
└── ... (21 total)

The final diagram visualizes the entire 8-stage pipeline:

⓪ Media → ① Write → ② Storage → ③ Dashboard → ④ Publish → ⑤ API → ⑥ Cross-post → ⑦ Track

Every node is clickable. Every connection is a real data flow. Every content type has its own path through the pipeline.

Building this diagram with Antigravity (Google DeepMind's AI coding assistant) took one intensive session. We went through 30 questions in 3 rounds of 10, challenging every assumption about content routing, media storage, and platform dependencies.

The 9 Content Types and Where They Go

Here's the routing logic for each content type — the "why" behind every arrow in the diagram.

1. LinkedIn Article → 4 socials

Write .md → LinkedIn (publish) → X, Mastodon, Bluesky, Threads (share link)

LinkedIn is the primary platform for business content. After publishing, the LinkedIn URL gets shared to 4 social platforms. Each platform's API script (twitter.js, mastodon.js, etc.) handles both link posts and media uploads — a dual-mode approach we chose over separate scripts.

2. Medium Article → 4 socials

Write .md → Medium (publish) → X, Mastodon, Bluesky, Threads (share link)

Same pattern as LinkedIn, different audience. Medium for philosophy and science essays.

3. Dev.to Article → 4 socials + Reddit

Write .md → Dev.to (publish) → X, Mastodon, Bluesky, Threads (share link)
                             → Reddit (full article copy, subreddit by tags)

Dev.to is the flagship for build-in-public content. Reddit gets a full copy (not just a link) — subreddit is auto-selected based on article tags.

4. Book Chapters → Substack → LinkedIn, Medium → 4 socials

Write .md → Substack (publish first)
         → LinkedIn, Medium (share Substack link)
         → X, Mastodon, Bluesky, Threads (share Substack link)

Book chapters publish to Substack first. Then the Substack link cascades to LinkedIn, Medium, and 4 socials. Sequential, not parallel — Substack is the source of truth.

5. Photo + Text → 6 socials

Upload photo → Facebook, Instagram (direct post)
            → X, Mastodon, Bluesky, Threads (media upload)

No link sharing needed — the photo and its caption are the content. Same image and text uploaded directly to all 6 platforms.

6. Vertical Video → 4 platforms

Upload 9:16 video → YouTube Shorts, TikTok, Instagram Reels, Facebook Stories
                  → X, Mastodon, Bluesky, Threads (share YouTube Shorts link)

Vertical video (≤512MB, 9:16 aspect ratio) goes to all short-form video platforms.

7. Horizontal Video → YouTube → 4 socials

Upload 16:9 video → YouTube (publish)
                  → X, Mastodon, Bluesky, Threads (share YouTube link)

Standard YouTube flow. Cover image (thumbnail) stored alongside the video metadata.

8. Podcast → Podster.fm → Apple, Spotify, YouTube → 4 socials

Write .md (audio_url in frontmatter) → Podster.fm (RSS distribution)
                                     → Apple Podcasts, Spotify, YouTube Podcasts
                                     → X, Mastodon, Bluesky, Threads

Audio files are referenced via audio_url in the Markdown frontmatter. Podster.fm handles RSS distribution to all podcast platforms.

9. Events → Luma → 4 event platforms + Instagram → 4 socials

Create event → Luma (publish first)
            → LinkedIn Events, Facebook Events, Meetup.com, Instagram (share Luma link)
            → X, Mastodon, Bluesky, Threads (share Luma link)

Events always publish to Luma first — then the Luma link fans out to all event platforms and socials.

Try It

The project is open source:

git clone https://github.com/maximosovsky/avtoposting.git
cd avtoposting
npm i -g vercel
cp .env.example .env   # fill in API keys
vercel dev --listen 3000
# Open http://localhost:3000

Open diagram.html in a browser to explore the full pipeline interactively.

Building something similar? Drop a comment — I'd love to compare approaches.

Building in public, one utility at a time. Follow the journey: LinkedIn · GitHub · Dev.to

I Was Building a Cloud Video Service. YouTube Turned Me Into an IP Trafficker.

Maxim Osovsky — Tue, 03 Mar 2026 16:54:00 +0000

The Irony

I was building a simple cloud service. Paste YouTube links, server merges them, you get a video. Innocent. Wholesome. The kind of project you'd show your mom.

Then YouTube said no.

Not because I was doing anything wrong. Not because I violated their API terms. But because my server's IP address came from a datacenter instead of someone's apartment.

So now, to make this work, I'll have to buy residential IP traffic from a proxy provider, route my downloads through random households, and pray that YouTube's bot detection doesn't notice. My "simple video merging service" is quietly becoming a proxy arbitrage operation that will live in the gray zone of YouTube's Terms of Service.

This is that story.

Context: What I'm Building

Merge Video is an open-source service I'm building to merge video files in the cloud. The idea: you send links or upload files, go to sleep, and wake up to a merged video on YouTube with a link in your email.

I film long strategy sessions — 6 to 8 hours each. My camera records in 20-minute segments. After each session I have dozens of files that need to be joined. I spent over $1,500 outsourcing this before building the service myself.

Here's the thing: after a session, I rarely have time to edit. So I upload the raw segments straight to YouTube — unmerged, unedited — just to free up disk space. YouTube becomes my storage. Over the years I've accumulated hundreds of raw clips organized into playlists, each playlist representing one session that still needs to be merged into a single video for the archive.

That's why the "YouTube URLs" mode exists. It will let you paste a playlist link and the server will download all the clips, merge them, and upload the result back as one video. It worked perfectly on localhost. On the cloud server:

ERROR: Sign in to confirm you're not a bot.

In Part 1, I solved the ffmpeg bugs. In Part 4, I solved cookie extraction. This is Part 5: getting downloads to actually work from a server.

The Real Problem: It's the IP, Not the Cookies

After extracting cookies (see Part 4), I uploaded cookies.txt to the server. Same yt-dlp command that worked on localhost:

yt-dlp --cookies cookies.txt -f "best[ext=mp4]" "https://youtu.be/VIDEO_ID"

Result on localhost: ✅ Downloaded in 30 seconds

Result on cloud server: ❌ Same bot detection error

The cookies were valid. The command was identical. The only difference: the IP address. My laptop has a residential IP from my ISP. The server has a datacenter IP from Alibaba Cloud.

YouTube doesn't just check cookies. It checks where the request comes from. Datacenter IPs are flagged automatically — no amount of cookies, headers, or user-agent strings will help.

7 Methods Tested

I spent two days testing every viable approach. Here's the full scorecard:

#	Method	How it works	Result
1	yt-dlp + cookies	Direct download with browser cookies	❌ IP blocked
2	Cobalt API (public)	Third-party download API	❌ Requires Turnstile CAPTCHA
3	Self-hosted Cobalt	Run your own Cobalt instance	❌ Signature decipher broken
4	RapidAPI YouTube downloaders	Commercial download APIs	❌ Rate-limited, unreliable
5	SaveFrom / similar services	Web-based download tools	❌ Quality limits, no API
6	YouTube Data API direct download	Google's official API	❌ No download endpoint exists
7	Residential proxy + yt-dlp	Route traffic through residential IPs	✅ Works

Every method that tries to download from a datacenter IP fails. The only solution is to not have a datacenter IP — or to commit to the charade of pretending you don't.

Let me walk you through the graveyard.

Method 1: yt-dlp + Cookies (Failed)

The setup from Part 2. Cookies extracted from Firefox, uploaded to server, yt-dlp configured:

yt-dlp --cookies cookies.txt --js-runtimes node \
  -f "best[ext=mp4]" "https://youtu.be/VIDEO_ID"

On localhost with a residential IP: instant download. On the cloud server:

ERROR: Sign in to confirm you're not a bot.

Diagnosis: YouTube allows or blocks based on IP reputation before even checking cookies. If the IP is flagged as datacenter, the request is rejected at the network level.

Method 2: Cobalt API (Failed)

Cobalt is a popular open-source media downloader. Their public API at api.cobalt.tools seemed perfect — offload the download to their infrastructure.

curl -X POST "https://api.cobalt.tools" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://youtu.be/VIDEO_ID"}'

Result: error.api.auth.turnstile.missing

Cobalt added Cloudflare Turnstile CAPTCHA to prevent automated API abuse. Every request now requires solving a browser challenge — impossible from a server script.

Method 3: Self-Hosted Cobalt (Failed)

If the public API requires CAPTCHA, run your own instance. I deployed Cobalt via Docker on the server:

services:
  cobalt-api:
    image: ghcr.io/imputnet/cobalt:10
    ports:
      - "9000:9000"
    environment:
      API_AUTH_REQUIRED: "false"

The API responded, accepted URLs, and started processing. Then:

error: ErrorCantProcess - couldn't process your request

Diagnosis: Cobalt uses its own YouTube signature deciphering algorithm. YouTube frequently changes their obfuscation, and the self-hosted version had a stale decipher implementation. The maintainers patch the public instance frequently, but a self-hosted snapshot falls behind within days.

Methods 4–6: Commercial APIs and Direct Downloads (All Failed)

Method	Why it failed
RapidAPI downloaders	Rate limits, intermittent 403s, quality caps. Most are wrappers around the same broken approaches
SaveFrom / y2mate / similar	Designed for browser use. No reliable API, quality limits, heavy ads, services go down often
YouTube Data API	Google's official API has endpoints for metadata, search, and uploads — but no download endpoint. By design.

None of these solve the core problem: YouTube blocks server-originating requests. The entire ecosystem of "YouTube downloader" services is a game of whack-a-mole against Google's engineering team. And Google has more engineers.

Method 7: Residential Proxy ✅

The only approach that worked. And the one I was hoping to avoid.

To download a YouTube video from a cloud server, you need to pretend your server is someone's laptop in a suburban apartment. That's what residential proxies do. That's what I now have to pay for monthly. Welcome to the internet.

What's a residential proxy?

Instead of your request going directly from the server (datacenter IP) to YouTube, it goes through a proxy server that uses an IP assigned by a real ISP to a real household. YouTube sees a residential IP and treats it as a normal user.

Server (datacenter IP) → Proxy (residential IP) → YouTube

Setup

I chose Decodo for residential proxies — they support SOCKS5, have 115M+ IPs across 195+ countries, and offer pay-per-GB pricing.

Backend configuration:

# config.py
PROXY_URL = os.environ.get("PROXY_URL", "")

# video.py — in both expand_urls() and download_videos()
cmd = ["yt-dlp", "--cookies", str(COOKIES_FILE),
       "--js-runtimes", "node",
       "-f", "best[ext=mp4]"]

if PROXY_URL:
    cmd.extend(["--proxy", PROXY_URL])

Environment:

# .env on the server
PROXY_URL=socks5h://user-USERNAME-session-1:PASSWORD@gate.proxy-provider.com:7000

Dependencies:

pip install pysocks  # Required for SOCKS5 proxy support

PySocks is required for yt-dlp to work with SOCKS5 proxies.

First successful test

yt-dlp --proxy "socks5h://user-USERNAME-session-1:PASSWORD@gate.proxy-provider.com:7000" \
  --cookies cookies.txt --js-runtimes node \
  -f "best[ext=mp4]" "https://youtu.be/VIDEO_ID"

[youtube] Extracting URL: https://youtu.be/VIDEO_ID
[youtube] VIDEO_ID: Downloading webpage
[youtube] VIDEO_ID: Downloading ios player API JSON
[download] Destination: video.mp4
[download] 100% of 403.12MiB in 00:02:15

It worked. Same server, same datacenter IP, same cookies. The only change: traffic routed through a residential proxy.

Cost Analysis: Congratulations, You're a Bandwidth Broker

Here's where the absurdity becomes quantifiable. I wanted to build a free, open-source tool. Instead I'll have a variable cost per download that scales with video length. Every time someone pastes a YouTube link into my service, I'll have to purchase residential bandwidth from a proxy provider and route it through some stranger's home internet connection.

Let that sink in.

Item	Cost
Residential proxy plan (2 GB)	$12/month
Pay-as-you-go rate	$3.50/GB
Typical video download (17 min, 1080p)	~400 MB
Two videos merged (one E2E test)	~870 MB
Estimated downloads per 2 GB plan	~5 video pairs

Cost per merge job

At $12 for 2 GB: roughly $2.40 per merge (assuming two ~400 MB videos).

Compare with my old approach: $30–50 per merge outsourced to a human editor.

The economics work, but it means my "free self-hosted service" will have a variable cost per download that scales with video size. Every time a user pastes a YouTube link, I'll be buying residential IP traffic.

Scaling considerations

Plan	$/GB	Monthly cost	Videos (~400 MB each)
2 GB	$6.00	$12	5
8 GB	$1.80	$14.50	20
25 GB	$1.70	$42.90	62
Pay-as-you-go	$3.50	Variable	Variable

For personal use (5–10 merges/month), the 2 GB plan is fine. For a public service, proxy costs will become the dominant expense — not compute, not storage, not bandwidth. The most expensive part of my video merging service will be pretending to be a regular person on the internet.

I started this project to save $1,500/year on video editing outsourcing. Now I'll be spending $144/year on residential IP traffic just to download files that are publicly available on YouTube. The economics work, but the irony is thick enough to cut.

The Strategic Lesson

YouTube's bot detection operates at two different levels:

Level	What's checked	Solution
Application	Cookies, headers, user-agent, JS challenges	Cookies + `--js-runtimes node`
Network	IP reputation (datacenter vs. residential)	Residential proxy

I spent Part 4 solving the application layer — extracting cookies, configuring JavaScript runtimes. All necessary, but not sufficient.

The network layer is the harder barrier. YouTube maintains IP reputation databases. Datacenter IP ranges from major cloud providers (AWS, GCP, Azure, Alibaba, etc.) are automatically flagged. No amount of application-layer configuration changes this.

Can you avoid proxies?

Surely there's a way to not pay strangers for their IP addresses?

Alternative	Feasibility
Run the server from home (residential IP)	✅ Works, but congrats — you've un-invented the cloud
Use a VPS from a residential ISP	⚠️ Rare, expensive, may still get flagged
Set up a VPN tunnel to your home network	⚠️ Works but adds latency, depends on home uplink
Download locally, upload to server, merge	⚠️ Works but defeats the purpose of cloud processing

For a production service, residential proxies are the pragmatic choice. They're the only way to reliably download from YouTube on cloud infrastructure.

So yes — to run a cloud video service that touches YouTube, you must pay a monthly fee to disguise your cloud server as a home computer. The cloud, pretending not to be the cloud. Peak 2026.

Update: It Works

While writing this article, I ran the first real end-to-end test. Two strategy session clips — 17 minutes and 26 minutes — pasted as a YouTube playlist link into my own service.

The proxy downloaded 870 MB. The server spent about an hour normalizing and merging (it's a small 2 vCPU instance). Then it uploaded the result to YouTube and sent me an email: 🎬 Your merged video is ready!

Cost of this single merge: roughly $6 in residential proxy traffic.

I started this project to avoid paying $30–50 per merge to a human editor. At $6 per merge, the math still works. But I never imagined that the hardest part of building a video merging service would be convincing YouTube that my server is someone's laptop.

This is Part 5 of a series about building Merge Video. Previous: 6 Ways to Get YouTube Cookies — Only 1 Works.

Building in public, one utility at a time. Follow the journey: LinkedIn · GitHub

6 Ways to Get YouTube Cookies for yt-dlp in 2026 — Only 1 Works

Maxim Osovsky — Mon, 02 Mar 2026 16:54:00 +0000

The Hypothesis

I have a self-hosted video merging service — Merge Video. It downloads YouTube videos with yt-dlp, merges them with ffmpeg, and uploads the result back to YouTube.

On localhost everything worked. On a cloud server:

ERROR: Sign in to confirm you're not a bot.
Use --cookies-from-browser or --cookies for authentication.

YouTube detected the datacenter IP and blocked downloads. The fix seemed obvious: extract cookies from Chrome, upload to server, done.

My hypothesis: extracting cookies is a solved problem. Dozens of tools exist. Should take 10 minutes.

Reality: I spent 3 hours trying 6 different methods. Only one worked — and it wasn't Chrome.

What Debugging Cookies Taught Me About Strategy

I run strategic sessions — 6-to-10-hour workshops where teams map complex systems before making decisions. We draw the object of management, analyze its place in a larger system, do hindsight and foresight, and only then build a plan. Over 150 sessions so far.

The cookie debugging was the exact opposite of this process.

I had an AI coding assistant — Antigravity by Google DeepMind — writing scripts, testing APIs, trying approaches. It's incredibly fast. But here's what happened: we burned through 6 attempts in 3 hours because neither of us stopped to map the system first.

The moment I paused and asked: "What's the plan? Pros, cons, risks, options?" — the answer became obvious in minutes:

Without strategy	With strategy
Try DPAPI → fail	Map the landscape: Chrome encrypts, Firefox doesn't
Try rookiepy → fail	Identify constraints: app-bound encryption since July 2024
Try CDP → fail	Evaluate options: only 2 viable paths (Firefox or proxies)
Try OAuth → fail	Choose: Firefox = free, proxies = $1.50/GB
Try Bearer token → fail	Execute: 10 lines of Python, done
Try Firefox → works
6 attempts, 3 hours	1 attempt, 5 minutes

This is the pattern I see in every strategic session: teams that jump to solutions before mapping the system waste time on dead ends. Teams that invest 30 minutes in analysis often find the answer without trying a single wrong approach.

AI tools are powerful executors. They'll write any script you ask for in seconds. But they'll also happily execute 5 wrong approaches before someone asks: "Wait — what are we actually dealing with?"

The human's job isn't to write code. It's to bring strategy — to ask the right questions before the first line of code is written.

⚠️ First, a Security Warning

Before you Google "export Chrome cookies" — read this.

When I first asked Antigravity to help extract cookies, its very first suggestion was to install a popular Chrome extension — Get cookies.txt. Quick, easy, thousands of users. I didn't install it — something felt off about giving a third-party extension access to all my browser sessions.

Good instinct. That extension turned out to be malware. It was silently sending all your cookies — login sessions, banking tokens, everything — to its developer. Google removed it from the Chrome Web Store and flagged it as malware.

This isn't an isolated case. Any browser extension with cookie access permissions can steal your sessions. Cookie-stealing malware like Raccoon, RedLine, and Vidar has been doing exactly this for years.

The rule: never install a third-party extension to export cookies. Use built-in tools or read the database directly.

Attempt #1: DPAPI Decryption Script

Chrome encrypts cookies with DPAPI + AES-256-GCM on Windows. I wrote a Python script to call CryptUnprotectData via ctypes:

class DATA_BLOB(ctypes.Structure):
    _fields_ = [("cbData", ctypes.wintypes.DWORD),
                 ("pbData", ctypes.POINTER(ctypes.c_char))]

result = ctypes.windll.crypt32.CryptUnprotectData(
    ctypes.byref(input_blob), None, None, None, None, 0,
    ctypes.byref(output_blob)
)

Result: CryptUnprotectData failed

Why: Chrome 127+ (July 2024) introduced app-bound encryption. The decryption key is now bound to the Chrome binary itself. External programs — even running as the same user — can't decrypt cookies anymore.

Attempt #2: rookiepy

rookiepy is a Rust-based Python library built specifically for extracting browser cookies. It handles modern Chrome encryption:

import rookiepy
cookies = rookiepy.chrome([".youtube.com", ".google.com"])

Ran it as Administrator.

Result: RuntimeError: decrypt_encrypted_value failed

Why: Same app-bound encryption. Even with admin privileges, no external process can access Chrome's cookie encryption key on Chrome 127+.

Attempt #3: Chrome DevTools Protocol (CDP)

If you can't decrypt cookies externally, maybe ask Chrome directly. Chrome's DevTools Protocol has Network.getAllCookies:

ws.send(json.dumps({"id": 1, "method": "Network.getAllCookies"}))
cookies = json.loads(ws.recv())["result"]["cookies"]

This requires starting Chrome with --remote-debugging-port=9222.

Result: TCP connect to (127.0.0.1 : 9222) failed

Why: On Windows, if Chrome is already running, a new instance with the debug flag opens as a window in the existing process — without the debugging port. I killed Chrome, restarted with the flag. Chrome still wouldn't bind to port 9222. Possibly Windows Defender or a Chrome policy blocking it.

Attempt #4: yt-dlp Native OAuth2

yt-dlp added native OAuth2 support in 2024. It uses YouTube TV's device code flow:

yt-dlp --username oauth2 --password '' https://youtu.be/...
# Go to google.com/device and enter code: XXXX-XXXX

Result: Login with OAuth is no longer supported

Why: YouTube deprecated this authentication method. It worked for a few months, then Google killed it. The yt-dlp wiki now says: "Use --cookies instead."

Attempt #5: Per-User OAuth Bearer Token

My app already had Google OAuth for YouTube uploads. Users sign in, I get their access_token. Why not pass it to yt-dlp?

cmd.extend(["--add-header", f"Authorization:Bearer {access_token}"])

Result: Request had insufficient authentication scopes

Why: yt-dlp uses YouTube's InnerTube API internally, not the YouTube Data API v3. They're completely different authentication systems:

API	Authentication	Used by
YouTube Data API v3	OAuth2 Bearer token	App uploads
YouTube InnerTube API	Session cookies	yt-dlp downloads

A Data API token simply can't authenticate InnerTube requests.

Attempt #6: Firefox 🏆

After 5 failures with Chrome, I tried Firefox.

Firefox doesn't encrypt cookies.

Firefox stores cookies in a plain SQLite database at %APPDATA%/Mozilla/Firefox/Profiles/*/cookies.sqlite. No DPAPI. No AES-GCM. No app-bound encryption. Just SQL:

import sqlite3, shutil, glob, os

profiles = os.path.join(os.environ["APPDATA"], "Mozilla", "Firefox", "Profiles")
db = max(glob.glob(f"{profiles}/*/cookies.sqlite"), key=os.path.getsize)

shutil.copy2(db, "tmp.sqlite")  # Copy — Firefox locks the file
conn = sqlite3.connect("tmp.sqlite")

rows = conn.execute(
    "SELECT host, name, value, path, expiry, isSecure "
    "FROM moz_cookies WHERE host LIKE '%youtube%' OR host LIKE '%google%'"
).fetchall()

print(f"✅ {len(rows)} cookies extracted")

Result: ✅ 67 cookies saved

10 lines of Python. No admin rights. No encryption libraries. No fighting the browser.

The Scoreboard

#	Method	Blocked by	Time
1	DPAPI + AES-GCM	Chrome 127+ app-bound encryption	30 min
2	rookiepy (Rust lib)	Same encryption, even as admin	15 min
3	Chrome DevTools Protocol	Port 9222 wouldn't bind	40 min
4	yt-dlp OAuth2	Deprecated by YouTube	20 min
5	Per-User Bearer token	Wrong API (InnerTube ≠ Data API)	30 min
6	Firefox SQLite	Nothing	5 min

Hypothesis vs Reality

What I expected	What actually happened
Cookie extraction is a solved problem	Chrome made it unsolvable in July 2024
Admin rights bypass any protection	App-bound encryption ignores admin
OAuth tokens work across Google APIs	InnerTube ≠ Data API
yt-dlp has built-in auth	YouTube deprecated it
Chrome extensions export cookies safely	The most popular one was malware
It should take 10 minutes	It took 3 hours

Why Chrome Does This

Chrome's app-bound encryption exists for a good reason: protecting users from cookie-stealing malware. Before Chrome 127, any program running as the same Windows user could read all Chrome cookies — login sessions, banking tokens, everything.

Google's fix: bind the decryption key to the Chrome binary. Only Chrome's own process can decrypt cookies. This blocks Raccoon, RedLine, Vidar, and all similar stealers.

The collateral damage: legitimate tools like yt-dlp, password managers, and cookie exporters also break.

Firefox took a different approach: cookies are plain SQLite, and security relies on OS-level protections — file permissions and user isolation. Neither approach is objectively better. Chrome prioritizes defense against same-user malware. Firefox prioritizes interoperability.

The Deployment

After extracting cookies, deployment was straightforward:

# Extract on local machine (Windows)
python extract_cookies.py
# → cookies.txt (67 YouTube/Google cookies, Netscape format)

# Upload to server
scp cookies.txt user@server:/opt/app/backend/

yt-dlp uses them automatically:

COOKIES_FILE = Path(__file__).parent / "cookies.txt"

cmd = ["yt-dlp", "-f", "bestvideo+bestaudio", ...]
if COOKIES_FILE.exists():
    cmd.extend(["--cookies", str(COOKIES_FILE)])

Trade-off: Cookies expire in ~2 weeks. When they do: open Firefox, visit YouTube, close Firefox, re-run the script. 60 seconds.

Key Takeaways

Start with Firefox. Chrome's encryption makes external cookie extraction impossible since July 2024.
Never install cookie-export extensions. The popular "Get cookies.txt" was literal malware. Read the SQLite database directly.
Check the timeline. Any cookie extraction tutorial from before Chrome 127 (mid-2024) won't work on modern Chrome.
InnerTube ≠ Data API. If you're building around yt-dlp, Google OAuth tokens from your app won't help — yt-dlp needs browser cookies, not API tokens.
Don't fight the browser. When a browser actively resists external access, use a browser that doesn't.

Where It Stands Now

Component	Status
Cookie extraction (Firefox)	✅ Working
yt-dlp downloads with cookies	✅ Working
Server deployment	✅ Deployed
YouTube upload after merge	✅ OAuth2
Cookie auto-refresh	❌ Manual (every ~2 weeks)

The extraction script and the full project are open source: github.com/maximosovsky/merge-video

This is part of a series about building Merge Video — a self-hosted video merging service. Previous: I Tried to Merge 52 Video Files Automatically.

Building in public, one utility at a time. Follow the journey: LinkedIn · GitHub

7 Failed Attempts to Create One Cloud Server on Alibaba Cloud

Maxim Osovsky — Sun, 01 Mar 2026 16:54:00 +0000

This is Part 3. Part 1 covered 3 bugs in the video merging engine. Part 2 was about Oracle Cloud's "Always Free" servers that don't exist. This one is about what happened when I tried Alibaba Cloud instead.

Why Alibaba Cloud?

I run long strategy sessions — 6 to 8 hours each — where we plan product roadmaps, discuss architecture, and make decisions on camera. Each session produces 30 to 50 short video clips that need to be merged into one continuous video.

I offered $2,000 to a developer to build a service that merges videos and uploads them to YouTube. They turned it down — didn't see the problem it solved. Multiple developers refused. So I built Merge Video myself — with AI as my pair programmer, in 3 days, for $0 in development costs. The code works. Now I needed to put it on a server.

In Part 2 I deployed the Telegram bot to Fly.io — 256 MB RAM, just enough for polling. But the backend needs ffmpeg, yt-dlp, and enough RAM to merge 50+ video files. It needs a real VPS.

Oracle Cloud? Dead to me. AWS/GCP? No free tier for what I need. Hetzner? Great, but I already had Alibaba Cloud API keys — left over from WallPlan, my calendar generator that I once deployed to Alibaba Cloud OSS through DeployBridge. Those keys were still active. An ECS instance with 2 vCPU and a few GB of RAM — how hard could it be?

Seven attempts hard.

No Console. Only Terminal.

One important detail: I never opened the Alibaba Cloud web console. Not once. The entire process — VPC creation, Security Groups, image search, instance provisioning, IP allocation — was done through the Alibaba Cloud ECS SDK via Node.js scripts running in my terminal.

Why? Because I script my deployments. The same API keys from the WallPlan project that went through DeployBridge — a deployment tool I built for moving sites from Vercel to cheaper hosting — were reused here with zero additional setup.

Attempt #1: Frankfurt, Wrong Image

I picked Frankfurt (eu-central-1) — closest to me. Wrote a Node.js script using the Alibaba Cloud ECS SDK to automate everything: VPC, VSwitch, Security Group, instance.

The VPC and VSwitch created fine. The Security Group created fine. Then:

Finding Ubuntu 22.04 image...
Image: ubuntu_22_04_arm64_20G_alibase_20260119.vhd

Wait — arm64? I asked for ecs.c6.large, which is x86. The SDK returned the ARM image first.

Error: InvalidInstanceType.NotSupported
The specified instanceType is not supported by the image architecture.

Lesson: Alibaba's image search doesn't filter by architecture unless you explicitly ask.

Attempt #2: Frankfurt, No Ubuntu at All

I added architecture: 'x86_64' to the image search. The result?

Error: No Ubuntu image found

Frankfurt has zero x86 Ubuntu images. Only ARM. The entire region. I listed all available images:

debian_12_13_x64_20G_alibase_20260120.vhd: Debian 12.13 64位
centos_stream_9_x64_20G_alibase_20260120.vhd: CentOS Stream 9
aliyun_4_x64_20G_alibase_20260120.vhd: Alibaba Cloud Linux 4

No Ubuntu. Fine — Debian 12 is basically Ubuntu without Canonical. I switched to Debian.

Attempt #3: Frankfurt, Zone Not for Sale

3. Creating ECS (ecs.c6.large, 2vCPU, 4GB)...
Error: Zone.NotOnSale
The specified zone is not available for purchase.

The entire Frankfurt zone doesn't sell ecs.c6.large. Not out of stock — not available for purchase. The instance type doesn't exist there for PayAsYouGo.

That's when I abandoned Frankfurt entirely and switched to Singapore (ap-southeast-1).

Attempt #4: Singapore, Wrong Disk

Singapore accepted my VPC, VSwitch, Security Group. Found Debian 12. Instance type available. Progress!

3. Creating ECS (ecs.c6.large, 2 vCPU, 4 GB)...
Error: InvalidDiskCategory.NotSupported
The specified disk category is not supported.

cloud_efficiency — not supported. Changed to cloud_essd. Still not supported. Changed to cloud_ssd. Still not supported.

Three disk types. All rejected. For the same instance type.

Attempt #5: Singapore, Instance Doesn't Exist

I queried DescribeAvailableResource (should have done this from the start). The shocking result:

ecs.c6.large — not found in any Singapore zone

ecs.c6.large doesn't exist in Singapore. Not out of stock — the instance type isn't offered. Only ecs.c6t (trusted) and ecs.c6r (ARM) variants.

Attempt #6: Singapore, ARM Again

I tried ecs.c6r.large — thinking "r" meant "regular."

Error: InvalidInstanceType.NotSupported
The specified instanceType is not supported by the image architecture.

"r" means ARM. My Debian image was x86. Architecture mismatch. Again.

Attempt #7: Singapore, KMS Required

I switched to ecs.c6t.large — "t" for "trusted." Should work with x86, right?

Error: InvalidParameter.KmsNotEnabled
Failed to perform this operation because KMS is not activated.

Trusted instances require KMS (Key Management Service) — a separate service that needs activation. I just wanted a Linux box.

The scorecard after 7 attempts

#	Region	Instance	Image	Disk	Error
1	Frankfurt	ecs.c6.large	Ubuntu ARM	—	Wrong architecture
2	Frankfurt	ecs.c6.large	—	—	No Ubuntu x86 exists
3	Frankfurt	ecs.c6.large	Debian x86	cloud_efficiency	Zone not for sale
4	Singapore	ecs.c6.large	Debian x86	cloud_*	Disk not supported
5	Singapore	ecs.c6.large	—	—	Instance type doesn't exist
6	Singapore	ecs.c6r.large	Debian x86	—	ARM instance, x86 image
7	Singapore	ecs.c6t.large	Debian x86	cloud_essd	KMS not activated

7 API calls. 7 different errors. 0 servers.

The Fix: Query First, Create Second

I finally wrote what I should have written from the start — a probe script that checks everything before creating anything:

// 1. Find instance types with stock
const res = await ecs.describeAvailableResource({
  regionId: 'ap-southeast-1',
  destinationResource: 'SystemDisk',
  instanceChargeType: 'PostPaid',
  instanceType: type,
});

// 2. Find zones with stock
// 3. Find compatible disk categories
// 4. Find matching VSwitch or create one
// 5. THEN create the instance

The script tested 4 candidate instance types across all zones. In seconds, it found what worked:

FOUND: ecs.t6-c1m4.large in ap-southeast-1c with cloud_efficiency

ecs.t6-c1m4.large — a burstable type I'd never heard of. Zone C — not the default zone the SDK picked. cloud_efficiency — the same disk type that was rejected for ecs.c6.large two attempts earlier.

One probe. One working combination. Instance created in 30 seconds.

Instance: i-xxxxxxxxxxxxxxxxxxxx
IP:       203.0.113.42
SSH:      ssh root@203.0.113.42

Deploying the Backend

With the server finally alive, I piped a setup script via SSH. The script creates a dedicated deploy user — the backend runs under that account, not root:

# Convert CRLF → LF (Windows → Linux)
$content = [IO.File]::ReadAllText("deploy/remote-setup.sh")
$lfContent = $content -replace "`r`n", "`n"
[IO.File]::WriteAllText($temp, $lfContent)
Get-Content $temp -Raw | ssh root@203.0.113.42 "bash -s"

The script installed everything in 3 minutes:

apt install -y python3 python3-venv ffmpeg nginx git
python3 -m venv /opt/merge-video/venv
pip install -r backend/requirements.txt
systemctl enable merge-video
systemctl start merge-video

● merge-video.service - Merge Video Backend (FastAPI)
     Active: active (running)
     Memory: 106.1M

106 MB. Running. After 7 failed attempts and one working probe.

What I Learned

What I assumed	What's actually true
`ecs.c6.large` exists everywhere	It exists in some regions, some zones
Ubuntu is always available	Frankfurt has zero x86 Ubuntu images
Disk types are universal	Each instance type supports different disks
"c6r" means regular	It means ARM
"c6t" means standard	It means trusted (requires KMS)
You can guess and retry	You must query `DescribeAvailableResource` first

The real takeaway

Alibaba Cloud's API is a compatibility matrix, not a catalog.

Unlike AWS where t3.micro works everywhere with any disk, Alibaba Cloud has per-zone, per-type, per-disk compatibility rules that aren't surfaced in the console or documentation. The only way to know what works is to call DescribeAvailableResource and cross-reference instance types, zones, disk categories, and image architectures.

One API call would have saved me 7 failed attempts.

Where It Stands Now

Component	Status
Web app — merge & download	✅ Working
Telegram bot	✅ Fly.io (256 MB, stable)
Backend (FastAPI + ffmpeg)	✅ Alibaba ECS Singapore (2 vCPU, 8 GB RAM)
Email notifications	✅ Gmail API
YouTube upload	✅ OAuth2
SSL + domain	⏳ Next: `merge-video.osovsky.com`
YouTube auth via bot	⏳ After backend goes public

Try It

The project is open source: github.com/maximosovsky/merge-video

Or send YouTube links to the Telegram bot: @MergeVideoBot

This is Part 3. Part 1 covered 3 bugs in the video merging engine. Part 2 was about Oracle Cloud. Next: connecting DNS, SSL, and YouTube auth through the bot.

Ever had a cloud provider reject 7 different configurations in a row? I'd love to hear your worst. Comments are open.

Building in public, one utility at a time. Follow the journey: LinkedIn · GitHub

3 Deployment Fails That Made Me Quit Oracle Cloud Forever

Maxim Osovsky — Sat, 28 Feb 2026 16:54:00 +0000

This is Part 2. Part 1 covered 3 bugs I hit while building the video merging engine. This one is about what happened when I tried to put it online.

The Plan That Looked Too Good

In Part 1 I built Merge Video — a service that merges dozens of video files using ffmpeg and uploads the result to YouTube. I film long strategy sessions — 6 to 8 hours each — and end up with 30–50 clips per session that need to be merged into one video. It worked on my machine. Now I needed to deploy the Telegram bot so it runs 24/7 without my laptop being open.

Two requirements:

Free — at the prototype stage, free tier makes the most sense. Cloud providers offer generous free tiers specifically for this use case — validating ideas before committing budget. Once there's real traffic and real users, paying for infrastructure is a no-brainer. But spending money before product-market fit is just burning runway
Persistent — a long-polling bot needs to stay alive, not sleep after 15 minutes of inactivity like Render's free tier

Oracle Cloud Free Tier looked perfect on paper: 4 ARM CPUs, 24 GB RAM, 200 GB disk — free forever. Not a trial. Not 12 months. Forever.

I signed up, picked a datacenter, and started creating a VM.

What followed was the most frustrating 2 hours I've had with any cloud provider.

Fail #1: The Server That Doesn't Exist

I selected the best free shape — VM.Standard.A1.Flex (ARM, 4 CPUs, 24 GB RAM). Configured everything. Hit Create.

API Error:
Out of capacity for shape VM.Standard.A1.Flex in availability domain AD-1.
Create the instance in a different availability domain or try again later.

No ARM instances available. The datacenter was fully packed. All of them. Taken.

Fine — fallback plan. I switched to the weaker x86 shape: VM.Standard.E2.1.Micro (1 CPU, 1 GB RAM). Not great for video processing, but enough for a Telegram bot.

Same error:

Out of capacity for shape VM.Standard.E2.1.Micro in availability domain AD-1.

Both free shapes — zero availability. The "Always Free" tier had no servers to give me. The marketing page promises 24 GB of RAM. The reality is a queue with no ETA.

Online advice says: "Try early morning (5–7 UTC), capacity comes in waves." Some people write scripts that poll the Oracle API every 5 minutes, for days, waiting for a slot to open.

I didn't want to write a bot to get a server to run my bot.

Fail #2: The Checkbox That Won't Check

Before the capacity error killed my attempt entirely, I spent 40 minutes fighting Oracle's VM creation UI.

The problem: the "Automatically assign public IPv4 address" checkbox was grayed out. Without a public IP, the server is invisible to the internet — no SSH access, no Telegram connection, nothing.

I stared at it. Refreshed the page. Tried a different browser. The checkbox wouldn't budge.

The root cause? When you create a new subnet inline during VM creation, Oracle's UI doesn't recognize it as "public" — even though you explicitly selected "Create new public subnet." The UI disagrees with itself.

The workaround I had to discover myself

Cancel VM creation entirely
Navigate to Networking → Virtual Cloud Networks → Start VCN Wizard
Run the wizard to create a VCN with internet connectivity
Go back to Compute → Create Instance
Select the existing VCN → existing public subnet
Now the checkbox works

Three separate pages. A wizard inside a wizard. To enable a checkbox that should have worked from the start.

I spent 40 minutes on this before discovering I couldn't get a server anyway.

Fail #3: One Card, One Life

After getting the capacity error on both shapes, I thought: what if the problem is this specific datacenter? Some regions have more available servers than others.

I couldn't change regions on my existing account — Oracle locks your home region at signup. So I went all in: registered a second account with a different Gmail address (not even an alias — Oracle didn't accept + aliases). Used a Regus coworking address in Tilburg, Netherlands as my billing address. Used my second phone number for verification.

Different email. Different address. Different phone. Made it through the entire signup flow. Got to the payment verification step. Entered my card.

Error: You already have an account with a different email address.
Oracle allows one promotion per person.

This was the moment I was done.

Oracle links your identity to your card number. One card = one account = one datacenter = zero servers. Different email doesn't matter. Different address doesn't matter. Different phone doesn't matter. You get one shot, and if your datacenter is full — tough luck.

No retry. No workaround. No path forward.

The scorecard after 2 hours with Oracle Cloud

What I tried	Result
ARM shape (A1.Flex, 4 CPU, 24 GB)	❌ Out of capacity
x86 shape (E2.1.Micro, 1 CPU, 1 GB)	❌ Out of capacity
Public IPv4 checkbox	❌ Grayed out (UI bug)
Manual VCN + public subnet	✅ Fixed the checkbox
VM creation after VCN fix	❌ Still out of capacity
Second account (new email, new address, new phone)	❌ Blocked by card
Total time	2 hours
Total servers	0
Total RAM obtained	0 bytes

The Pivot: Fly.io in 10 Minutes

I closed Oracle's console and opened Fly.io.

No VMs. No VCN wizards. No availability domains. Just a Dockerfile and a CLI.

fly auth login
fly launch --no-deploy
fly secrets set BOT_TOKEN="..."
fly deploy

10 minutes. DNS verified. App live at merge-video-bot.fly.dev. aiogram connected to Telegram Bot API. Bot started polling.

	Oracle Cloud	Fly.io
Time to deploy	2 hours	10 minutes
Result	0 servers	1 running bot
UI complexity	6 pages, 2 wizards	4 CLI commands
Account tricks needed	Second email, Regus address, second phone	GitHub login

Everything worked.

And it's been running stable since.

What I Learned

What I expected	What actually happened
Oracle Free Tier = free server	Free tier with zero available servers
"Always Free" means always available	Means always free if you can get one
Oracle Cloud UI is enterprise-grade	3-page workaround for a single checkbox
Different email + address + phone = new account	One card = one account, forever
Deploy takes 30 minutes	Oracle: 2 hours → nothing. Fly.io: 10 minutes → working

Where It Stands Now

Component	Status
Web app — merge & download	✅ Working
Telegram bot	✅ Deployed on Fly.io (256 MB, stable)
Email notifications	✅ Gmail API
YouTube upload	✅ OAuth2
Stress test (52 files, 13 GB)	✅ Passed
Backend deployment	❌ Still localhost
YouTube auth via bot	❌ Needs deployed backend

Try It

The project is open source: github.com/maximosovsky/merge-video

Or send YouTube links to the Telegram bot: @MergeVideoBot

This is part 2. Part 1 covered 3 bugs in the video merging engine. Next: deploying the backend and connecting YouTube auth through the bot.

Ever been burned by a "free" cloud? Drop your horror story in the comments.

Building in public, one utility at a time. Follow the journey: LinkedIn · GitHub

I Tried to Merge 52 Video Files Automatically. Here Are 3 Bugs That Almost Killed the Project

Maxim Osovsky — Fri, 27 Feb 2026 16:54:00 +0000

The $1,500 Problem

I film long strategy sessions — 6 to 8 hours each. When you record for that long, things go wrong. The battery dies. The power goes out. And when it does, the entire file gets corrupted.

So I set my camera to record in short segments — about 20 minutes each. Safe, but now I have 52 separate video files after every session that I need to merge into one.

I used to outsource this. Send files to an editor, wait, pay. Over the years I've spent at least $1,500–2,000 just on merging clips — not editing, not color grading, just joining files together.

In 2022 I decided to build my own service. I called it Merge Video.

The Road Here: 3 Failed Attempts

This isn't v1. I've been trying to solve this problem since 2022 — across three separate repositories:

Version	Stack	What happened
v1 — Merge-video.online	Node.js, Telegraf, youtube-dl, ffmpeg	Worked on AWS EC2 but died with the server. Single 424-line file
Landing page	Umso no-code builder, GitHub Pages	Static promo page
v2 — Microservices	Python, aiogram, Flask, FastAPI	Ambitious: 3 microservices, payments, Google Drive delivery. Pytube broke when YouTube changed their API

The original idea was fully cloud-based: take videos from YouTube or Google Drive, merge them on the server, upload back to YouTube — without ever touching the local machine. It worked for small files, but my real problem was 52 local recordings sitting on a hard drive.

Multiple developers refused to work on this project. They didn't see the problem it solved — "just use a video editor." One developer turned down a $2,000 offer to automate the pipeline.

The current version — merge-video — consolidates all three repos into one and adds what was always missing: local file upload and merge. I rebuilt the frontend and backend in 3 days with the help of Antigravity, an AI coding assistant by Google DeepMind. What took months of failed outsourcing now took a weekend of focused work.

What I Built

The idea is simple: send links or upload files, go to sleep, wake up to a merged video on YouTube and a link in your email.

No manual work. No editor. No waiting at the screen.

Feature	How it works
YouTube URLs	Paste links → yt-dlp downloads → ffmpeg merges
Local files	Drag & drop up to 100 files → server merges
YouTube upload	Merged result uploads to your channel via OAuth
Email notifications	📧 Auth → Start → Done/Error — all sent via Gmail API
Telegram bot	Send YouTube links to @MergeVideoBot
3 quality modes	Compact (CRF 23) · High Quality (CRF 18) · Lossless (concat demuxer)

The "Email Bot" Concept

I started with a Telegram bot — it was the quickest way to build an interface. But I realized: not everything should live inside Telegram.

What I really wanted was an email bot. Not a chatbot. The idea:

You submit files or links through the web app
You close the browser and go to sleep
The server does everything in the background
You wake up to an email: 🎬 Your merged video is ready! ▶ View on YouTube

The merge runs on the server regardless of whether the browser is open. Gmail API sends you status updates at every step — authorization, job start, completion, and errors. All from your own Gmail, to your own Gmail. No SMTP servers, no third-party email services.

Architecture

Browser / Telegram Bot
        ↓
   FastAPI Backend
        ↓
  ┌─────────────┐
  │  Job Queue   │ ← async single-worker
  │  (in-memory) │
  └──────┬──────┘
         ↓
  yt-dlp → ffmpeg → YouTube API
         ↓
  Gmail API → email notification

Stack: Python 3.12, FastAPI, ffmpeg, yt-dlp, aiogram 3, Google OAuth2

The Stress Test: 52 Files, 13 GB

Everything worked fine on small tests — 2 files, 40 MB each, merged in a minute. So I ran the real thing: 52 video files, 13 GB total.

Three things broke. Every one of them taught me something.

Bug #1: ffmpeg Choked on 52 Mixed-Format Files

What happened

I fed ffmpeg a single command with 52 inputs using filter_complex. Some files were 4K (3840×2160), others were 1080p, and some had no audio track. ffmpeg crashed:

Input link in0:v0 parameters (size 1920x1080, SAR 1:1) do not match
the corresponding output link parameters (3840x2160, SAR 1:1)

The concat filter requires all inputs to have identical parameters — same resolution, same codec, same audio format. With 52 random files, that's never the case.

What I tried first

Added scale and pad filters to normalize everything to 1920×1080 inside the same massive filter_complex. Still crashed — the filter graph with 52 inputs was too complex and fragile.

What actually worked: Two-Pass Merge

I completely changed the approach:

Pass 1 — Normalize each file independently:

for i, f in enumerate(files):
    print(f"  📦 Normalizing {i+1}/{len(files)}: {f.name}")
    # Scale to target resolution with letterbox
    # Add silent audio if missing (detected via ffprobe)
    # Re-encode to uniform h264/aac format

Pass 2 — Concat demuxer (no re-encoding):

# Write file list
for nf in normalized_files:
    list_file.write(f"file '{nf}'\n")

# Merge without re-encoding — instant
cmd = ["ffmpeg", "-f", "concat", "-safe", "0", "-i", list_path,
       "-c", "copy", str(output)]

This gave me a bonus I didn't expect: visible progress. Instead of a silent 30-minute ffmpeg run, I could see 📦 Normalizing 1/52... 2/52... 3/52... in the terminal. Debugging became trivial — if file #37 fails, you know exactly which one.

The lesson

When a single-step pipeline breaks under scale, don't fix the step — split it into stages. Each stage is simpler, debuggable, and independently testable.

Bug #2: 13 GB of stderr Crashed Python

What happened

The merge ran for a few minutes, then:

Exception in thread Thread-2 (_readerthread):
MemoryError

This wasn't ffmpeg failing. It was Python's subprocess.run trying to read ffmpeg's stderr output into memory. When processing 13 GB of video, ffmpeg writes progress for every single frame to stderr — that's gigabytes of text output.

Why it worked on small files

With 2 files totaling 80 MB, ffmpeg's stderr output was maybe a few kilobytes. subprocess.PIPE handled it fine. At 13 GB and thousands of frames? Python ran out of memory before ffmpeg even finished.

The fix

Redirect stdout and stderr to temp files on disk instead of memory pipes:

async def _run(cmd, cwd=None):
    def _sync_run():
        with tempfile.NamedTemporaryFile(delete=False) as out_f, \
             tempfile.NamedTemporaryFile(delete=False) as err_f:
            result = subprocess.run(cmd, cwd=cwd,
                                    stdout=out_f, stderr=err_f)
            # On error, read only the last 4KB of stderr
            if result.returncode != 0:
                err_f.seek(max(0, err_f.tell() - 4096))
                raise RuntimeError(err_f.read().decode())
    await asyncio.to_thread(_sync_run)

The lesson

subprocess.PIPE is a time bomb for long-running processes. If you can't predict the output size, write to files. This is standard in DevOps but easy to miss in application code.

Bug #3: `asyncio.create_subprocess_exec` Doesn't Work on Windows

What happened

The first time I tried to merge anything:

❌ Error: NotImplementedError()

asyncio.create_subprocess_exec requires ProactorEventLoop on Windows. But uvicorn (the ASGI server running FastAPI) sets its own event loop policy and overrides mine.

What I tried first

# Tried setting the policy in main.py — uvicorn overwrites it
if sys.platform == "win32":
    asyncio.set_event_loop_policy(asyncio.WindowsProactorEventLoopPolicy())

Didn't work. Uvicorn ignores this and uses its own loop.

What actually worked

Gave up on asyncio.create_subprocess_exec entirely. Used synchronous subprocess.run wrapped in asyncio.to_thread:

async def _run(cmd, cwd=None):
    def _sync_run():
        return subprocess.run(cmd, cwd=cwd, ...)
    await asyncio.to_thread(_sync_run)

Less elegant than native async subprocess, but it works on every platform without fighting the ASGI server.

The lesson

"Correct by documentation" ≠ "works in your stack." When two frameworks fight over the event loop, sometimes the pragmatic solution beats the elegant one.

What I Learned

What I expected	What actually happened
ffmpeg handles any number of inputs	52 mixed-format files = crash
`subprocess.PIPE` is fine for any process	13 GB of stderr = MemoryError
`asyncio.create_subprocess_exec` is cross-platform	Windows + uvicorn = NotImplementedError
Small test = production-ready	Small test hides 3 critical bugs

Timeline

Year	Milestone
2022	v1 — Node.js Telegram bot on AWS EC2. Worked but fragile
2023	v2 — Python microservices, payments. External dependencies killed it
2023	Landing page — Umso builder, Product Hunt links
2024	Multiple developers decline the project. $2,000 offered and refused
2026	Current version — rebuilt in 3 days with AI. FastAPI + yt-dlp + ffmpeg + Gmail + YouTube OAuth

Where It Stands Now

This is a build-in-public project. Some things work, some don't yet:

Component	Status
Web app — merge & download	✅ Working
Telegram bot	✅ Deployed on Fly.io
Email notifications	✅ Gmail API
YouTube upload	✅ OAuth2
Stress test (52 files, 13 GB)	✅ Passed
Large file upload via HTTP	❌ Hangs on 13 GB
Credentials persistence	❌ Lost on server restart
Backend deployment	❌ Still localhost

The project is open source: github.com/maximosovsky/merge-video

Try It

git clone https://github.com/maximosovsky/merge-video.git
cd merge-video/backend
pip install -r requirements.txt
python main.py
# Open http://localhost:8000

Or send YouTube links to the Telegram bot: @MergeVideoBot

This is part 1. The 3 bugs above were just the beginning — I've already hit new ones while deploying and stress-testing. I'll write about those next.

Building something similar? Hit me up in the comments — I'd love to compare notes.

Building in public, one utility at a time. Follow the journey: LinkedIn · GitHub

Why the Boston Metro Map Designer Built Me a Calendar

Maxim Osovsky — Thu, 26 Feb 2026 16:44:00 +0000

In 2012, I printed my first multi-year calendar. Two years on one sheet — because the publishing industry only makes calendars for the next 12 months, and I needed to plan further.

I gave copies to friends and colleagues. One of them — Evgeniya Shamis, a generations researcher — filmed herself using it. She pinned it to her wall and started marking deadlines across both years. That was the first signal: people actually want to see more than 12 months at a glance.

The calendar was published through Scriber in the Russian «Жить интересно!» magazine. But every new year meant manual layout work. I needed a generator.

The Boston Metro Connection

In 2020, Michael Kvrivishvili — the designer of the official Boston Metro map — built a calendar generator specifically for me. His tool used pdfmake to create PDFs directly in the browser: you set the number of months and Gantt rows, and it rendered a printable document.

It worked. But it was a black box — pdfmake handles all the layout internally, so I couldn't control positioning down to the millimeter. And when I started printing on 914mm engineering paper rolls, millimeters mattered.

So I rewrote it. From scratch. In pure SVG.

What WallPlan Does

WallPlan is a browser-based multi-year calendar generator. You choose a duration (1 month to 20 years), a paper format, and a number of Gantt rows — and it renders a printable calendar in three views:

View	What It Shows
Vertical	Days listed vertically per month — classic planner layout
Gantt	Horizontal day grid with project rows — timeline planning
Box	Traditional 7×5 mini-month grids with week numbers

All three views render as SVG. You export to SVG or PDF for printing.

Paper Formats

Format	Use Case
A4 / A3	Standard office printing
914mm roll	Engineering plotter — unlimited length, 1m wide
914mm ×2	Two calendars on one roll
914mm ×4	Four mini-calendars side by side

Yes, I print multi-year calendars at copy centers on engineering paper rolls. A 5-year Gantt calendar on a single continuous sheet, pinned to a wall. That's how I use it for strategic planning.

Zero Dependencies, Three Files

index.html    — 22 KB (toolbar, modals, mobile UI, welcome carousel)
calendar.js   — 80 KB (SVG renderer, viewport, export, touch support)
style.css     — 20 KB (all styling, responsive, print CSS)

No React. No build step. No npm install. One npx -y serve -l 3456 and you're running.

The SVG renderer calculates every coordinate manually — month column widths, day cell sizes, Gantt row heights, page breaks. It's ~2000 lines of vanilla JavaScript that produce pixel-perfect output for any paper format.

Why SVG Over Canvas?

Vector output — PDF stays crisp at any zoom, prints cleanly on plotters
Pan and zoom — the viewport supports one-finger drag and pinch-to-zoom
Batch path optimization — thousands of grid lines are merged into 4 <path> elements instead of individual <line> elements
Lazy PDF export — jsPDF + svg2pdf.js (~500KB) load only when you click Download

Seven weights of IBM Plex Sans are fetched in parallel and embedded as base64 into the PDF. The visual style is deliberately Moleskine-inspired: warm cream background, thin ink-like lines, condensed typography.

The PDF That Looked Perfect But Printed Garbage

Here's an engineering horror story.

I generated a PDF — A4, 12 months, 12 Gantt rows. Opened it in Chrome: perfect. Sent it to a colleague via Telegram: preview looked great. Hit Print on a plotter: complete garbage. Vertical lines smashed together into an unreadable mess.

The culprit: batch path optimization.

To keep the SVG lightweight, I merge all grid lines into a few <path> elements with thousands of M/V/H draw commands:

M150.3 400V520 M150.55 400V520 M150.8 400V520...

Chrome's PDF renderer (PDFium/Skia) handles this flawlessly. But the plotter's RIP (Raster Image Processor) — with its limited firmware — chokes on paths with 3000+ commands. Coordinates lose precision after hundreds of operations, and lines collapse into each other.

The PDF was technically valid but too complex for certain printers. Like a website that works in Chrome but breaks in Internet Explorer.

The fix? Still exploring options — from splitting batch paths into smaller chunks, to canvas rasterization at 300 DPI, to a parallel PDFKit renderer. The original pdfmake approach from Michael's version never had this problem because pdfmake generates native PDF table elements, not converted SVG paths.

Month Colors — The Temperature Palette

Each month can be shaded with a seasonal color palette inspired by Johannes Itten's color wheel. Warm months get warm tones, cold months get cool tones. Toggle it with &c=1 in the URL.

The palette follows a temperature curve: January is deep blue, July is warm amber, and transitions flow through greens and oranges. It's subtle — just enough color to visually separate months at a glance without overwhelming the print.

Custom Entries

Add birthdays, deadlines, or recurring events directly on the calendar:

DD.MM  Your text here

Entries appear as markers on the corresponding day. Set them to repeat annually, and they show up every year across your entire multi-year span. No login, no cloud — entries live in the URL parameters and localStorage.

Miro Integration

WallPlan doesn't just live in the browser. It has a full Miro App that generates calendars as native Miro board elements — not images, but real text objects, shapes, and frames that you can move, edit, and annotate.

The architecture made this possible: WallPlan's SVG renderer calculates explicit (x, y, width, height) coordinates for every element. The Miro version reuses the same data layer (calendar-engine.ts) and maps coordinates to miro.board.createText() / miro.board.createShape() calls.

There's also a Miroverse template — a ready-made 2-year Gantt calendar board that anyone can duplicate.

This is something none of the competitors offer. Calidar.io has beautiful PDF calendars. Kruglendar has elegant circular layouts. Notion Planners sell templated planners on Etsy. But none of them generate native, editable calendar objects inside a collaborative whiteboard.

The LifeLine Connection

WallPlan shares its rendering engine with LifeLine, my life timeline visualization tool. Same SVG core, same viewport system, same IBM Plex Sans fonts, same PDF pipeline.

WallPlan → years × months (planning ahead)
LifeLine → decades × life categories (looking back and forward)

The SVG rendering approach proved in WallPlan — manually calculated coordinates, batch path optimization, lazy PDF export — became the foundation for a completely different product.

From 2012 to Now

Year	Milestone
2012	First 2-year calendar printed and distributed
2013	Published in «Жить интересно!» magazine
2017	Methodology presented at conferences
2020	Michael Kvrivishvili builds the pdfmake generator
2024	Full rewrite to SVG — WallPlan is born
2025	Miro App, month colors, custom entries, mobile UI
2026	Open source on GitHub

Fourteen years from a hand-made calendar to a production tool. The core idea never changed: see more than 12 months at once.

Try It

Live: osovsky.com/wallplan
GitHub: github.com/maximosovsky/wallplan
Miro template: 2-Year Timeline Gantt Calendar

npx -y serve -l 3456  # Open http://localhost:3456

Building in public, one repo at a time. Follow the journey: LinkedIn · GitHub

I Built a Life Timeline Tool That Coaches Say You Shouldn't Use

Maxim Osovsky — Wed, 25 Feb 2026 16:44:00 +0000

In coaching, drawing lifelines is considered taboo. They say it frustrates people — forces them to confront gaps, failures, missed decades.

I'm not a coach. I'm a strategy consultant. And in strategic sessions, we draw timelines with organizations all the time. One day I thought: why not apply the same tool to personal strategy?

So I started drawing lifelines on paper with real participants. Decades across the top, life categories down the side, colored markers for events. It worked. People saw their entire life at a glance — patterns they never noticed, gaps they could fill, futures they could plan.

Then I automated it.

What LifeLine Does

LifeLine is a browser-based tool that generates a multi-decade timeline with a Gantt-style grid. You mark events, milestones, and periods across 12 life categories — from Happiness to Career to Loss.

No login. No server. No database. Everything stays in your browser's localStorage.

The core idea: see your entire life on one page — from birth year to the horizon you choose.

12 Life Categories

Category		Category
😊 Happiness	💜 Relationships	👶 Children	🎓 Education
🏢 Career	💰 Income	⛺ Travel	✏ Hobbies
🏃 Sport	🏥 Health	💀 Loss	⚡ Conflicts

What You Can Do

Add point events: 3, Product launch, 2018
Add bar ranges: 4, 1979-1990, School, blue
Toggle life milestones (statistical ♀/♂ lines with education, career, family)
Export as SVG or multi-page PDF
Print on A4 sheets or 914mm plotter rolls

Yes, I actually print these on a plotter. A 40-year life on a single continuous roll of paper, pinned to a wall. That's how we use them in real sessions.

From Paper to Code

The first lifelines were hand-drawn on large paper with colored markers. Participants in strategic sessions would fill in their decades while I facilitated.

The problem: every session needed a fresh template. Drawing the grid by hand takes 30 minutes. Printing a pre-made template means fixed year ranges.

So I built a generator. Start year, end year, number of rows — the tool renders a perfect SVG grid that you can fill in digitally or print blank and fill by hand.

Zero Dependencies — By Design

The entire project is three files:

index.html    — 18 KB (toolbar, modals, canvas, mobile UI)
calendar.js   — 84 KB (SVG renderer, viewport, i18n, PDF export)
style.css     — 25 KB (all styling, responsive, mobile)

No React. No build step. No npm install. The whole thing loads instantly and runs on any device with a browser.

Why No Framework?

Instant load — zero bundle, zero hydration, zero FOUC
SVG over Canvas — vector output for crisp printing at any scale
Offline-capable — works without internet after first visit
Easy to host — npx -y serve -l 3456 and you're done

The PDF export lazy-loads jsPDF + svg2pdf.js (~500KB) only when the user clicks "Download PDF". Seven font weights (IBM Plex Sans) are fetched in parallel and embedded as base64.

The WallPlan Connection

LifeLine shares DNA with WallPlan, my wall calendar generator. Same SVG rendering engine, same viewport pan/zoom system, same IBM Plex Sans fonts, same PDF export pipeline.

This wasn't an accident. WallPlan proved that pure SVG + vanilla JS can handle complex multi-page printable layouts. When I needed the same capability for life timelines, I forked the rendering core and adapted it.

Same engine, different purpose:

WallPlan → years × months (planning ahead)
LifeLine → decades × life categories (looking back and forward)

Mobile-First, Touch-Native

The mobile UI uses a bottom bar + bottom sheet pattern:

One-finger pan, two-finger pinch-to-zoom
Paper format toggle (A4 / plotter roll)
Column width selection (1cm / 1.5cm / 2cm per year)
Entry input via a full-screen modal

Everything renders as SVG with position: fixed pages — smooth pan/zoom without DOM reflow.

Built-in i18n

The tool ships with English and Russian interfaces. Language auto-detects on load. Every string — from decade labels to tooltip text to the sticky-note category cheatsheet — is localized through a built-in t('key') function. No i18n library needed.

Russian version lives at lifeline.osovsky.com/ru.

Publications & Lectures

This isn't a weekend project. The methodology behind LifeLine has been presented at conferences and published since 2017:

Images of the Future & Graphic Thinking — Kirov, 2017
Career Development of a Top Manager — Sochi, 2018
Lifeline & Schematization in Coaching — Seminar, 2018
Forum of Ideas — Moscow, 2020
Expanding Planning Horizons — Medium article

The concept: "Lines and structures are a language for making sense of your life — just as a blueprint is the language of an engineer, a map is the language of a geographer, and a Gantt chart is the language of a manager."

Try It

Live: lifeline.osovsky.com
GitHub: github.com/maximosovsky/lifeline

npx -y serve -l 3456  # Open http://localhost:3456

Building in public, one repo at a time. Follow the journey: LinkedIn · GitHub

Your README Is Your Book Cover. Here's the Checklist I Use for 50+ Projects

Maxim Osovsky — Tue, 24 Feb 2026 16:44:00 +0000

Open any random GitHub repo. Chances are, the README is either a wall of text, a default create-react-app placeholder, or just empty.

Now imagine you manage 50+ repositories. Every single one needs a README that looks professional, explains what the project does, and helps new contributors (or your AI assistant) get up to speed in seconds.

I got tired of reinventing this every time. So I turned my README rules into a standalone project.

The Problem Nobody Talks About

Most developers treat READMEs as an afterthought. "I'll write it later." Later never comes.

But here's the thing: a README is a book cover. If it's boring, nobody opens the project. No stars, no contributors, no adoption. Even if the code inside is brilliant.

And there's a second audience that nobody thinks about: AI. When you ask an LLM to help with your project, the first thing it reads is the README. A bad README means bad AI suggestions. A structured README means the AI understands your project instantly.

What I Systematized

After writing and rewriting READMEs for 50+ projects, I noticed that the same patterns kept working. The surprise? README quality can be systematized. It's not art — it's a checklist.

Here's the 14-point structure I settled on:

1.  Centered header + logo
2.  Badges (status, license, stack)
3.  Tagline (1 line)
4.  Inline navigation (Quick Start · Features · Docs)
5.  Preview screenshot / GIF
    ---
6.  💡 Concept (blockquote + explanation)
    ---
7.  ✨ Features (table, not bullet list)
    ---
8.  🚀 Quick Start (3 lines of code)
    <details> Advanced setup </details>
    ---
9.  🏗️ Tech Stack (table + file tree)
    ---
10. 🗺️ Roadmap (task checklist)
    ---
11. 🤝 Contributing (fork → branch → PR)
    ---
12. 📄 License + author
13. llms.txt + llms-full.txt (LLM-readable docs)
14. GitHub About: Description, Website, Topics

Not every project needs all 14 points. But having a checklist means you never forget the important ones.

What to Use (and What to Avoid)

✅ Use

Technique	Why
`<div align="center">`	Centered headers look professional
`style=for-the-badge` badges	Consistent, eye-catching
`<img width="600">` preview	Shows what the project looks like
`<details>` collapsibles	Hides secondary info, keeps README scannable
Feature tables	Easier to scan than bullet lists
`---` dividers	Visual separation between sections
`[!NOTE]` / `[!WARNING]` alerts	GitHub renders them beautifully
`llms.txt` at root	AI can discover and understand your project

❌ Avoid

Wall of text — nobody reads unformatted prose
No preview image — unclear what the project looks like
No badges — looks like an unfinished project
No Quick Start — people leave if they can't run it in 30 seconds
Hardcoded secrets — even sk_test_... alarms reviewers
No license — legally unclear whether the code can be used
Dead links — broken URLs kill trust
Empty About section — repo won't appear in GitHub search

The LLM Angle: llms.txt

The llms.txt standard is simple: put a plain-text file at your repo root that explains the project in a format optimized for AI.

I add two files to every project:

llms.txt — short summary (name, purpose, stack, status)
llms-full.txt — extended context (architecture, API, deployment)

Does it make a difference? When I give my AI assistant a project with llms.txt, it understands the codebase faster and gives better suggestions. Without it, the AI guesses — and often guesses wrong.

CI: Auto-Check Your README

One file, zero cost, and GitHub checks every push:

# .github/workflows/readme-lint.yml
name: README Lint
on: [push, pull_request]
jobs:
  links:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: lycheeverse/lychee-action@v1
        with:
          args: --verbose *.md
  markdown:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: DavidAnson/markdownlint-cli2-action@v16
        with:
          globs: "*.md"

What it catches:

🔗 Dead links (404s)
🏷️ Broken badge images
📝 Markdown syntax errors

Free for public repos. 2,000 minutes/month for private.

Templates

The repo includes two ready-to-use templates:

TEMPLATE.md — full 14-point structure with {PLACEHOLDERS}. Copy, rename to README.md, fill in the blanks.

TEMPLATE-minimal.md — 5 essential sections for quick projects.

Both follow the same principles. Both work as instructions for AI — paste the template into your prompt and the LLM generates a structured README.

How I Actually Use It

My workflow:

Start a new project
Copy TEMPLATE.md → README.md
Tell the AI: "Fill this README using the project's source code and README_GUIDELINES.md"
Review, tweak, push

The AI reads the guidelines, follows the structure, and produces a README that looks like I spent an hour on it. In reality, it takes 2 minutes.

For 50+ projects, that's not a productivity hack — it's a survival strategy.

Real-World Examples

Projects built with these guidelines:

Project	What It Is
WallPlan	Calendar wall planner generator
Lifeline	Interactive timeline builder
TeleInviter	Telegram meeting bot with timezones
DelayedPopup	Smart popup timing library

Every one follows the same structure. Every one looks professional at first glance.

Try It

Repository: github.com/maximosovsky/readme-guidelines

Grab a template, point your AI at the guidelines, and stop writing READMEs from scratch.

While writing this article, my Water Reminder popped up and I took a water break. If you're deep in code right now — go drink a glass of water. You'll thank me later.

Building in public, one repo at a time. Follow the journey: LinkedIn · GitHub

I Built a Telegram Bot That Solves the "What Time Is It For You?" Problem

Maxim Osovsky — Mon, 23 Feb 2026 16:44:00 +0000

"Can we do 6 PM your time? Wait, what time zone are you in again?"

I've had this conversation hundreds of times. I work with people across 7 timezones — from Los Angeles to Bishkek. Every meeting started the same way: open World Time Buddy, convert times, paste the result into Telegram, hope nobody gets confused.

But the real problem wasn't the conversion. It was everything that happens after.

The Actual Problem

Meetings happen in messengers. Not everyone knows each other's email. So nobody adds you to Google Calendar. You get a Zoom link in a Telegram chat, and that's it — no reminder, no calendar event, just a message you'll scroll past and forget.

I needed three things:

Automatic timezone conversion — type the time once, everyone sees it in their city
A Google Calendar link — one click to add the meeting, no email required
DM reminders — because group chat messages get buried

So I built a Telegram bot that does all three from a single message.

How It Works

Send the bot one line:

Strategy Call, 15.03.2026, 18:00, https://zoom.us/j/123456, @alex @maria

It responds with a card like this:

📅 Strategy Call
📆 Saturday, 15 March 2026

🕐 17:00 Riga; Tel-Aviv
🕐 17:00 Rome
🕐 18:00 Istanbul
🕐 20:00 Bishkek
🕐 01:00 Beijing (+1 day)
🕐 08:00 Los Angeles

🔗 https://zoom.us/j/123456

📲 Add to Calendar  ❌ Cancel Reminder

Then, 45 minutes before the meeting, every participant gets a personal DM: "Reminder: Strategy Call starts in 45 minutes." And another one 5 minutes before.

The Stack (All Free Tier)

Service	Role	Cost
Vercel	Hosting (serverless)	$0
Upstash QStash	Delayed reminders	$0
Upstash Redis	User allowlist	$0
Telethon	Personal DMs	$0
pyTelegramBotAPI	Bot interface	$0

Total infrastructure cost: $0/month. Everything runs on free tiers.

The entire bot lives in one file — api/index.py. Deploy with git push. No servers, no Docker, no maintenance.

The Hard Parts

Why Telethon (and why it's risky)

Telegram Bot API has a fundamental limitation: bots can't DM users who haven't started a conversation with the bot. So if I invite @alex to a meeting, the bot can't send Alex a reminder — Alex never messaged the bot.

The workaround: Telethon, a userbot library. It sends DMs from a real Telegram account, not a bot. This bypasses the restriction — but Telegram actively fights spam from userbots. Send too many DMs too fast, and your account gets a FloodWaitError or worse — a permanent ban.

My AI assistant kept warning me: "Don't use Telethon, Telegram will block your account." I used it anyway, with rate limiting and careful batching. So far, no ban.

The 64-Byte Bug

Telegram limits callback_data (the hidden payload in inline buttons) to 64 bytes. QStash message IDs are long. So when the bot tried to create a "Cancel Reminder" button with the full QStash ID, Telegram threw BUTTON_DATA_INVALID.

The fix: store a short numeric key (cancel:1, cancel:2) in the button, and map it to the full QStash ID server-side. Simple, but it took a debugging session to figure out — we only saw the real error after adding detailed error messages to the bot's responses.

DST Is a Nightmare

Timezone conversion sounds simple until you hit Daylight Saving Time. Riga and Tel-Aviv are sometimes in the same timezone, sometimes not. The bot uses Python's zoneinfo with IANA timezone database — proper DST-aware conversion, not hardcoded UTC offsets.

When two cities end up at the same time, the bot merges them: 17:00 Riga; Tel-Aviv.

Architecture

User → Telegram → Vercel (webhook)
                       │
                  api/index.py
                  (Flask + Bot)
                       │
        ┌──────────────┼──────────────┐
        │              │              │
   Upstash Redis    QStash      Telegram API
   (allowlist)   (2 reminders)  (card + buttons)
                       │
                  ┌────┴────┐
                  │         │
             -45 min    -5 min
                  │         │
             /reminder  /reminder
                  │         │
              Bot msg    Bot msg
              + DMs      + DMs
              (Telethon) (Telethon)

Security layers:

Webhook verification via X-Telegram-Bot-Api-Secret-Token
Reminder endpoint protected by custom X-Reminder-Secret header
Dynamic allowlist in Redis (only approved users can create meetings)
Admin roles for managing the allowlist
Input sanitization with html.escape()

What I Learned

1. Infrastructure beats features.

The bot has ~10 features (timezones, reminders, DMs, calendar, allowlist, admin roles, cancel buttons). But the real value is the architecture: one file, zero cost, deploy with git push. Features are easy to add when the foundation is solid.

2. Free tiers are surprisingly generous.

After 2 weeks of usage: 37 QStash messages total, 16 Redis commands, 0 bandwidth. The free tier limits (1,000 QStash messages/day, 500K Redis commands/month) are absurd overkill for a personal tool.

3. The Telethon trade-off is real.

Userbot DMs are the killer feature — and the biggest risk. Telegram can ban your account at any time. For a personal tool, the risk is acceptable. For a product with thousands of users, you'd need a different approach.

4. AI debugging is best when it shows, not tells.

The BUTTON_DATA_INVALID bug was invisible — we only saw "⚠️ Reminder failed." The fix wasn't in the logic; it was adding str(e) to the error message so we could see the real problem in Telegram. AI suggested this in one step.

Try It

The bot is live: @inviterLinkBot

Source code: github.com/maximosovsky/teleinviter

Deploy your own in 5 minutes — you'll need a Telegram Bot Token, an Upstash account, and a Vercel account. All free.

Building in public, one bot at a time. Follow the journey: LinkedIn · GitHub

I Asked My AI to Remind Me to Drink Water. It Built a Product Instead.

Maxim Osovsky — Sun, 22 Feb 2026 17:09:22 +0000

I was 62 minutes into a coding session when I asked my AI assistant: "Do you even have a rule to remind me about water?"

It did. It just couldn't do anything about it — AI only responds when you talk to it. It can't push notifications.

Drinking water is one of those things everyone knows they should do but nobody actually does during deep work. So instead of relying on a rule the AI couldn't enforce, we built a tool that can.

That conversation turned into an open-source product in under 30 minutes.

The Problem Nobody Talks About

Developers know they should hydrate. We install apps, set phone timers, buy fancy water bottles. But when you're deep in code, you dismiss everything. Phone buzzes? Ignored. Browser tab notification? Closed without reading.

What you can't ignore is a window that appears on top of everything and won't go away until you click OK.

From Request to Script (5 Minutes)

I said: "Write a PowerShell script that shows a popup every 40 minutes."

The AI's first version used Windows balloon notifications — those small toasts in the bottom-right corner. I tested it.

It disappeared on its own after 5 seconds. Useless.

🧑 "Make the window 5x bigger."

The AI switched from balloon notifications to WinForms — a proper GUI window with dark theme, centered on screen, TopMost = $true. No more missed reminders.

The Script: 90 Lines of PowerShell

The entire thing is one file — water-reminder.ps1:

param(
    [int]$Interval = 40,
    [string]$Title = "Water Reminder",
    [string]$Message = "Drink a glass of water!",
    [string]$Subtitle = "Take a 10 minute break",
    [string]$Emoji = [char]::ConvertFromUtf32(0x1F4A7),
    [int]$Width = 500,
    [int]$Height = 300
)

Every parameter is configurable. Want a stretch reminder every 25 minutes? A Pomodoro break timer? Just change the flags:

powershell -File water-reminder.ps1 -Interval 25 -Message "Stretch!" -Title "Break Time"

The Dark UI

The popup uses a dark theme that doesn't blind you during late-night sessions:

Background: rgb(30, 30, 40) — almost black
Accent: rgb(100, 180, 255) — soft blue
Typography: Segoe UI with a 48pt emoji on top

No Electron. No Node. No dependencies. Just PowerShell and .NET assemblies that ship with every Windows installation.

The Loop

while ($true) {
    Start-Sleep -Seconds ($Interval * 60)
    $count++
    Write-Host "[$time] Reminder #$count"
    Show-Reminder
}

That's it. Sleep → popup → repeat. The counter logs to console so you can see how many reminders you've gotten today.

From Script to Product (20 Minutes)

After testing it for a few minutes, I said: "Turn this into a product so others can use it too."

The AI:

Created a project folder with proper structure
Wrote a README following my readme-guidelines
Added an MIT license
Created ARCHITECTURE.md documenting every parameter
Published to GitHub with topics for discoverability

One command to publish:

gh repo create water-reminder --public --source=. --push --description "Desktop reminder to drink water and take breaks"

VS Code Auto-Start (The Best Part)

I didn't want to remember to launch the script every morning. So I added a VS Code task that starts it automatically when I open my workspace:

{
    "label": "Water Reminder",
    "type": "shell",
    "command": "powershell -File water-reminder.ps1",
    "presentation": { "reveal": "silent", "panel": "dedicated" },
    "isBackground": true,
    "runOptions": { "runOn": "folderOpen" }
}

Open VS Code → reminder starts silently in a background terminal → first popup in 40 minutes.

One-time activation: Ctrl+Shift+P → Tasks: Manage Automatic Tasks in Folder → Allow.

What I Actually Learned

1. The best tools solve your own problems first.

I didn't set out to build a product. I just wanted a reliable reminder to drink water during long coding sessions. The product came second.

2. AI can't compensate for missing infrastructure.

My AI had a rule to remind me about water, but it physically can't push notifications. Recognizing the gap between "capability" and "infrastructure" is the real skill.

3. PowerShell is underrated for desktop utilities.

No install. No dependencies. No build step. Double-click and it works on every Windows machine since Windows 7. For small tools, this beats Electron by 100x.

4. Productizing a script takes 20 minutes, not 2 days.

README + LICENSE + GitHub repo + topics. That's the minimum viable product for an open-source utility. If your tool works, ship it.

Try It

git clone https://github.com/maximosovsky/water-reminder.git
powershell -File water-reminder.ps1

Star the repo if you forget to drink water too: github.com/maximosovsky/water-reminder

Building in public, one utility at a time. Follow the journey: LinkedIn · GitHub

I Tried to Build a One-Click Deployer — Here's What Actually Happened

Maxim Osovsky — Sun, 22 Feb 2026 11:48:05 +0000

The Original Idea

The hypothesis was simple:

If a project runs on Vercel, it's just static files — HTML, JS, CSS. If it's static, you can host it anywhere. Any CDN. Any object storage. Any cloud.

So I came up with DeployBridge — an open-source service where you paste four things into a form:

GitHub repo URL
Vercel token
Alibaba Cloud token
Domain name

Hit "Deploy." The service clones the repo, runs npm run build, takes the output files, and uploads them to Alibaba Cloud OSS (object storage). No server. No Nginx. No VPS. Just files on a CDN with a custom domain. Done in 30 seconds.

The logic felt bulletproof: GitHub repo → npm run build → upload dist/ to Alibaba OSS → DNS → live site. Five API calls, all automated.

I even had the complexity estimated at 3–4 out of 10. How hard can it be?

Then I tried to actually deploy something. It took 1.5 hours, 15 steps, 3 different admin consoles, and 8 gotchas I never saw coming.

Here's what happened.

The Promise

🤖 Antigravity built the landing page with a Luma-inspired aesthetic — glassmorphism cards, pastel gradients, subtle animations. It looked professional. Premium, even.

The form. The progress bar. Five steps animating beautifully:

✅ Cloning repository
✅ Building project
✅ Deploying to Vercel
⏳ Configuring DNS on Alibaba Cloud
⬜ Verifying domain & SSL

Then came the moment of truth: I needed to actually deploy WallPlan, my calendar generator, to Alibaba Cloud.

The Reality

🧑 = me (human) — console clicks, purchases, DNS records
🤖 = Antigravity (AI) — scripts, API calls, debugging

Step 1: Create a RAM User (10 min)

🧑 You can't just use your root Alibaba account for API access. You need a RAM (Resource Access Management) user — their equivalent of AWS IAM.

I navigated to Alibaba Cloud Console → RAM → Identities → Users → Create User, and attached the AliyunOSSFullAccess policy. There's a picker with 56 pages of policies. Fun.

After creating the user, you get an AccessKey ID and Secret. The Secret is shown exactly once. If you miss it, create a new one.

Gotcha #1: The RAM user was created, but I still couldn't do anything. Turns out you need to grant permissions in a separate step — creating the user alone isn't enough.

Step 2: Activate OSS ($0.00 Purchase Flow)

🧑 OSS (Object Storage Service) isn't enabled by default. You need to "purchase" it. For $0.00. With a credit card.

Clicking "Enable Now" takes you to a checkout page. Total: $0.00. Payment method: VISA. You still need to click "Purchase."

After the "purchase," you get a success page. Congratulations, you've bought nothing.

Gotcha #2: Even though the service is free to activate, there's a multi-step purchase flow with payment method selection. This can't be automated via API.

Step 3: Deploy the Files (2 min ✅)

🤖 Antigravity wrote a Node.js script using the ali-oss SDK. I just hit Enter:

const client = new OSS({
  region: 'oss-ap-southeast-1',
  accessKeyId: process.env.ALI_ACCESS_KEY_ID,
  accessKeySecret: process.env.ALI_ACCESS_KEY_SECRET,
  bucket: 'wallplan-deploy',
});

// Upload 23 files: HTML, JS, CSS, fonts, images
await client.put('wallplan/@yka_yka/index.html', localFile, {
  headers: { 'Content-Type': 'text/html; charset=utf-8' },
});

23 files uploaded. Bucket created. Static hosting enabled. All good.

Step 4: Try to Open the URL... 💀

🧑 I clicked the URL. The HTML file downloaded instead of rendering in the browser.

<!-- Not this -->
<h1>WallPlan Calendar</h1>

<!-- This -->
Save as: index.html (19KB)

🤖 Antigravity re-uploaded the file with explicit Content-Type: text/html and Content-Disposition: inline headers. Headers looked correct. Still downloading.

Turns out the problem wasn't the headers at all.

Gotcha #3: Alibaba Cloud OSS forces file downloads on the default *.aliyuncs.com domain. This is a security policy, not a bug. You must bind a custom domain. The documentation mentions this in a footnote somewhere. Nowhere is it prominently displayed.

This single gotcha invalidated the entire "one-click" concept. Without a custom domain, nothing works in a browser.

Step 5: Find Your DNS Provider (1 min)

🤖 Antigravity ran a quick check:

nslookup -type=NS osovsky.com
# → ns31.domaincontrol.com → GoDaddy

My domain was on GoDaddy. In the "one-click" vision, the system would somehow need to handle this automatically for every possible DNS provider.

Step 6: GoDaddy API... Doesn't Work (15 min)

🧑 I created a Production API key at developer.godaddy.com/keys.

🤖 Antigravity wrote a script to add a CNAME record via the GoDaddy API. The API returned:

{"code": "ACCESS_DENIED", "message": "Authenticated user is not allowed access"}

Gotcha #4: GoDaddy's free tier doesn't give actual API access to manage DNS records. The API key creation page doesn't tell you this. You create the key, it looks valid, and then... AccessDenied.

🧑 Had to add the CNAME record manually through the GoDaddy mobile app. At 2 AM.

Step 7: Domain Verification (20 min)

🤖 Antigravity wrote a bind-domain.js script to bind ali.osovsky.com to the OSS bucket. New error:

NeedVerifyDomainOwnership: Please verify domain ownership 
by CreateCnameToken and try again.

OSS needs proof that you own the domain. Fair enough. But the verification requires adding a TXT record — and DNS doesn't allow a CNAME and TXT record on the same hostname.

🤖 Antigravity parsed the API response and figured out the TXT record goes to _dnsauth.ali.osovsky.com, not ali.osovsky.com.

🧑 I added the TXT record manually in GoDaddy.

🤖 Antigravity ran the bind script again — domain bound successfully.

Gotcha #5: The initial error message is misleading. The TXT record goes to _dnsauth.{subdomain}, which doesn't conflict with CNAME. But you only learn this by reading the full XML error response.

Step 8: Block Public Access (5 min)

🤖 Antigravity tried to set the bucket ACL to public-read via API. Error: Put public bucket acl is not allowed.

🧑 I went into OSS Console → Permission Control → found "Block Public Access: Enabled" → disabled it.

🤖 Antigravity ran the ACL script again — success.

Gotcha #6: Alibaba Cloud enables "Block Public Access" by default on the account level. This overrides any bucket-level ACL you set. You must explicitly disable it in the console before public-read works.

Step 9: DNS Propagation (10 min)

After binding the domain, the URL returned "Could not find IP address." Normal DNS propagation delay — but another step where we both sat and waited, refreshing the browser.

🤖 Antigravity kept running nslookup ali.osovsky.com 8.8.8.8 until it resolved. Eventually:

ali.osovsky.com → wallplan-deploy.oss-ap-southeast-1.aliyuncs.com → 47.79.50.56

Step 10: SSL Certificate... Costs $40 💸

The site worked over HTTP. Time for HTTPS.

🤖 Antigravity installed the Alibaba Cloud Certificate Management SDK, wrote a script, and called the API:

Error: InsufficientQuota — 额度不足

🧑 I went to the SSL Certificate Management console. The free certificate package requires a "purchase." I clicked through the flow... $40/year.

Gotcha #7: Alibaba Cloud's "free" SSL certificates were quietly transitioned to a $40/year subscription model in February 2026. The free tier no longer exists.

We decided HTTP was fine for an experiment.

Final Result

After 1.5 hours, it worked:

http://ali.osovsky.com/wallplan/@yka_yka/index.html

The calendar loads. The fonts render. It works.

The Scoreboard: Human vs. AI

Step	Who did what	Outcome
Landing page	🤖 AI designed & built	✅ Beautiful
RAM user + permissions	🧑 Human (console)	✅ Manual
OSS activation	🧑 Human ($0.00 purchase)	✅ Manual
File upload script	🤖 AI wrote & ran	✅ Automated
Content-Type fix	🤖 AI debugged headers	❌ Wrong diagnosis
Custom domain needed	🤖 AI found the real cause	✅ Researched
DNS provider lookup	🤖 AI ran nslookup	✅ Automated
GoDaddy API script	🤖 AI wrote it	❌ API blocked
CNAME record	🧑 Human (GoDaddy app, 2 AM)	✅ Manual
Domain verification script	🤖 AI wrote & debugged	✅ Automated
TXT record	🧑 Human (GoDaddy app)	✅ Manual
Domain bind	🤖 AI ran the script	✅ Automated
Disable Block Public Access	🧑 Human (console)	✅ Manual
Set ACL to public-read	🤖 AI ran the script	✅ Automated
SSL certificate	🤖 AI wrote SDK script	❌ $40, abandoned
Security hardening (.env)	🤖 AI refactored all scripts	✅ Automated

Score: 🤖 AI automated 8 steps. 🧑 Human did 5 console steps manually. 3 steps failed entirely.

The AI was genuinely useful — it wrote all the scripts, debugged API errors, and parsed XML responses at 2 AM. But it couldn't click "Purchase" in a browser, couldn't bypass GoDaddy's API restrictions, and couldn't buy a $40 SSL certificate without permission.

What I Actually Learned

The Hypothesis vs. Reality Gap

Hypothesis	Reality
"It's just static files"	True, but hosting static files has 15 steps
5 API calls	5 API calls + 5 manual console steps + 3 failures
Complexity: 3–4/10	Reality: 7/10
30 seconds	1.5 hours
Zero config	Configure RAM, OSS, ACL, DNS, domain verification
Fully automated	5 mandatory manual steps
Any cloud provider	Each provider has unique gotchas
Any DNS provider	GoDaddy API doesn't even work
Free SSL included	SSL costs $40/year

The "Automation Ceiling"

Even with an AI assistant writing code in real-time, some steps simply cannot be automated:

Activating OSS requires a manual purchase flow
GoDaddy (and some other DNS providers) don't offer working API access
Domain verification requires adding records in a third-party system
Block Public Access toggle is an account-level security setting
SSL certificates require purchasing a subscription plan

The Core Irony

The original hypothesis was elegant and technically correct: Vercel-compatible projects are just static files, and static files can live anywhere. That's true.

But "deploying static files" turned out to be the easy 10% of the problem. The other 90% is cloud provider onboarding, security policies, DNS fragmentation, and $0.00 purchases with credit cards.

DNS: The Universal Problem

The biggest blocker isn't cloud providers — it's DNS fragmentation. Your domain could be on GoDaddy, Cloudflare, Namecheap, Route53, Google Domains, Hetzner, or any of dozens of other providers. Each has its own API (or doesn't have one at all). Supporting all of them is a product in itself.

Should DeployBridge Exist as a Product?

Probably not as a SaaS. The gap between "one-click deploy" and reality is too wide. Every user's setup is different — different cloud, different DNS, different account configurations.

But the article you're reading might be more valuable than the product itself. If you're considering building a cross-cloud deployment tool, here's your roadmap of what you'll actually encounter.

What I'd build instead:

A guided wizard that walks users through each step, rather than promising automation
A CLI tool for personal use that handles the specific providers I work with
A really good dev.to article about why "one-click" is a lie 😄

The 8 Gotchas Cheat Sheet

#	Gotcha	Provider	Who found it
1	Creating a RAM user ≠ granting permissions	Alibaba Cloud	🧑 Human
2	OSS activation requires a $0.00 "purchase"	Alibaba Cloud	🧑 Human
3	Default OSS domain forces file downloads	Alibaba Cloud	🤖 AI
4	GoDaddy API requires paid plan for DNS access	GoDaddy	🤖 AI
5	Domain verification TXT goes to `_dnsauth.*`	Alibaba Cloud	🤖 AI
6	Block Public Access silently overrides ACLs	Alibaba Cloud	🧑 + 🤖
7	"Free" SSL certificates cost $40/year	Alibaba Cloud	🤖 AI
8	OSS API signatures need alphabetically sorted params	Alibaba Cloud	🤖 AI

What's the wildest deployment gotcha you've encountered? Drop it in the comments 👇

Follow me: LinkedIn · X/Twitter