Receiving files

This is the half an ordinary file host does not do, and the reason the app exists rather than a link to WeTransfer.

How it works

An administrator adds an outside contact under Users — an agency client, a photographer, an accountant — as a guest. A guest has no password and never sets one.

When they need to send you something:

  1. They open your instance and enter their address.
  2. If that address is on the list, they receive a one-time sign-in link.
  3. The link opens an upload form where they choose which team member should receive the files.
  4. That person gets the transfer, with the guest's address as the reply-to.

No account for them to create, no password for them to forget, and nothing for you to administer beyond adding the address once.

Why a guest can only address your team

The recipient picker is filled from your member list, and the choice is resolved against the user table on the server. Addresses typed by the guest are refused.

Without that, anyone holding a magic link could use your server to mail an arbitrary third party — a relay with your domain on it. A guest can pick who at your company receives their files, and nothing else.

Guests also don't choose retention. They are dropping files off, not publishing, so the instance default applies rather than letting an outside contact pin something on your disk indefinitely.

The link is single-use and expires after NUXT_MAGIC_LINK_MAX_AGE_MINUTES (30 by default). Guest sessions are deliberately short — NUXT_GUEST_SESSION_MAX_AGE_HOURS, 12 by default — because a magic link is a one-off errand, not a standing login.

Requests are rate limited per IP, and the endpoint answers identically whether or not the address is known. That matters: an endpoint that says "no such user" is a way to test who your clients are.