DEV Community: Bear Huang

Using FastFileLink to Deliver a 3.8GB, 158-File U.S. Department of War UFO Public Archive

Bear Huang — Thu, 14 May 2026 08:51:38 +0000

Recently, war.gov launched a public UFO/UAP records page.

According to the official description, the release was part of the Trump administration's push for more transparency around UAP-related information. The U.S. Department of War (DOW), together with other agencies, published a batch of unresolved UAP-related records and historical documents.

When I saw the news, my first thought was simple:

“It would be really useful if people could download this whole thing in one place.”

The official page is browsable, but if you actually want to download all the PDFs, videos, and images, the experience is not that smooth. You have to click through files one by one, figure out which items are documents, which are videos, and which are just images used by the page itself. For a normal user, even getting started is already a bit of work.

This is exactly the kind of problem FastFileLink is meant to solve: taking a batch of files and turning it into a package that can be delivered, downloaded, and clearly explained.

I was personally curious about the material too, so I spent some time collecting the files and checking whether it was legally reasonable to redistribute these public records. After confirming that it was okay to do, I decided to organize everything and make it easier for others to download.

This kind of archive is a natural fit for FastFileLink. The full package is around 3.8GB and contains many files. I honestly did not have an easy place to put it. You cannot send something like this through WhatsApp, LINE, or a regular messaging app. A cloud drive would bring its own issues: storage limits, permissions, packaged downloads, bandwidth limits, and so on. So I decided to document the whole process as I went.

First, I organized the public files into one complete folder

I started by collecting the directly downloadable files from the war.gov UFO/UAP Release 01 page.

The final package looked roughly like this:

158 downloadable files
116 PDFs
28 videos
14 images
Around 3.8GB total
Source URLs preserved for every file
SHA-256 checksums generated
Index files and a manifest included

I put everything into one folder:

04_full_release01_pack/

Besides the actual files, I also prepared a few helper files:

README.md
START_GUIDE.html
files_index.csv
files_index.jsonl
manifest.json
checksum.sha256
files/

README.md explains the source, scope, licensing notes, and the non-endorsement disclaimer.

START_GUIDE.html is an entry guide for regular users. The release itself is quite scattered: there are videos, images, FBI-related materials, NASA/Apollo-related materials, and large historical scanned PDFs. If someone downloads the archive and only sees a pile of files, they may have no idea where to begin.

So in START_GUIDE.html, I added a simple suggested browsing order:

Start with the videos
Then look at the images
Then open the shorter modern PDFs
Then move on to the FBI and NASA/Apollo-related materials
Save the large historical PDFs for last

That gives people a straightforward entry point after downloading the archive.

Uploading the whole folder with FastFileLink

Once the folder was ready, I uploaded it.

I logged into my FastFileLink account and uploaded the entire 04_full_release01_pack folder. The important part here is that I did not need to compress it into a ZIP myself, and I did not need to manually handle how all the files would be packaged, listed, or delivered to downloaders.

FastFileLink handled the folder delivery directly.

At first, the upload produced a standard download page like this:

This standard page is clean, functional, and downloads work just fine.

But when I looked at it, it felt too neutral.

This package was about the U.S. Department of War UFO/UAP public records. When someone opens the page, they should immediately understand what they are downloading. Especially for a 3.8GB package, a generic download box may not inspire enough confidence.

So I decided to use FastFileLink's white-label customization feature to make the page better match the actual content.

Using white-label customization to turn the download page into a dedicated landing page

FastFileLink's white-label settings let you customize the logo, background, colors, navigation links, download notes, footer content, and more.

I switched the logo to a white version because I wanted a dark theme for this page. Then I changed the background to a deep blue, tech-style image and used a cool color palette that fit the UFO/UAP topic.

After the customization, the page looked more like this:

Now, as soon as someone opens the page, they can quickly see that the package contains:

U.S. Department of War UFO/UAP public records
158 files
116 PDFs
28 videos
14 images
Source URLs, index files, and SHA-256 checksums

I also added source and legal notes in the footer:

Source: war.gov/UFO
This is an unofficial convenience download pack
It is not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War, U.S. Department of Defense, AARO, NARA, DVIDS, or any U.S. government agency
The appearance of U.S. government visual information does not imply DoW/DoD endorsement of FastFileLink or this website
The archive is redistributed as publicly released and does not claim that the files prove extraterrestrial life

That disclaimer matters. Since the package uses U.S. government public records, and U.S. federal government works are generally public domain in the United States, redistribution is usually not the main issue. The important thing is to avoid giving the impression of an official partnership or endorsement.

There is also a small localization detail: my browser is set to Chinese, so the download progress and interface text appear in Chinese for me. English readers opening the same page will see the download interface in English according to their browser environment.

A download page should explain the content before asking people to download

After I published the package, someone gave me a very practical piece of feedback:

It'd still be courteous to wait for a click before downloading 4 GB of files. I just wanted to see a description of what's included first.

That made me think.

From the sender's point of view, opening a download page and preparing the download right away makes sense. The goal is to deliver the files.

