How do I send a file from one machine to another with curl and no account?

The general problem

A file transfer has three separate jobs: move bytes reliably, decide who may read them, and decide how long that permission should last. Email and chat combine those jobs with an identity system, a conversation history, previews, retention rules, and size limits. That can be useful for people, but it is awkward when one machine needs to hand a build, measurement, database export, or log bundle to another machine.

HTTP already gives you the transport. RFC 9110 describes PUT as a request to create or replace a representation at a target URI, while GET retrieves a representation. curl can stream a local file with --data-binary @file, preserving bytes instead of treating them as a web form. TLS protects the connection in transit, but it does not by itself decide which recipient should be allowed to fetch the object.

The simplest no-account design is a capability: a random piece of authority that the holder presents when downloading. It is a bearer permission, so copying it is equivalent to copying the right to use it. That trade-off is honest and often practical for a short-lived handoff, provided the capability is kept out of URLs, shell history, tickets, and logs where possible.

A small curl workflow

First choose a box and a name. The box is the transfer space, and the name identifies the object. The public shape of svc.nz separates the write host from the read host. A sender who holds a write capability for the box can upload a file like this. During the private trial a new box is created by invitation, so the examples assume you already hold that capability; see the policy centre for the current status.

curl -X PUT -H "Authorization: Capability <write-capability>" \
  --data-binary @report.csv \
  https://in.svc.nz/example-box/report.csv

The response supplies the metadata needed by the sender, including the newly created version and an access capability. Pass that capability to the recipient through a channel you trust for this sensitivity level. The recipient downloads the latest version with a header:

curl https://out.svc.nz/example-box/report.csv/latest \
  -H "Authorization: Capability <access-capability>" \
  -o report.csv

Never put the capability in the URL, whether in an example or in production, unless a compatibility requirement leaves no alternative. URLs are routinely copied into browser history, proxy logs, analytics fields, screenshots, referrer headers, and chat transcripts. The HTTP Authorization field exists for credentials that belong in request headers. A header does not make a bearer secret magically safe, but it removes several easy leakage paths.

What no account changes

An account normally gives you a recovery identity, an audit trail tied to that identity, a place to list objects, and a way to revoke sessions. A no-account capability transfer gives you none of those by default. The holder of a valid capability can use its scope, and the system cannot distinguish the intended holder from somebody who copied it. Treat the capability like a physical key, not like a username.

Use an expiring box for a one-off transfer. Expiry limits the useful lifetime of a forgotten or leaked capability, although expiry is not a substitute for deletion guarantees or a recipient who handles the file carefully. Keep your original file until receipt is confirmed. The legal pages explain the private trial status and current service limits, including why svc.nz should not be the only copy of important data.

For a sensitive file, encrypt it before upload. Client-side encryption means the sender turns plaintext into ciphertext before the PUT, and the recipient decrypts after the GET. Send the decryption key through a different channel from the capability. The storage service then sees opaque bytes, but anyone who obtains both the capability and the key can still read the file.

Choosing the right tool

Use a direct SSH copy when both machines are yours, you control network access, and a durable machine identity is useful. Use object storage when you need durable retention, lifecycle policies, access logs, teams, and a mature administrative model. A collaboration drive suits people who need search, comments and permissions managed by accounts. An expiring capability box suits a small, explicit handoff that should work from a shell.

A presigned S3 URL is a fair comparison. AWS documents presigned URLs as time-limited access to an object without requiring the recipient to have AWS credentials. They are powerful, but setting them up still assumes an AWS account, bucket, IAM policy, and usually an SDK or configured CLI. svc.nz narrows the surface to a named byte object and a header capability. Teams needing retention policies, governance and operational controls should evaluate storage services against those requirements.

After the receiver has the bytes, compare the downloaded file with the sender's expected digest when the workflow is important. A digest catches truncation and the wrong object, while the capability controls access. Keep the original file until the recipient confirms receipt, and record the version used so a failed transfer can be retried without guessing which upload was current. Ask the recipient to confirm successful retrieval. Keep that confirmation with the transfer record.

FAQ

Sources

HTTP Semantics, the standard reference; curl man page; AWS S3 presigned URLs; OWASP, information exposure through query strings.