Two cloud modes. One direct browser-to-S3 architecture.

Cloud storage on Amazon S3, managed by us.

webQsee operates dedicated Amazon S3 buckets in six AWS regions. When you provision provided storage, the extension picks one of those regions; webQsee handles the bucket, IAM policies, encryption and lifecycle. You upload exactly as you would with your own bucket, the browser still talks directly to S3 over HTTPS, with short-lived presigned URLs minted by webQsee's backend.

How it works (legend for the diagram above)

1. The extension asks webQsee's backend for a presigned upload URL.
2. The backend validates your plan, tenant path prefix, and item caps, then mints a short-lived presigned S3 URL.
3. The extension PUTs the capture bytes directly to S3 using that presigned URL. The bytes never traverse webQsee's backend.
4. Metadata (title, status, owner) is stored in webQsee's EU backend, exactly like with bring-your-own.

Available regions

Pick the region closest to your team. You can run multiple webQsee teams in different regions, but a single team's storage lives in one region only.

Plan limits for provided storage

Item lifetimes are server-enforced. Free-account items are auto-deleted at the 7-day mark. Paid items can be extended past 1 year using a Longer Storage Booster. Item cap can be temporarily raised with a +5 cloud items booster.

What we can and can't see

Since webQsee 9.3, the recorded data of every item (events, requests and responses with their bodies, cookies, attached files such as HAR files, and saved AI analyses) is encrypted in your browser with AES-256 before it reaches the bucket, so a copy of the bucket alone holds nothing readable. Videos, screenshots and thumbnails are not encrypted, so that the browser can play and show them straight from storage. Items uploaded before 9.3 stay as they were stored.

The keys are kept by webQsee, encrypted with a key of our own, so that everyone who may open an item (your team, and whoever holds a link) can read it. That protects against a bucket that leaks, a presigned URL that ends up in a log or a storage credential that escapes. It does not protect against webQsee itself, and it is not end-to-end encryption. If your threat model needs that, use Bring-your-own, where webQsee has no access to your bucket at all.

What ends up where, in both modes.

When something doesn't connect.

Bring-your-own

• CORS error on PUT. Re-check the CORS configuration on the bucket. Methods must include PUT POST GET DELETE HEAD, expose ETag, allow your extension origin.
• 403 Forbidden on PUT. IAM policy ARN doesn't match the bucket name, or the principal tag webqsee-user-id isn't set on the IAM user.
• SignatureDoesNotMatch. Region mismatch between team-wide settings JSON and the bucket's actual region; or v2 instead of v4 signing on min.io.
• net::ERR_CERT_AUTHORITY_INVALID (min.io). The cert must be trusted by every team member's browser; self-signed won't work cross-origin.
• "This bucket must be addressed using the specified endpoint" (min.io). s3ForcePathStyle: true is missing from the connection settings.

webQsee-provided

• "Trial expired" on a free account. Items in provided storage older than 7 days are server-deleted automatically. Upgrade to Pro to keep them.
• "Item cap reached". Free 5 / Pro 20 / Studio 40. Either delete some items, upgrade tier, or buy a +5 cloud items booster.
• Long upload times. Pick a region closer to your team. Provisioning into the wrong region can only be fixed by switching the storage type (one team, one storage).
• "Cannot create temporary storage". The self-hosted min.io provisioning tier was retired; create a new provided storage in a non-temporary region instead.