How A 2 GB Server Shaped My Pricing For Digital Kits Sold To Buyers On Three Platforms

Description and use

The author built a memory‑aware, idempotent pipeline that automates metadata, uploads, and packaging, enabling low‑cost sales on three platforms.

Problem

The author’s 2 GB RAM, 1 vCPU server crashed during parallel render jobs, leaving uncertainty about which assets had uploaded and causing a costly rebuild of the pipeline.

Outcome

The pipeline now reliably produces 39 finished products from a 2 GB server, with automated metadata, idempotent uploads, and packaging, allowing the author to list on three platforms at a low price while maintaining margin.

Workflow

• 1. Render assets sequentially with memory limits, using subprocesses for heavy steps.
• 2. Generate platform‑specific CSV metadata with make_metadata.py.
• 3. Upload assets with upload_tracker.py to avoid duplicates.
• 4. Package final zip, cover, thumbnail, and PDF docs with pack_product.py and md2pdf.py.
• 5. Organize files in assets/, output/, packs/, research/, scripts/ folders.

Evidence

I had queued 40 render jobs in parallel because parallel felt faster. Python ate the memory, the OS started swapping, and the whole box froze mid-job.

Source

The biggest win was dumb: inspect previews at 60 dpi instead of rendering at 300. Same decisions, a fraction of the memory.

Source

I wrote make_metadata.py to emit exactly the header each platform demands and nothing else, because every "helpful" extra column I added was a rejection waiting to happen.

Source

The fix was embarrassingly simple: upload_tracker.py, a plain ledger with pending, done, and status commands that remembers what shipped.

Source

Two dependencies total for the whole kit. The metadata and tracker scripts use the standard library alone, so they run on the cheapest VPS you can rent with no install step at all.

Source