S
SwiftFlow.io
Technical overview

Developer Notes

A condensed architecture brief for technical partners and investors. SwiftFlow.io is deliberately built around guest-only ephemeral usage.

No-auth architecture

There are no user accounts, no logins, no email collection, and no auth tokens. Each visitor is identified only by a random session token stored in their browser's localStorage. The token is opaque and not linked to any identity.

Ephemeral session model

Guest sessions exist for up to 24 hours. File jobs expire within 2 hours. Result download links are signed URLs with a 30-minute lifetime. Nothing is retained beyond its expiry window.

Local vs cloud processing

Files under 30MB are processed locally in the user's browser when possible — they never reach the server. Files above 30MB are routed through a temporary cloud worker and require a one-time €1.00 guest payment.

Stripe guest checkout

Premium processing uses Stripe Checkout in one-time payment mode. No customer object is created, no subscription is opened. Metadata on the payment intent only includes the opaque session token, file job id, and tool key.

Temporary storage

Two private storage buckets isolate input and output: temporary-uploads for inbound files and temporary-results for processed artifacts. Both are accessible only through signed URLs created server-side.

Cleanup jobs

A scheduled worker scans for expired file jobs, removes their files from both buckets, and marks the rows as expired. An audit event is written for every cleanup run. No file content is ever included in audit metadata.

Future real processing engines

Each tool currently runs against a simulated processor. The architecture is designed so individual edge functions can be swapped for real engines (Ghostscript, Tesseract, ExifTool, libvips) without touching the public frontend contract.