A closer look at Flare
Explore real screens before you install, or discover a feature you have not tried yet. The walkthrough uses captured app screens; the settings lab runs locally in your browser. Neither connects to a live account.
Explore the workspace
Choose a step, then enlarge the screenshot to inspect the details. The screenshots use demonstration accounts and files.
A home for every file
Scroll through every matching file without changing pages. The slim date rail lets you jump into your upload history; search, folders, and filters keep the view focused.
Read the complete guide →Watch real workflows
These short, silent recordings capture actual browser interactions with Flare and an isolated test database. Playback is manual and downloads only when requested. The written steps below each video are also its descriptive transcript.
Browse a large library
- Open Files in the isolated demonstration account. The library shows 12,000 files and its newest uploads from October 2026.
- Scroll down through the file cards. More files appear in the same continuous list, and the slim rail at the right shows the current upload period.
- Drag the date rail to the middle of the upload history, then press End to jump to the oldest uploads, from July 2018. Each destination loads directly without stepping through intervening pages.
- Return to the beginning, choose Select, and select visible files. Scroll until those cards leave the view; the selected count stays available in the selection bar. Return to the beginning and confirm the original cards remain selected.
- Finish the selection with Done and search for Northern lights. The count becomes 1,000 files. Clear the search to restore the full library.
This recording uses real application requests and a disposable account seeded with 12,000 demonstration files across several years. The upload dates and file contents are fixtures; the scrolling, date jumps, selection, and filtering are actual browser interactions. It does not measure the performance of your server or storage provider. Follow the library guide for keyboard controls, selection limits, and retry behavior.
Browse the same library on a phone
- Open the same demonstration library at a 390px viewport. The single-column cards and date label fit beside the narrow rail.
- Scroll down through the newest uploads.
- Focus the rail and press End to reach July 2018, then Home to return to the newest uploads.
This is Chromium rendering the real application at mobile width, using the same local database as the desktop recording. It demonstrates the narrow layout and full-library date navigation; it is not a physical-phone or touch-gesture recording.
Review and revoke browser sessions
- Open Profile → Account on the isolated demonstration instance and scroll to Active sessions.
- Review This browser and the other signed-in browser sessions, including their sign-in methods and activity times.
- Inspect Login history, where a rejected demonstration password appears as Failed beside successful sign-ins.
- Choose Revoke session on another browser and confirm Revoke session. The list reloads without that session; the browser check separately verifies its next authenticated request is rejected.
- Choose Revoke all sessions and confirm Revoke all and sign out. The current browser returns to sign-in too.
The recording uses real browser sign-ins and server revocations against a disposable database. Revocation applies to subsequent protected requests; API credentials and previously issued storage URLs have separate lifetimes. Follow the account guide. The recording stays at desktop width. Separate screenshots and browser checks in that guide cover the mobile controls.
Investigate instance activity
- Open Audit log on the isolated demonstration instance with an administrator session.
- Review recorded activity produced by a real demonstration upload, visibility changes, download, denied access, actual OCR of a generated receipt image, a rejected OCR request on a text file, deletion, role assignment, and settings change.
- Enter quarterly-report.txt in Search activity, choose Apply filters, and expand a File delete event. The deleted filename and acting account remain recorded.
- Review Recorded details and request context. Choose Clear filters, set Outcome to Denied, and apply to inspect refused requests.
- Add missing-demo-filename to search and apply. Flare shows No activity matches these filters. Clear the filters and return to recent instance activity.
These screens display real events produced by demonstration operations. The setup uses API requests before opening the recorded audit page; the recording shows investigation of those events. The receipt image is generated test input, and the server performs real OCR; it is not a fabricated application screenshot. The audit log begins when the feature is installed, retains selected metadata, and does not capture every request outside Flare. It is not a tamper-evident ledger. Read the audit guide for access, filtering, privacy, and retention; the guide also includes desktop and mobile screenshots. The recording stays at desktop width; mobile layout is covered by those separate captures and browser checks.
The audit guide also includes a separate real-server archive investigation capture, produced by creating, browsing, downloading from, and extracting an archive on the disposable instance. Reproduce the combined archive/audit check to verify those events; they are separate from the recorded investigation above.
Browse and extract an archive
- In Alex Morgan's demonstration library, open the menu for Field kit.zip and choose Browse archive. Flare displays four files and four folders.
- Search for README and select guide/README.md. Its text appears beside the matching path, with a Download entry action.
- Search for flare-icon and select images/flare-icon.png. Flare previews the verified PNG directly from the archive.
- Clear the search and choose Extract all. Select Campaigns under Save to and enter Field kit unpacked as New folder name.
- Keep Private (no profile) and choose Extract files. Archive extracted confirms that four private files were saved and the original archive remains unchanged.
- Choose Open folder. The wrapper contains drafts, empty, guide, and images. Open guide to see the new README.md and checklist.csv library files.
The app reads a real stored ZIP and publishes its new folder tree to the disposable database. The browser checks also verify the extracted bytes, the preserved empty directory, and the unchanged source archive. Follow the archive guide and reproduce the checks.
Create an archive with a saved profile
- In Files, choose Select and select Field notes.txt and Launch checklist.csv.
- Choose Create archive, enter Launch handoff.zip, leave Format on ZIP, and select Campaigns as the destination. The initial profile choice is Private (no profile).
- Explicitly select Public handoff under Upload profile. Review the summary: public visibility, 1 week, then private, randomized URL filenames, Delivery share page, and one tag. The form warns that public outputs expose their contents.
- Choose Create archive. Archive created confirms the new file without changing the originals.
- Choose Open archive. The generated ZIP contains Field notes.txt and Launch checklist.csv at its root.
This is a real stored ZIP generated from two private fixture files. The explicit profile makes the result public, applies the Approved tag, and sets expiration to make it private after one week. The server checks the displayed profile and effective settings before publication, including inherited defaults. The same browser suite separately exercises private TAR.GZ creation and profile-based extraction. Review profile and privacy choices before packaging your own files.
Browse and download a shared archive
- Open the public Field kit.zip share page while signed out. Archive contents shows four files and four folders inline, above the whole-file Download action.
- Open guide and select README.md. The text appears beside the folder contents.
- Choose Download entry. The browser saves the actual README.md bytes and keeps the share page open.
- Search for flare-icon and select images/flare-icon.png. The verified image appears without extracting files into an account.
This recording uses an anonymous visitor and a real unprotected public archive. The browser checks verify the downloaded bytes and that no Extract all action appears. Separate, unrecorded checks exercise protected-file access, reject missing or incorrect passwords, and deny unrelated visitors after the source becomes private. The guide includes the password gate, unlocked page, and mobile captures. Existing file visibility and password rules apply to every shared entry request.
Enable, use, and recover two-factor authentication
- Sign in to the isolated Alex Morgan account and open Profile → Account → Sign-in security.
- Choose Set up authenticator, confirm the current password, and choose Continue. The real setup dialog displays the QR code and manual key; both are concealed before the recording captures a frame.
- Enter a current authenticator code and choose Enable two-factor authentication.
- In Save your recovery codes, download the ten codes, select I have saved my recovery codes somewhere safe., and choose Done. The recording conceals the code values; the test deletes the downloaded fixture file afterward.
- Choose Sign in again, submit the email/password, then enter a fresh code at Verify your identity. The dashboard opens only after the second step.
- Sign out, submit the password again, and choose Use a recovery code. One unused code opens the dashboard.
- Sign out and try that same recovery code again. Flare rejects it. Enter a different unused code to regain access.
- Return to Sign-in security. Choose Replace recovery codes. The recent recovery-code sign-in supplies identity proof, so no second code is needed. Save the replacement set and sign in again.
- Sign in with a replacement recovery code. Choose Turn off and finish Turn off two-factor authentication using the recent recovery-code sign-in as identity proof. After signing in again, the password alone opens the dashboard.
These are real enrollment, login, recovery, and removal operations against a disposable database. The authenticator code is generated by the test's TOTP client; no personal authenticator account is involved. QR/setup secrets, passwords, and recovery values are concealed throughout the capture. The recording stays at desktop width; the guide also shows real mobile captures, and the browser verification separately exercises recovery at 390px wide. Follow the account security guide for your own account, and reproduce the checks locally.
Create, use, and remove a passkey
- Sign in to the isolated Jamie Rivera account and open Sign-in security.
- Choose Add a passkey, name it Personal laptop, confirm the password, and choose Create passkey.
- Registration succeeds and ends the previous sessions. Choose Sign in again, then Sign in with a passkey. The verified credential opens the dashboard without entering the account password.
- Return to Sign-in security and inspect Personal laptop in the passkey list.
- Choose its Rename action and save My laptop passkey. The recent passkey sign-in supplies identity proof, and renaming keeps the session open.
- Choose Remove, confirm Remove passkey, then choose Sign in again.
- Try Sign in with a passkey using the credential still held by the test device. Flare rejects the removed credential and stays signed out.
The app and server operations are real; Chromium's virtual authenticator simulates the device. It performs actual WebAuthn cryptographic ceremonies but does not display a physical device's fingerprint, face, PIN, or security-key prompt. Your browser/provider supplies those prompts on your own device. This recording demonstrates server registration, passwordless sign-in, renaming, and revocation; it is not a hardware compatibility test. Add a passkey.
Require a passkey and recover access
- Sign in to the isolated Jamie Rivera account, add Required sign-in key, and sign in again with that passkey.
- Open Sign-in security → Require passkey to sign in. Review the password/authenticator/SSO restriction, then choose Require passkey. The recent passkey sign-in confirms the change.
- In Save your passkey recovery codes, download the ten dedicated codes, select I have saved my recovery codes somewhere safe., and choose Done. Values are concealed in the recording; the test deletes the downloaded fixture file. Existing browser sessions are invalidated.
- Choose Sign in again and try the correct password. Flare refuses it and explains that a passkey is required. Sign in with a passkey opens the account; the requirement remains Required.
- Sign out and choose Use a passkey recovery code. Enter the account email with different capitalization and one dedicated code, then choose Sign in with recovery code. The case-insensitive lookup succeeds: the dashboard opens without entering a password, and the requirement stays on.
- Sign out and try that same code again. Flare rejects it. A different unused code restores access.
- Open Replace passkey recovery codes, use the recent dedicated recovery sign-in as proof, and choose Replace codes. Save the replacement set before signing in again. An unused code from the old set is now rejected; a new code works.
- Choose Allow other sign-in methods → Allow other methods. The fresh dedicated recovery sign-in confirms this explicit change. After signing in again, the password works and the dedicated recovery count is zero.
This is a real local account workflow; Chromium's virtual authenticator replaces the physical device. Password rejection and dedicated recovery use the actual server, with no mocked authentication responses. The same browser checks also verify rejection of stale sessions and last-key removal while required. The recording stays at desktop width; the guide includes separate mobile captures. It does not demonstrate a live external SSO provider or native biometric prompt. Prepare required-passkey recovery before enabling it on your account.
Create and assign a role
- Open Roles and choose Create role.
- Name the role Content reviewer, choose an amber color, and describe its purpose: “Review uploads and help keep the workspace tidy.” Set Position to
30. - Search for View users and turn it on.
- Search for moderation. Turn on View all content and Edit all content; leave Delete all content off.
- Choose Save role. The role exists without any members yet.
- Open Users, edit the demonstration account Taylor Reed, select Content reviewer, and choose Save Changes.
- Return to Roles, select Content reviewer, and confirm it shows 1 member and the selected moderation permissions.
This recording makes real role and account changes in an isolated instance. Everyone remains the shared baseline; the new role adds review/edit capabilities without granting deletion of other users' content or settings administration. Read the role guide for hierarchy and permission details. The separate roles lab below is a local simulation.
Organize and upload
- In Files, create a folder named Project launch.
- Select two existing files and move them into that folder.
- Open the folder and create a Week 39 subfolder.
- Use Upload here to upload a project checklist into the subfolder.
- Open the destination from the completed upload.
Moving a file preserves its individual share link. Read the folders guide.
Share a collection, then revoke access
- Open a folder’s sharing controls and create a share link.
- Visit the collection as a recipient. Public files appear; a password-protected file appears as a generic locked tile.
- Return to the owner’s sharing controls and disable the link.
- Revisit the collection URL to confirm the shared page is unavailable.
Disabling a folder link does not revoke a file’s separate public URL. Understand sharing boundaries.
Open a protected file
- Open a locked tile from a shared folder.
- Enter an incorrect password; the file stays locked and its name stays hidden.
- Enter the correct password to reveal the file and its normal viewer.
This flow is for a public file protected by a password. Private files are not included in a public folder share.
Roles and permissions lab
Try Everyone, an additional contributor role, and Administrator. Removing a permission from one role does not deny a grant from another. The simulation also shows why a named token needs both its scope and its owner's current permission. Follow the real role workflow.
Model one account's upload permission. These controls are an educational simulation; they never read an account or change a real role.
Dashboard upload: Allowed
Everyone grants uploads, even without an additional role.
Named-token upload: Allowed — requires both the account permission and the token scope.
This models role and scope checks only. Real uploads also require a valid session or token, email eligibility, available storage, valid file content, and the instance's size limits. Administrator does not expand a token's scopes.
Upload options lab
Try the precedence rules behind account defaults, saved profiles, and per-upload choices. This is an educational model of the upload profile rules, with explicit inputs; it does not read your account.
Change the inputs to see which visibility setting wins. Flare starts with public visibility; make a private profile your default to change your everyday uploads. Nothing is uploaded or saved here.
People with the share URL can view the file unless it also has password protection.
When the expiration worker processes the deadline, the file is deleted. Keep a separate copy if you need it later.
Build an API request
Generate curl, JavaScript, or Python examples with your instance address. The builder never asks for a token and never sends a request.
Choose an operation and copy a working starting point. Set FLARE_TOKEN in your terminal to a named token with the required scope. The token owner must also have the current role permission. This builder covers named-token operations; account security changes and owner-library archive operations require a browser session. Use the signed-in Flare interface for bulk tag editing. Shared archive browsing and entry downloads instead follow file visibility and password rules; this token builder does not authorize them.
curl --fail-with-body 'https://files.example.com/api/files' \
-H "Authorization: Bearer $FLARE_TOKEN" \
-F "file=@./screenshot.png"Credentials never enter this demo. Run these requests yourself against your instance; uploads and short-link creation change your data.