Solution · secure file transfer on AWS
Send confidential files outside the company, and stay in control of every one.
Expiring links instead of email attachments. Recipients verify their email before they download, every file is encrypted and scanned first, and an admin can revoke any link at any time. It runs in your own AWS account.
A · Get it
Built for your business.
I design and build the service in your AWS account, adapted to your company: regions, single sign-on, branding, languages and your data rules. You get the code, the infrastructure, the runbooks and a handover.
B · Get it
Licence plus setup.
A commercial licence to use this codebase in your business, with deployment into your AWS account and support while your team takes it over.
File sharing your security team can sign off on.
Email attachments and shared-drive links can't be taken back, don't check who opens them and leave no record. This replaces them.
- 01
Send by expiring link
Share files up to 5 GB each, 20 GB per transfer, with people outside the company. Every link has an expiry, and uploads resume after a dropped connection.
- 02
Request files from outsiders
Send an upload link so a client, supplier or applicant can deliver files to you, with no account and no email attachments.
- 03
Verified recipients only
A recipient proves they own the email address with a one-time code before anything downloads. Forwarding the link to someone else gets them nothing.
- 04
Scanned before it's shared
Every file is scanned for malware, and nothing can be downloaded until it passes.
- 05
Stop leaks before they leave
Files are inspected for personal data and secrets, such as card numbers, national IDs and cloud keys. Your rules warn the sender, hold the transfer for an approver, or block it.
- 06
Revoke and audit everything
An admin can cut off any link at any time. Every upload, verification and download is written to an audit log that admins search and export.
Two journeys, one set of controls.
Sending and receiving go through the same verification, scanning, inspection and audit.
Sending files out
- 01
Upload
A member uploads files in the web app or through the API, and names the recipients.
- 02
Scan and inspect
Workers scan each file for malware and inspect it for sensitive data. Your rules decide what happens next.
- 03
Email the link
Each recipient gets an email with a link that expires on the date you set.
- 04
Verify
The recipient enters a one-time code sent to their address. The proof is tied to that browser and that transfer.
- 05
Download
The file streams through the API, and only after the download's audit record is written.
Receiving files in
- 01
Create a request
A member creates an upload request and sends its link to the person outside.
- 02
Verify
The uploader proves their email address, the same way a recipient does.
- 03
Upload
They upload up to 50 files, 20 GB in total, straight to encrypted storage.
- 04
Scan and deliver
Each file is scanned and inspected, then becomes available to the member until its retention period ends.
Secure by design, layer by layer.
Each layer comes from a STRIDE threat model, and the design targets OWASP ASVS 5.0 Level 2 for the web app and API.
- Encryption
- TLS 1.2+ in transit. Files, database, backups and logs encrypted at rest with AWS KMS, one key per class of data.
- Malware
- ClamAV in the workers plus Amazon GuardDuty Malware Protection for S3. A file that can't be scanned follows your policy.
- Data loss prevention
- Built-in detectors with check digits and context, in English and Japanese text, inside Office files, PDFs and archives. Matched values are never stored.
- Sign-in
- Mandatory MFA for members, single sign-on with your own identity provider (OIDC or SAML), and tenant-scoped API keys.
- Isolation
- Every query runs under PostgreSQL row-level security per tenant, and a test suite tries every endpoint with another tenant's IDs.
- Abuse
- Rate limits per IP address, account and tenant on sign-in, verification codes, link access, uploads and downloads. Link tokens carry 128+ bits of randomness.
- Audit
- Archived audit records are locked with S3 Object Lock, so nobody can change or delete them before their retention ends.
- Operators
- Platform operators can't read file contents. Break-glass access is time-limited, audited and raises an alert.
Measurable, not hand-waved.
Every requirement has a number and a way to prove it: load tests, failure drills and a written report per drill.
- availability of the API and download path, rolling 28 days
- 99.9%
- from revoking a link to no new download being able to start
- ≤ 5 s
- to restore service in a second region after losing the first
- ≤ 1 h
- API latency at design load, excluding file bytes
- p95 ≤ 300 ms
targets from the requirements · proven by load tests and drills as the build lands
Read every decision before you hire me.
The whole project is public: planned and built the way a large company's platform team works, from requirements to runbooks.
- Product requirements ↗Users, use cases, non-goals and 26 measurable targets
- Architecture ↗Context and container diagrams, upload and download flows, data model
- Threat model ↗STRIDE, threat by threat, with the control for each
- Decision records ↗One ADR per significant choice, with the options and trade-offs
- API contract ↗OpenAPI 3.1, checked against the code on every pull request
- Infrastructure ↗Terraform for AWS and GitHub Actions with OIDC, no static keys
Stack:Python · FastAPIAurora PostgreSQLS3 + KMSEKS · Karpenter · Argo CDSQS · SES · CognitoTerraformGitHub Actions
Before you ask, the short answers.
- Is the code open source?
- It is source-available under the PolyForm Noncommercial licence. Anyone can read it and learn from it. Using it in a business needs a commercial licence, or a custom build.
- Where does our data live?
- In your own AWS account. The reference design keeps every file, record, backup and log inside two regions, with a guard that denies the rest, so the build follows the regions you choose.
- Can it fit our company?
- Yes. A custom build starts from this design and adapts it: your regions, your identity provider, your branding and languages, and your rules for sensitive data.
- Is it finished?
- The requirements, architecture, security design and decisions are complete, and the build is in progress in public. Ask about the current status and what a build for you would take.