Nodecraft hosts player-created game servers. Co-founders Jon Yarbor and James Ross started it in 2012 in Oklahoma City, first around Minecraft, then a longer list of titles.
The public write-up is a Backblaze customer story, so it is a vendor page. I could not find a matching post on Nodecraft’s own blog. This case study stays with what James said there, plus Cloudflare and Backblaze docs that match the architecture.
They moved more than 23TB of customer backup files from Amazon S3 to Backblaze B2. The DevOps team did it in seven hours with Python, shell scripts, and the Nodecraft and Backblaze APIs. Backblaze says there were zero disruptions.
If you are looking at the same route, start with the Amazon S3 → Backblaze B2 playbook. Nodecraft already sat behind Cloudflare, so B2’s value was cheaper storage plus free egress into that CDN.
Why they left S3
On 17 January 2018 they launched NodePanel 2 with 12 games. A customer could host Minecraft on Saturday and swap the same box to Terraria on Sunday. The feature that made the swap safe was a save-state: settings, world files, player status, archived and restored on demand.
Those archives were large. The vendor page puts a single restore between 500MB and over 15GB. Anyone, anywhere, could ask for one at any time.
Saves went to S3. Restores came back out through Cloudflare to a Nodecraft game server. Nodecraft paid S3 to store the file and paid S3 again to send it to Cloudflare. More games meant more files. More swaps meant more egress.
They sell at a fixed price. Storage and egress were eating the margin. James’s worry, on the vendor page, was whether they could afford to succeed on S3.
Cloudflare was already in the stack for delivery, DDoS, and Argo Smart Routing. A later Cloudflare developer spotlight (November 2021) confirms they had been on Cloudflare for almost ten years by then, and that James was pushing Workers for the website and player-lookup APIs. That post is about Workers, not about this copy. I am using it only to show Cloudflare was real, not a slide in a Backblaze deck.
How they moved
The move was one storage backend. Cloudflare stayed.
Backblaze sits in Cloudflare’s Bandwidth Alliance as a zero-rated egress partner. Cloudflare’s Backblaze partner page says Backblaze offers free data transfer to shared customers. Backblaze’s own Cloudflare CDN guide says the same thing for public buckets served through a proxied hostname.
That is the architecture the vendor page sells. Storage on B2 at about one fifth of S3. Egress from B2 to Cloudflare at $0.00. The 85% figure is James’s estimate of the combined monthly storage-plus-egress bill, not a storage-only discount.
The copy itself is thin. They used Python, shell scripts, and the Nodecraft and Backblaze APIs, and moved more than 23TB in seven hours. The page does not mention Flexify, rclone, or a write freeze.
B2’s S3-compatible API is the usual way to keep S3-shaped tools. Nodecraft may have used that, or the native API. The page does not say. Current Backblaze docs still list a generic migrate menu if you do not want to write the job yourself.
What they gained
James estimates Cloudflare plus B2 saves almost 85% each month on storage and egress versus S3. Storage alone is about one fifth. The Cloudflare hop dropped off the bill.
The vendor page says they can keep adding titles without the swap feature crushing the margin. It does not publish the old invoice or the new one.
Backblaze also claims zero service disruption. There is no customer-visible outage window in the story.
What the vendor page skips
The story does not describe a dual-run or a checksum table. It also says nothing about objects written during those seven hours. The playbook still wants a freeze before the last delta. If players kept saving while the scripts ran, you need a second pass or you lose those archives.
Versions, lifecycle, encryption keys, and bucket policy are not described. The playbook treats those as rebuilds.
ETags can change. The Amazon S3 → Backblaze B2 playbook says not to treat ETag equality as proof.
The 85% number is architecture plus a vendor quote. If you are not already sending this traffic through Cloudflare, you do not get the Bandwidth Alliance waiver just by opening a B2 bucket. Backblaze’s CDN guide wants a proxied CNAME and a Transform Rule that scopes the hostname to your bucket, so another public bucket cannot ride your domain.
Cloudflare’s 2021 spotlight says James was looking forward to R2. That is a later comment, not this migration. I am not treating it as a second move. If R2 is the destination you want, that is a different playbook: Amazon S3 → Cloudflare R2.
If you need to undo B2, the reverse playbook is Backblaze B2 → Amazon S3. Nodecraft did not describe using it.
What I would copy
Price the bill you actually have. Nodecraft’s pain was S3 storage plus S3-to-Cloudflare egress on large, frequent restores. If your objects sit still, the Alliance waiver does less work.
Keep the CDN and change the origin. That is the one-change story they published.
If you write the copier yourself, log every key and size. Reconcile against S3 after the first pass. Then decide whether you need a freeze or a second job for saves that arrived during the copy.
After cutover, restore an old 15GB-class archive and a save created after the flip. The first checks the bulk copy. The second checks the new writer.
The Amazon S3 → Backblaze B2 playbook is the checklist I would run. Use the Backblaze interview for the Cloudflare pairing, and remember it is a vendor page.