Server-to-server transfer

RFC 959 describes FTP in those terms: a client host and a server host, copying a file. The modern version is usually an SFTP push, an HTTPS PUT from one service to another, or a copy between two buckets in the same provider. A human may have scheduled it. The human is not uploading from a laptop tonight.

The absence of a person changes the credentials and the retry. A password in a script is a leaked secret waiting for a repo. A scoped key, rotated, is the normal door. There is no one to click "resume" at midnight, so the job has to retry, record the byte count, and stop after a cap. Checksums matter more because nobody opens the file to see if it looks right.

At 02:00 app host A pushes a 1.2 GB export to vendor host B over SFTP, key `billing-push`, folder `/inbound`. The remote size matches. The job writes a row and exits. On Thursday the vendor rotates host keys. A's client refuses the new host key, which is the correct SSH failure, and the export does not land. A job that disabled host-key checking would have uploaded to whoever answered. Bucket-to-bucket copy inside one cloud is the other shape: the bytes may never leave the provider's network, the bill is a copy request, and you still need a completion event before the downstream job starts. Starting the import on a copy that is still running reads a partial object.

Do not call a user upload server-to-server because it landed on a server. If a browser or a phone sent it, a person was in the path. This term is for hosts acting on their own.