But for someone seeing the link for the first time, 4GB is not a small download. They may simply want to check what is inside, confirm the source, review the size, and decide whether they actually want to download it.

FastFileLink already has an eye icon on the page that opens a preview, where people can see the file description and content information.

But I realized that if I am sharing a link on a forum or social platform, it is better not to send people straight into the download flow. A better approach is to share the preview-mode link directly.

The trick is simple: add this to the end of the URL:

?preview=true

For example, instead of:

https://0.2.fastfilelink.com/xxxx

use:

https://0.2.fastfilelink.com/xxxx?preview=true

With that, people first see the description, file information, and download notes. Then they can choose whether to start the download.

For large-file delivery, this is a very useful detail. The bigger the file, the more likely the first question is not “How do I download it?” but “What exactly is this?”

How people reacted after I shared it

After the package was ready, I posted it in a few places to see how people would react.

I tried Hacker News first. Surprisingly, it did not get much traction and only received a small number of points. Someone later pointed out that this kind of reading material or public archive is not a great fit for a Show HN submission. There may also have already been a similar effort by someone else, though that version was mainly hosted on GitHub and required Git LFS to download. Hacker News readers know how to use Git LFS, of course, but most normal users do not.

That was one of the reasons I made this package in the first place: not everyone uses Git, and not everyone has Git LFS installed. Many people just want to download the full archive through a browser.

The response on V2EX was much better than I expected. A lot of people said thanks, and many people actually downloaded the package. The backend showed thousands of clicks and hundreds of real downloads.

That gave me another useful confirmation: FastFileLink worked smoothly in a real scenario with a large archive, many files, and many people downloading around the same time. This was not just a local test, and it was not just one or two people opening the link. A real group of users actually downloaded the 3.8GB package.

What this taught me about large-file delivery

On the surface, this project looks like a quick response to a news topic.

But after going through the whole process, I came away with a clearer understanding of large-file delivery. The hard part is often not just that the file is large.

The real issues are things like:

There are many files
The file types are mixed
Source URLs need to be preserved
Downloaders need to know where to start
The content needs explanation
Checksums matter
Legal and attribution notes matter
The download page needs to feel trustworthy
Previewing before download can be important

If you simply drop a folder into a cloud drive, you have to patch together all of these details yourself.

FastFileLink turns delivery into a more complete workflow: upload the folder, customize the page, add the explanation, share the link, and let people download it through a browser.

This public archive was a good example of that workflow.

The final result

In the end, I prepared three versions for different audiences:

English
Traditional Chinese
Simplified Chinese

Each version has its own download page, README, and START_GUIDE.

This was not a UFO research project, and I did not try to interpret the files. My goal was simple: take a batch of official public files and make them easier for normal people to download and start browsing.

I also put the materials I created myself — the README, START_GUIDE, index files, checksums, manifest, and the three download links — on GitHub:

https://github.com/bear0330/war-gov-ufo-uap-release-01

The actual large files are still delivered through FastFileLink. GitHub is a good place for the index, documentation, and verification files. FastFileLink is better suited for delivering the full 3.8GB archive to normal users.

If you have a similar need, such as:

Delivering a large public archive
Sending a full set of video assets
Handing off client project files
Sharing a large collection of photos or original files
Letting someone download a folder through a browser without installing extra tools

that is exactly the kind of situation FastFileLink is designed for.

Sometimes file transfer is not just about sending files out.

Organizing the files, explaining them clearly, and helping the recipient download with confidence is what real delivery looks like.

How ffl Differs from CLI File Transfer Tools Like croc and Magic Wormhole

Bear Huang — Wed, 13 May 2026 10:18:00 +0000

If you often move files from the terminal, you have probably heard of tools like croc, Magic Wormhole, portal, or sendme. They all solve the same basic problem: getting a file from one machine to another.

Most file transfer tools fall into two broad categories:

P2P transfer tools

These try to connect the sender and receiver directly. When a direct path is not available, some of them fall back to a relay. Magic Wormhole, portal, and sendme belong to this general category. croc is more relay-first, which helps avoid many NAT and firewall problems.
Cloud-upload tools

These upload the file to a server first, then give the recipient a download link. Tools and services like transfer.sh, WeTransfer, and file.io follow this model.

In everyday use, most people are already familiar with the second category: Google Drive, Dropbox, WeTransfer, and similar services. The reason is simple: the recipient does not need to install anything. They receive a link and download the file.

CLI transfer tools have a different strength. They are fast, simple, automation-friendly, and great for temporary transfers. But many of them share one limitation: the receiver usually needs to install the same tool too.

For example, croc is very convenient, but both sides need croc. Magic Wormhole also expects both sides to participate in the same wormhole workflow. That is fine when you are moving files between your own machines. It becomes less convenient when you need to send something to a client, a teammate, a phone user, or a group of people.

So what makes ffl different?

ffl is the CLI version of FastFileLink. Its core idea is simple: from the terminal, turn files, folders, or even stdin streams into an HTTPS download link that anyone can open.

The main difference: ffl gives the receiver an HTTPS link

The mental model of ffl looks like this:

