Introduction
What the service is, who it's for, what v1 does and what it deliberately doesn't.
Secure File Transfer is a reference service on AWS for exchanging confidential files with people outside a company. A company sends files through a link that expires, or sends an upload link so an outsider can deliver files to it, and keeps control of both until the link ends.
The problem it solves
Companies routinely exchange confidential files with outsiders: contracts with a customer, payroll with an accountant, drawings with a supplier. The usual tools fail in three ways:
- They can't be taken back. An email attachment, once sent, stays in the recipient's mailbox. A shared-drive link keeps working until someone remembers to turn it off.
- They don't check who opens them. Anyone who receives a forwarded email or a pasted link can open the file.
- They leave no record. Nobody can answer "who downloaded the contract we sent on Monday, and from which IP address?"
Secure File Transfer addresses each one. Every link expires and can be revoked at any time. Every recipient proves they control the invited address before they see a single file name. Every file is scanned for malware and inspected for sensitive data before anyone can download it. Every action is written to an audit log.
Who it is for
The service is multi-tenant. A tenant is one customer company. Its own people sign in; outsiders never get an account and only ever reach one transfer or one upload request at a time.
| Role | Who | What they do |
|---|---|---|
| Tenant admin | IT or security staff at the customer | Manage members, tenant policy and the DLP policy; see and revoke every transfer and upload request in the tenant; search and export the audit log. Sees metadata, not file contents. |
| Member | Any employee of the customer | Send transfers, create upload requests, and see and revoke their own. |
| Approver | A member or admin named by a tenant admin | Approve or reject transfers that a DLP rule holds for approval, never their own. |
| Recipient | An outside person a transfer is sent to | After verifying their email address, download that transfer's files while it is valid. |
| Uploader | An outside person an upload request is sent to | After verifying their email address, upload files to that request while it is valid. |
| Platform operator | The team running the service | Provision tenants and run the platform. No access to file contents; emergency access is audited and raises an alert. |
What v1 does
| Capability | What it means |
|---|---|
| Send | Share up to 50 files (5 GB each, 20 GB per transfer) with up to 50 recipients by a link that expires in 1 hour to 30 days. |
| Request | Send one outsider an upload link so they can deliver up to 50 files to you. |
| Verify | Recipients and uploaders enter a one-time code emailed to the invited address. A forwarded link alone grants nothing. |
| Protect | Files are encrypted with AWS KMS keys at rest and TLS in transit, and scanned for malware before any download. |
| Prevent data loss | Files are inspected for personal data and secrets, such as My Numbers and payment card numbers. Company rules warn the sender, hold the transfer for an approver, or block it before anything leaves. |
| Control | Admins revoke any link at any time. Downloads can be limited per recipient per file. |
| Audit | Every security-relevant action is recorded with its actor, time and source IP, and kept for 365 days. |
| Web app and API | A React web app on a versioned REST API (OpenAPI 3.1). Recipient pages and emails in English and Japanese. |
All customer data stays in AWS's Tokyo and Osaka regions; Osaka is a replicated standby for disaster recovery.
What it deliberately doesn't do
Some features are left out of v1 on purpose:
- No end-to-end encryption. If the service couldn't read files, it couldn't scan or inspect them. Scanning takes priority, so files are encrypted with keys the service controls through KMS.
- No anonymous public links. Every recipient verifies an email address.
- No collaboration features (folders, sync, previews, comments, versions) and no server-side zip downloads.
- No desktop, mobile or Outlook clients, and no email gateway integration. The web app and the API are the only clients.
- No self-service sign-up, billing or plans. A platform operator provisions each tenant.
- No defence against a determined insider. DLP catches mistakes and casual misuse; someone who encrypts, splits or retypes data gets past it.
- No DLP beyond v1's detectors and formats, such as OCR, legacy Office files, or 7z and RAR archives. A file that can't be fully inspected is recorded with its reason, and the tenant's rules decide.
- No active-active multi-region, and no compliance certification such as SOC 2, ISO 27001 or ISMAP.
Current status
Five planning phases are done: requirements, architecture and system design, security design, architecture decision records, and a delivery plan. The build is on milestone M0, the foundation. The API service skeleton has its settings, health probes, metrics, logs and graceful shutdown, but serves no product routes yet. The AWS infrastructure is written in Terraform and statically checked, not applied.
Secure File Transfer is a reference service, built to the standard of a real B2B SaaS team. It has no customers, no support and no uptime commitment. Every number on these pages is a design target, not a measured result. Do not use it to move real confidential data.
Licence
The source is available under the PolyForm Noncommercial License 1.0.0. You may read, run and adapt it for noncommercial purposes. It is source-available, not open source: the licence does not permit commercial use. See Licensing for details.
Where to go next
- Core concepts: the vocabulary used across these pages.
- Sending files: how a transfer goes from upload to download.
- Requesting files: how outsiders deliver files to you.
- Recipient verification: why a forwarded link gives nothing.
- Security model: encryption, access control and the threat model.
- Architecture: how the service is built on AWS.