When two devices are on the same network, uploading a large folder to cloud storage just to download it nearby can be unnecessary. Share provides a direct device-to-device path for selected files and folders.
The useful word is selected. Share is not a public file server and should not expose the whole computer. You choose a project, another folder or a single file, decide when the device is discoverable and respond to access requests.
Use a network you trust
Share’s local transfer path uses plain HTTP on the local network. That makes the trust boundary important. Use it on a network you control or understand, not on open airport, hotel or café Wi-Fi.
“Direct” does not mean automatically private from every peer on the network. A direct transfer avoids routing the file through cloud storage, but network security, device trust and user approval still matter.
If the network is not trusted, use another protected transfer method or wait until the devices can join a known network.
Choose exactly what to expose
The Share app can expose the active project, a selected folder or an individual file. Start with the narrowest item that solves the transfer.
Before sharing a folder, inspect it for secrets, temporary exports, personal information and generated files that do not belong in the transfer. Project folders often contain .env files, credentials, large build artifacts and history that the recipient does not need.
Create a clean transfer folder when the original hierarchy is broad. This improves both security and clarity: the recipient can see what the package is meant to contain.
Discovery should be temporary
Turning discovery on advertises the device to nearby Upfyn clients. Enable it when you expect a connection, then turn it off when the transfer session is complete.
Use recognizable device names. “Anit’s desktop” and “Studio laptop” are easier to verify than a generic machine identifier. If several similar devices appear, confirm with the other person before approving a request.
Discovery makes finding a device easier; it is not proof of identity by itself.
Requests create a human checkpoint
A nearby device can ask to browse what you shared or send an incoming file. The host can approve or deny those requests.
Read the request before accepting it. Confirm the device, requested item and intended action. A browse request and an incoming transfer are different authorities: one reveals selected content, while the other writes a file onto your machine.
Keep incoming transfers in a known location and inspect them before opening. Treat executable files, archives and documents with active content as untrusted until verified.
Watch progress and history
Share shows transfer progress and recent access. Use that information to confirm completion rather than assuming that a large file arrived because the request was accepted.
After transfer, compare the expected files and sizes or use an appropriate checksum for consequential packages. A completed progress bar does not tell you that the selected folder contained every intended item.
Review recent history when you finish. If an unfamiliar device or request appears, stop discovery, remove trust and investigate before sharing again.
Share is different from remote access
Share moves selected data between nearby devices. Remote access lets a signed-in browser or phone reach a paired desktop across a relay. Operator creates a one-time remote-assistance session with mutual approval and optional input control.
Choose Share when the desired outcome is “put these files on that nearby device.” Choose remote access when you want to continue using your own desktop from elsewhere. Choose Operator when another person needs to see or control the host during support.
Using the correct surface keeps authority understandable. A file transfer should not require full remote control, and remote assistance should not expose an entire project folder by default.
Prepare a reliable transfer package
Create a short manifest for important transfers. List the expected top-level files, the purpose of the package and any instructions for opening it. Include the manifest in the shared folder.
For a project handoff, exclude dependency folders and generated build output unless they are specifically needed. Prefer source plus a clear setup document. For media, preserve the folder structure expected by the project and include proxy or source files intentionally.
If the package contains sensitive information, decide whether local-network Share is appropriate at all. Direct transport is not a substitute for encryption at rest or an organizational data policy.
Let the assistant prepare, not approve
Analyst can help inventory a folder and propose a clean transfer package under output. Developer can identify generated project paths or create a manifest. The assistant can point out likely secrets and oversized files.
The person sharing should still review the final selection and approve the browse or transfer request. The assistant’s analysis informs the boundary; it does not own the trust decision.
After completion, remove temporary copies that are no longer required according to your normal retention policy. Do not automate deletion merely because transfer succeeded unless recovery and verification are designed into the workflow.
Ask Upfyn
Prepare a safe Share package from this project. Inventory the requested files, flag secrets and generated content, create a manifest under output, and stop before enabling discovery or approving any device request.