ffl file.zip
→ creates an HTTPS link
→ the recipient downloads it with a browser, curl, wget, or ffl

The recipient does not need to install ffl first. If they have a browser, they can download the file. If they are on a server, they can use curl or wget. This changes the shape of the whole transfer flow.

Most CLI transfer tools are built around a paired session:

sender terminal  <->  receiver terminal

ffl is closer to creating a reusable delivery point:

sender creates an HTTPS link
recipient A downloads
recipient B downloads
recipient C downloads later

That is why ffl naturally fits one-to-many delivery, repeated downloads, and resumable downloads. It is useful for “send this from one of my machines to another,” and it is also built for “deliver this file to someone else.”

Quick comparison

✅ Supported / suitable　❌ Not supported / not suitable　➖ Depends, or not the main workflow

Key point	ffl	croc	Magic Wormhole	sendme	transfer.sh / WeTransfer
Receiver needs to install a tool	✅ No, browser is enough	❌ Yes	❌ Yes	❌ Yes	✅ No
Download with `curl` / `wget`	✅ Yes	❌ No	❌ No	❌ No	✅ Yes
Main handoff model	✅ HTTPS link	🔑 Code phrase	🔑 Code phrase	🎫 Ticket / CLI	☁️ Cloud link
One-to-many delivery	✅ Natural	❌ Not suitable	❌ Not suitable	❌ Not suitable	✅ Yes
Repeated downloads from the same share	✅ Yes	➖ Not the main model	➖ Not the main model	➖ Not the main model	✅ Yes
Direct P2P	✅ WebRTC P2P	➖ Mostly relay-based	➖ Can try direct paths	✅ Yes	❌ No
Fallback when direct fails	✅ HTTPS relay / tunnel	✅ Relay	✅ Transit relay	✅ Relay	➖ Already cloud-hosted
Relay impact on speed	✅ Direct path avoids an extra hop; fallback only when needed	➖ Often depends on relay location and bandwidth	➖ Depends on the path	✅ Good when direct works	➖ Depends on the cloud service and region
E2EE	✅ Supported	✅ Supported	✅ Supported	✅ Transport encryption / protocol integrity	➖ Depends on the service
Recipient verification model	✅ OTP / PubKey / Basic Auth, etc.	🔑 The code is the pairing mechanism	🔑 Wormhole code	🎫 Ticket	➖ Mostly link or account permissions
Cloud upload / sender can go offline	✅ Supported with upload mode	❌ No	❌ No	❌ No	✅ Main workflow
Resume interrupted downloads	✅ Yes	✅ Yes	➖ Depends	✅ Yes	➖ Depends on the service
Folder transfer	✅ Yes	✅ Yes	✅ Yes	✅ Yes	➖ Usually needs zipping first
Distribution model	✅ APE single file + native builds	✅ Go binary per platform	➖ Python package / OS package	✅ Rust, installed per platform	✅ Web service

Why WebRTC matters for speed and routing

ffl tries WebRTC P2P by default. When a direct path works, data flows from the sender to the receiver without going through a relay. For large files, avoiding an extra hop can make a real difference.

When P2P is not available, ffl automatically falls back to HTTPS relay / tunnel mode. The transfer can still continue instead of failing because of NAT or firewall restrictions. If the recipient uses a browser or curl, they use the HTTPS path. If the recipient also uses ffl, it can try WebRTC first.

croc leans more toward a relay-first design. That makes it very good at getting through NAT, but transfer speed can depend heavily on the relay’s location, bandwidth, and route. When you are moving large files across countries, corporate networks, or cloud regions, that difference can matter.

Tools like sendme also have strong modern P2P capabilities. The main difference is still on the receiver side: the recipient needs the matching tool or ticket workflow, while ffl can simply hand out a standard HTTPS download link.

Where tools like croc shine

croc has a very clear strength: once both devices have it installed, you can pair them with a code and move a file quickly. For engineers, it is great for sending something from a laptop to a remote host, from a work machine to a home machine, or between two machines you control.

Magic Wormhole has a similar appeal. Its code phrase is easy to communicate verbally, and its security model is mature. It works well when both sides are comfortable using the same CLI workflow.

The sweet spot for these tools is:

both sides understand CLI
both sides can install the tool
the transfer is a one-time paired session

If that is your situation, croc and Magic Wormhole are excellent tools.

Where ffl fits better

ffl is more useful when the situation looks like this:

I need to send a file to someone who does not use CLI
I want the recipient to download from a browser
I want to share one link with multiple people
I want interrupted downloads to resume
I want curl / wget support for automation
I want both P2P speed and fallback reliability

In these cases, the HTTPS link is the key advantage.

You do not need to check whether the recipient installed the right tool. You do not need to explain a code phrase flow. You send a link. The recipient can be on a browser, a phone, a server, or a CI job, and there is still a natural way to receive the file.

How it differs from cloud-upload tools

Services like transfer.sh, WeTransfer, and file.io also give you download links. Their usual flow is:

upload the file to a server
then let the recipient download it

