39 Products Packaged on a Single-Core 2 GB Server: Zero Dependencies for Half the Scripts

The moment I knew the pipeline was going to work was also the moment I nearly killed it. I had just finished packaging my 39th product, and the server was gasping. One vCPU. Two gigabytes of RAM. No GPU. I had queued up a parallel batch of cover renders because it felt faster, and the box hung for four minutes before the kernel killed the process. Nothing was lost, but the lesson was. The machine was not the problem. My habits were.

Here is what actually changed, and why it let the same tiny server push out 39 finished products, 856 MB of output, without falling over again.

The four stalls that matter

Making the art is the fun part. The things that actually stop people from shipping are boring:

1. Metadata. Adobe, Vecteezy and Dreamstime all reject a wrong CSV header instantly. The header has to match exactly, or the whole upload bounces.
2. Double posting. Run your batch twice and you look like a spammer. Fastest way to get an account flagged.
3. Turning a doc into a product. You have the content, but a raw Markdown file does not look like something someone pays for.
4. Packaging. A bare zip does not sell. A zip with a real cover and a crisp thumbnail does.

Every script in the kit exists because I hit one of these four, usually at 2 a.m. usually right after a rejection email.

The rules that keep the box alive

The pipeline ran on 1 vCPU, 2 GB RAM, no GPU. Not because that is ideal, but because that is what I had, and it turns out that is enough if you stop fighting the machine:

• One process at a time. Never fan out image jobs in parallel on a single-core box. I learned this the expensive way.
• Free memory between items. Call gc.collect() after each asset. It sounds fussy. It is the difference between a clean run and a crash on item 300.
• Measure peak RSS, not average. resource.getrusage(RUSAGE_SELF).ru_maxrss tells you the real ceiling. Averages lie.
• One file per subprocess for heavy render steps, so memory goes back to the OS instead of sitting around.
• Render at the resolution you need. Checking a preview at 60 dpi beats rendering it at 300 and waiting.

These are not performance tricks. They are habits. The box did not get faster. I stopped asking it to do three things at once.

Half the scripts need nothing installed

Here is the part that surprises people. Two of the four scripts in the kit use only the Python standard library. No pip install. No virtualenv. Just Python 3.9 and go.

• make_metadata.py builds the exact Adobe (5 column), Vecteezy (4 column) and Dreamstime (15 column) upload CSVs from a folder of files.
• upload_tracker.py is a ledger that remembers what you have already posted, so a re-run never double posts.
• md2pdf.py turns a Markdown file into a clean styled PDF. This one needs reportlab.
• pack_product.py zips a product and renders a 1280x720 cover plus a 600x600 thumbnail. This one needs Pillow.

That is two third party packages, total, and only for the scripts that touch pixels or PDF output. If you only build metadata and track uploads, you can skip the install entirely. On a 2 GB server, fewer dependencies is not a style choice. It is room to breathe.

The folder layout that scales

A catalogue turns into a junk drawer fast. The kit assumes one fixed structure:

project/
  assets/     raw output, one file per asset
  output/     ready to submit files and metadata.csv
  packs/      finished zips and covers
  research/   your notes and sources
  scripts/    the tools

Keep research/ forever. The scrape logs and notes behind the 300+ pages of platform rules are the raw material for the next product. I deleted mine once to "clean up" and had to rebuild it from memory. Do not do that.

The numbers behind the rules

The scripts enforce what they enforce because 300+ pages of research said so. The parent project runs about 19,000 lines of pipeline code. The kit is the packaging layer pulled out of it, the four tools that survived contact with a real catalogue of 39 products and 856 MB of shipped output. Above them, the full stack is free: an orchestrator that schedules and retries jobs, a local LLM proxy, and the rest. None of it needs a cloud account.

If you are a solo maker selling stock vectors, stickers or templates, the hard part is almost never the art. It is the CSV header, the duplicate upload, the document that looks like a document, and the zip that looks like a product. That is exactly what the compliance metadata kit was built to handle, and it is the same code that ran on that tired little server.

Get compliance metadata kit

---

Building digital products? Free guides & kits for digital product sellers.