That is convenient, but it also means the file is stored on a service first. Large files have to finish uploading before the recipient can download them. Privacy, retention, and availability depend on the service provider.

ffl gives you more flexibility. It can try WebRTC P2P first, then fall back when needed. If the sender needs to go offline, upload mode can turn it into a temporary hosted delivery link.

That covers two common workflows:

both sides online: prefer P2P
not online at the same time: use upload mode for temporary delivery

With E2EE enabled, the relay or temporary storage server cannot read the file contents.

APE: why portable single-file distribution matters

Besides native builds, ffl also provides an APE version. APE stands for Actually Portable Executable, from the Cosmopolitan ecosystem. In plain terms, it is a single executable format designed to run across multiple operating systems whenever possible.

This is different from the usual Go or Rust single-binary story. Go and Rust tools often produce one executable per target platform:

linux-amd64
linux-arm64
macos-arm64
windows-amd64.exe
...

The APE experience is closer to this:

download ffl.com
put it on a USB drive, home directory, shared folder, or toolbox
run it when needed

That is useful for DevOps work, emergency debugging, customer environments, containers, and machines where you do not have permission to install packages. You do not need a package manager, and you do not need to set up a runtime on the target machine.

APE also makes ffl unusually convenient as an embeddable transfer engine. The official Android app and the MCP Server both use the APE build as the core engine. The outer application handles the phone, AI agent, or server integration, while the same ffl.com engine handles transfer.

Practical DevOps scenarios where ffl feels different

1. Pull a result out of a container

You run a task inside a container and it produces a report, model, log bundle, or test artifact. The usual options may involve mounting a volume, setting up SCP, fixing permissions, or uploading to cloud storage first.

With ffl, you can run:

ffl /output/report.zip

It prints an HTTPS link. You can open it from your browser or download it from another machine with curl. The more temporary the container environment is, the more useful this becomes.

2. Stream a MySQL backup directly to someone or another machine

Database backups often create huge .sql files. You may not want to write the file locally first and then upload it somewhere.

You can stream directly into ffl:

mysqldump production_db | ffl - --name production_backup.sql

The recipient can download it from a browser, or receive it from another machine with ffl or curl. This is also useful when the output is part of a larger pipeline.

3. Share a large CI artifact with a reviewer

Some build artifacts are too large or too temporary to put into GitHub Actions artifacts, S3, or an internal file service. Examples include debug builds, benchmark results, model weights, and compressed log bundles.

From a CI runner or temporary build server:

ffl build/output/

Then send the link to the reviewer. They open it in a browser. They do not need to know anything about the CI runner.

4. Move files from locked-down machines

Production machines and customer environments often do not allow installing extra packages. They may not have Python, Node, or a convenient package manager.

A portable ffl.com binary is useful here. You can keep it in an internal tools directory, on a USB drive, on a jump box, or fetch it temporarily. Run it when needed, delete it when done.

5. Send technical files to non-engineers

This happens more often than people expect. You may need to send logs, videos, datasets, model outputs, design assets, or diagnostic bundles to a PM, customer, QA person, or external partner.

With croc, the other person also needs croc. With cloud drives, you may need to upload first, set permissions, and wait for sync.

With ffl, you send an HTTPS link. They download it from a browser. That is the simplest value proposition.

Which one should you choose?

If you are moving files between two machines you control, and both sides can install a CLI tool, croc, Magic Wormhole, and sendme are all mature choices.

If you are sending files to general users, clients, teammates, or multiple recipients, ffl feels more natural because the receiver gets a normal download link.

If your only goal is to upload a file to the cloud and let someone download it later, tools like transfer.sh and WeTransfer can do the job. They simply do not provide the same P2P-first path or the same portable CLI delivery-engine model.

Summary

The shortest way to describe ffl is:

It turns CLI file transfer into HTTPS link delivery.

That gives it a clear distinction from paired one-to-one tools like croc and Magic Wormhole. The receiver does not need to install anything. The same link can be downloaded by multiple people. The file can be received with a browser, curl, wget, or ffl.

With WebRTC P2P, relay fallback, E2EE, upload mode, and portable APE distribution, ffl works both as a daily CLI tool and as a practical file-delivery building block for automation.

For a more detailed feature-by-feature breakdown, see the Wiki detailed comparison.

Want to try it? Download the CLI version.

Server Migration Without Extra Disk Space: Streaming Borg Backups with FastFileLink CLI

Bear Huang — Tue, 05 May 2026 13:39:24 +0000

Migrating a production app sounds like a simple copy job until the old server is nearly full.

That is usually when migration becomes urgent. The machine is old, disk space is tight, the new server is only half-prepared, DNS cannot move yet, and the data set is large. If the migration flow still expects the source server to create one more giant tarball before anything can move, the process becomes much harder than it needs to be.

This post is a field report from reworking our own migration flow. The original path was familiar: take a Borg backup, export it as a tar or tar.gz, copy it to the target with scp, and restore it there.

That works fine when disk space is plentiful. It is much less pleasant when the source machine is already under pressure, which is often the exact reason the migration is happening in the first place.

So we moved the transfer layer to FastFileLink CLI and turned the whole operation into a streaming path. The source no longer needs to stage a tarball. The target does not need to download one either. Data flows from the old machine to the new one and lands where it needs to be restored.

This pattern is useful well beyond our own deploy system. If you need to move large backups, restore production data into a development VM, or transfer a one-off archive without prearranged SSH trust, it is a very practical approach.

Our Deployment Model

Internally, we run a lightweight deployment system with a PaaS-like shape. The main entry point is Deploy.py.

It handles install, backup, restore, migrate, update, health checks, and the surrounding operational work. Shared behavior lives in the deployment layer, while each app keeps its own app-specific scripts and settings.

We do not use Kubernetes for this class of workload. The reason is simple: for our current environment, the total complexity is not a good trade. Many of our services are small to medium production apps. We care more about clear single-host operations, readable scripts, predictable recovery, and being able to understand the entire lifecycle from the app directory.

In that context, a structured deployment interface is valuable. Full cluster orchestration would be more machinery than we actually need.

Why App Working Folders Matter

A key design choice in this system is that every app has its own working folder.

That folder contains runtime configuration, container definitions, service scripts, app-level maintenance tools, and the rules for restoring persistent volumes. The database is part of the same operational contract through dumps, backup hooks, or related tooling.

In practice, if we can recreate the following pieces on another machine, the app can usually come up there before any DNS cutover:

Piece	Why it matters
Container definition	Recreates the service process and runtime image
Volumes	Preserves uploads, user data, and other persistent state
Database	Preserves structured application data
Configuration	Recreates domains, ports, paths, secrets, and environment variables
App maintenance tools	Gives the new host the same install, backup, restore, and migrate interface

That is why each app has its own bin tools such as backup, install, restore, and migrate. The global deployment layer invokes them, but the app still owns the app-specific details.

This design is intentionally plain. In production operations, plain is often a strength.

What the Old Migration Flow Looked Like

The old migration flow looked roughly like this:

source server
  -> run Borg backup
  -> export volumes from Borg
  -> create a tar stream or tar file on disk
  -> copy it to the target with scp

target server
  -> receive the archive
  -> extract it
  -> restore database and config
  -> start the app
  -> verify before cutover

That is an easy flow to understand. Borg is a solid backup tool. scp is familiar to almost every operator. Tarballs are easy to inspect.

The real problem is the disk-usage pattern.

The Pain Point: the Source Server Is Already Short on Space

Suppose an app has 80 GB of volume data.

The old path can force the source server to carry all of this at once:

existing application data
+ Borg repository or backup cache
+ exported tar archive
+ optional compressed archive
+ partial transfer file
+ logs and temporary files

That requirement clashes with the reason migrations happen in the first place. The machines that need to be moved tend to be the ones that are already too full, too old, or too awkward to keep extending. Asking that same machine to produce one more large copy of the data is the worst possible requirement.

The more sensible approach is to let the backup output enter the transfer pipeline directly, without landing on the source disk first.

Could rsync Solve This?

If the source data already exists as a directory tree and SSH connectivity between source and target is already in place, rsync remains excellent.

rsync -aHAX --numeric-ids --partial --partial-dir=.rsync-partial \
  /srv/apps/myapp/volumes/ user@target:/srv/apps/myapp/volumes/

It resumes, preserves metadata, and is very good at synchronizing real directories. If migration simply meant "copy the live volumes and start the app somewhere else," rsync would be a very reasonable choice, and in many environments it may well be faster than a relay-capable sharing tool.

Our situation was slightly different. We already take a backup before migration. Once that backup exists, using it as the data source is natural. The new Borg archive is a clean point-in-time snapshot, and borg export-tar gives us a ready-made stdout stream that can be fed straight into a transfer pipeline.

That is an important distinction. Borg is not the reason migration exists here. It is simply the backup mechanism we already use and trust. After the backup finishes, it becomes a convenient source for the migration stream. Whether to transfer the full backup history to the new machine is a separate decision. In many environments it is optional because full-machine backups already exist elsewhere.

The other factor is target flexibility. Sometimes the target is a clean VM or a temporary test environment, and we do not want to deal with SSH keys, sshpass, or extra server-to-server trust setup before moving the first byte.

Under those conditions, a stream-oriented transfer tool is a better fit.

Why FastFileLink CLI Fits So Well

FastFileLink CLI can transfer files, folders, and stdin. That is the capability that changed the design.

Instead of exporting to a tarball and then copying that tarball, we can keep the data moving the entire time:

borg export-tar -> stdout -> FastFileLink CLI -> stdout on target -> tar extract

The source does not need to stage a tarball. The target does not need to download one either.

The sender side looks like this:

borg export-tar "$BORG_REPO::$ARCHIVE" - \
  | "$FFL" - \
      --name "$APP_NAME-volumes.tar" \
      --e2ee \
      --stdin-cache off \
      --max-downloads 1 \
      --pickup-code "$PICKUP_CODE"

The receiver side sends the stream straight into tar:

"$FFL" download "$LINK" \
  --pickup-code "$PICKUP_CODE" \
  --e2ee \
  --stdout \
  | tar xvf - -C "$RESTORE_ROOT"

That gives us exactly the shape we wanted:

source server: no exported archive on disk
target server: no downloaded archive on disk
transfer path: data streams directly into the target layout

That command shape is intentionally plain tar. borg export-tar produces a tar stream here, so the transfer is named .tar, and the receiver uses tar xvf -. If you want gzip in the middle, it is better to write it explicitly, for example borg export-tar ... - | gzip -c | ffl ..., and then extract with tar xzvf - on the target.

We kept gzip out of the main example on purpose. In this migration, the primary problem was extra disk usage, not compression ratio, and a plain tar stream keeps CPU cost and troubleshooting overhead lower on both ends.

For low-space migration, that is the real win.

What `--stdin-cache`, `--stdout`, and `--pickup-code` Are Doing

If you just paste the commands and move on, a lot of readers will not immediately understand why these flags matter.

Start with --pickup-code. It is part of the pairing flow. The sender produces a link, but the receiver still needs the pickup code before it can actually claim the transfer. If you have used croc, this style of short-code trust model will feel familiar. In a migration script, it is convenient because we can hand the link and the code to the target process without exposing an open download endpoint. Once --pickup-code is present, FastFileLink CLI already knows that pickup mode is being used, so there is no need to also spell out --recipient-auth pickup.

FastFileLink CLI is more flexible than that single mode suggests. Besides pickup, it also supports receiver-verification modes such as pubkey, pubkey+pickup, and email, plus traditional HTTP Basic Authentication through --auth-user and --auth-password. We chose pickup here because it is a very smooth fit for a one-off scripted migration.

Next is --stdin-cache off. FastFileLink CLI's default mental model is general-purpose file sharing. Files might be downloaded more than once, or by multiple receivers, so caching is useful there. A migration stream is the opposite. We know there will be a single receiver consuming the data once. Keeping a stdin cache in that scenario only spends extra source-side disk space. Turning the cache off makes the sender behave much more like a real one-shot stream producer.

--e2ee is worth enabling too. WebRTC already runs over secure transport, but migration jobs can fall back to relay or tunnel paths. With end-to-end encryption enabled, even those middle hops only see encrypted chunks. For backup material and production data, that extra protection is well worth having.

Finally, --stdout is what makes the target side clean. The receiver writes the bytes to stdout, and tar unpacks them directly into place. There is no downloaded tarball to clean up afterward.

Put together, the data path becomes very straightforward:

source app backup snapshot
  -> Borg export stream
  -> FastFileLink CLI sender
  -> FastFileLink CLI receiver
  -> tar extracts directly into the target app folder
  -> volumes land in place

How This Fits Back into Deploy.py

We did not build a completely separate migration tool.

The existing Deploy.py migrate flow already knew how to:

prepare the source and target app layout
invoke the app's own migrate and backup scripts
export volumes
dump and restore the database
restore configuration
start the target app and verify it

So the job was to swap out the transfer mechanics while leaving the rest of the workflow intact.

The resulting shape now looks like this:

Deploy.py migrate
  -> app bin/migrate
  -> ExportVolumes from Borg
  -> source streams into FastFileLink CLI
  -> target receives from FastFileLink CLI
  -> volumes extract directly into the target app folder
  -> database and privileges are restored
  -> backup history can also be transferred when desired
  -> target app is installed and started
  -> verification happens before cutover

This also keeps the old file-based path available. If we want to preserve an artifact, debug restore behavior in isolation, or simply keep the older flow for a roomy machine, that option still exists. Streaming mode is there to solve the low-space migration problem.

What FastFileLink CLI Brings to This Case

FastFileLink CLI matches this scenario surprisingly well because it brings several useful properties at once:

Capability	Why it helps migration
Single-file APE binary	Download when needed, delete after use, no permanent install
WebRTC direct transfer	Tries peer-to-peer paths when the network allows it
Relay fallback	Still completes when direct connectivity fails
End-to-end encryption	Relay infrastructure cannot see plaintext data
Pickup-code verification	Scripts can pair sender and receiver safely
`--e2ee`	Relay or tunnel hops still cannot inspect contents
stdin / stdout support	Makes true no-staging transfer possible
`--hook` event output	Integrates cleanly into existing automation

For an old production host, the single-file binary is a bigger advantage than it first sounds. We do not need to permanently install another service just to move away from that machine. Download ffl.com, run the migration, clean it up, and move on.

--hook is also worth calling out on its own. FastFileLink CLI has its own embedded mode, which can emit structured events for integration. That saved us a lot of glue code, because we no longer had to parse human-oriented console output just to understand what the transfer was doing. That kind of integration surface is unusual in this category of tools.

Comparing FastFileLink CLI with scp, rsync, croc, and Magic Wormhole

The real question with transfer tools is not which one has the flashiest feature list. It is whether the tool's assumptions match the environment you are actually operating in.

Tool	Best fit	Limitation in this scenario
`scp`	Straightforward file copy over SSH	Needs a prebuilt artifact and SSH access
`rsync`	Synchronizing live directory trees	Not a natural fit for Borg stdout streams
`croc`	Secure CLI transfer with pipe support	A good fallback option, but large transfers often end up traversing relay infrastructure, which is not very attractive for multi-hundred-megabyte or multi-gigabyte migrations
Magic Wormhole	Human-friendly one-time transfer	Better for ad hoc exchange than unattended migration pipelines
FastFileLink CLI	File, folder, stdin, and stdout streaming	Needs proper orchestration for logs, cleanup, and timeout handling

If the data is already a plain directory tree and SSH trust is stable, rsync remains very strong.

But when the data source is a backup stream and the target might be a fresh VM, FastFileLink CLI feels better aligned with the real constraints. It asks less from the environment while still giving us encryption, verification, direct-transfer attempts, and relay fallback.

The Real Lessons from Implementation

The most valuable lessons did not come from the happy path. They came from the first few attempts, when large transfers could stall and the surrounding automation did not have enough visibility into what was happening.

Our earliest version was the obvious one: start FastFileLink CLI, parse its normal output, grab the link, and let the rest of the wrapper script take it from there. That was fine for a proof of concept. It was not good enough for a real migration command.

Large data transfers make every observability problem feel bigger:

Did the sender actually begin reading stdin?
Did the receiver really connect?
Are we using a direct path or a fallback path?
If both processes are still alive, is progress real or are we just stuck?
Did the producer fail first, or did the transfer tool fail first?

Orchestration Matters More Than the Pipe

Streaming migration is not finished just because we connected a producer and a consumer with one more pipe.

When a file-based transfer fails, there is usually still a partial file sitting on disk. When a stream stalls, the system has to tell us where it stalled. The difference between a neat demo and a production migration command is usually not whether the tool supports stdin. It is whether the orchestration around that tool was designed with observability, cleanup, and retry boundaries in mind.

In practice, we found that a few things have to be designed explicitly:

Concern	Approach
temporary binary	Download `ffl.com` into a temporary directory and remove it afterward
logging	Be able to switch to DEBUG or point to a logging config when a transfer stalls
receiver readiness	Confirm that the target receiver has actually started before letting the workflow continue
progress	Watch bytes transferred or extracted, not just whether the process still exists
cleanup	Remove orphan sender / receiver processes and temporary files
retry	Retry at the transfer boundary instead of trying to resume from the middle of a half-extracted tar stream
secrets	Keep auth passwords and pickup codes out of ordinary logs

We learned this very directly during testing. If the target receiver never really comes up, the source side can still look busy for a while. It may appear to be waiting or doing useful work, even though the migration is already stuck.

So a robust migration command should at least be able to confirm:

source process is alive
target process is alive
target output is growing
logs show an accepted transfer path

For long-running transfers, "the process still exists" is not progress. Progress has to be observable.

Once we switched to FastFileLink CLI's --hook support, things got much smoother. Share links, progress, receiver state, completion, and failure events could all be tracked as structured data. That was the point where we finally stopped treating human-readable output as an API.

That shift matters a lot. Migration automation needs more than bytes moving over the wire. It needs state that can be trusted.

On top of that, we still fixed a few ordinary deploy bugs, such as target path quoting and the cleanup order for old volumes. But those became straightforward engineering issues once the transfer state itself was observable.

After that, the migration path was able to:

stream volumes from Borg through FastFileLink CLI
restore database dumps on the target
restore database privileges
optionally bring over the Borg backup repository
pull the app image
start the target container

The remaining issue in our test was no longer in the streaming layer. It was an Nginx / SSL cleanup detail on the target side. That was actually reassuring: the hardest part of the move had become ordinary deployment finish-up.

You Can Test the Migration Before DNS Moves

A good migration flow should let us validate the new machine before the real cutover happens.

That fits nicely with our app-folder design. Because the container definition, volumes, database, config, and app maintenance tools already belong to the same working-folder contract, we can restore the app onto the new machine, start it with a test port or a temporary hostname, and confirm that it behaves correctly before touching DNS or the load balancer.

In practice, the checklist is fairly simple:

1. Restore app files, volumes, database, and config on the target.
2. Start the target containers or services.
3. Run health checks.
4. Verify static files and uploaded files.
5. Verify database-backed pages and the login flow.
6. Check logs for path, permission, or environment-variable issues.
7. Only then schedule the DNS or load-balancer cutover.

That is one of the reasons migration becomes less scary. The old production server keeps serving traffic while the new machine proves, right next to it, that it is ready to take over.

This Pattern Is Useful Beyond One App

Even though this work grew out of one migration project, the pattern generalizes very well.

Any time the data source can write to stdout, the same transfer model becomes available:

borg export-tar repo::archive -
pg_dump mydb
mysqldump mydb
tar -cf - /large/folder
zfs send pool/dataset@snapshot

Pipe that into FastFileLink CLI:

producer | ffl - --stdin-cache off --max-downloads 1

Then let the target feed it directly into the real consumer:

ffl download "$LINK" --stdout | consumer

That is a good fit for:

migrating old or nearly full servers
restoring production backups into development VMs
disaster recovery transfers
moving large user-upload archives
transferring database dumps without leaving dump files behind
temporary environments where prearranged SSH trust is inconvenient

Final Takeaway

The most important part of this migration change was not a new compression trick or a more elaborate archive format.

It was rewriting the migration contract.

The old contract required the source server to prepare one more large copy of the data before it could move away.

The new version is much simpler:

read the backup stream
transfer it immediately
restore it directly on the target

--stdin-cache off and --stdout fit that model extremely well. For teams dealing with server migration, backup transfer, low-disk hosts, or temporary restore environments, this turns out to be a practical, automation-friendly, and easy-to-reason-about approach.

When the old server is full and migration has become urgent, that is exactly the behavior you want from the toolchain.

Is AI Making Programming Harder? Why "Test Only, Zero Code Review" is an Absolute Disaster

Bear Huang — Sat, 21 Feb 2026 03:03:51 +0000

Recently, an article titled "AI Fatigue is Real" struck a massive chord, perfectly echoing what many developers are feeling right now: programming in the AI era has actually become more exhausting.

Because we’ve transitioned from being Creators (Builders) to Reviewers. AI generates code so fast and inconsistently that the burden of reviewing has become overwhelmingly heavy: first, it's impossible to enter a flow state; second, you are constantly context-switching; third, this kind of high-density micro-reviewing is incredibly draining and quickly pushes you into "decision fatigue."

Recently, while promoting my open-source project, the fastfilelink CLI (ffl), across various communities, I’ve been lurking and observing mainstream developer discussions. What I saw was endless anxiety, boundless hype, and a flood of "AI will replace developers" methodologies, all accompanied by massive amounts of poorly crafted code.

Some of it makes sense, but a huge portion of it is, frankly speaking, utter bullshit.

To combat this fatigue, a new, incredibly sweet-sounding proposition has emerged in the community (especially driven by the current OpenClaw-dominated faction):

"Don’t review code; review output / tests passed."

Some people even use compilers as an analogy, arguing that we don't review the assembly generated by a compiler today either. Personally, I think this argument is complete dogshit. The reason is simple:

1. LLMs are not Compilers; they lack "Determinism"

A compiler uses strict syntax for deterministic translation, but an LLM is a probabilistic model. When you ask an LLM to generate test cases, sometimes the tests themselves are fake or of terrible quality. Even if all the tests show green, it doesn't mean the system is fine. You ultimately have to review these test cases, so the premise of "not reviewing at all" is fundamentally unreliable.

2. Lack of Global Vision leads to the collapse of the Single Source of Truth

Constrained by the extreme limits of context windows and RAG capabilities, LLMs can only see fragments of a project; they cannot comprehend the system as a whole. This results in generated code packed with extreme redundancy, completely violating the DRY (Don't Repeat Yourself) principle. Once requirements change, it's incredibly prone to producing a massive amount of inconsistent bugs.

3. The Context Window Limit is a short-term unsolvable fatal flaw

Stop fantasizing that "it'll be fine once the models get stronger." Bound by the physical limits of training data and attention mechanisms, context windows will always have a ceiling (not to mention that no matter how big the context window gets, projects will only get bigger). Therefore, the architectural collapse mentioned in Point 2 is practically unsolvable in the foreseeable future.

4. Trapped in a "Chicken-and-Egg" infinite loop

To prevent those weird, unpatched, and inconsistent edge-case bugs from Point 2, your Test Coverage must approach 100%, and the tests must be designed with extreme rigor. This brings us right back to Point 1: Test Cases are themselves Code, heavily copy/pasted by the LLM.

If you want to save yourself the effort of reviewing Production Code, you must spend equal (or even more) effort reviewing a massive pile of Test Code. You are merely trading one hell for another.

The Cruel Reality: This is a game of "Compute Capitalism"

Therefore, the methodology of only caring if test cases pass while ignoring the code has fundamental flaws. It's more of an AI hype—it sounds awesome, but in practice, it’s riddled with issues. You're just swapping one problem for another.

Of course, you might argue: "But it seems to work! As long as we only care about tests/outputs, if we give the LLM enough time and tokens to fix it, it can eventually pass the tests."

Oh, yeah, sure! Because as the project grows larger and gets filled with more and more repetitive logic created by the LLM, you can indeed just throw money at it and let it slowly fix things. But the key points are:

Not reviewing is impossible: You’ve just shifted the target of your review from Production Code to Test Cases. That is still Code, and it still drains your brainpower.
Maintenance costs compound exponentially: Once technical debt stacks up, fixing even a minor bug will cost increasingly more tokens and time.

People are lazy. Who wouldn't want to dump all their work onto AI? (Especially for the vast majority of developers who don't even enjoy coding that much—to them, it's just a job). So, this narrative that "AI can do everything for you" is guaranteed to excite people, while simultaneously peddling anxiety.

But who is the ultimate beneficiary? It's the AI development tool vendors. The more bloated the code is, and the more times you need to debug, the more money they make. The cruel truth they don’t want you to know is that the oldest software engineering adage still holds true: "No Silver Bullet."