Connecting to a Cloud Database

ReVISit is inherently a serverless program. As such, we developed a storage engine architecture in order to store the data that is gathered from users as they move through the study. While you can test the program locally using the browser's local storage, you will need to set up some sort of cloud database in order to save study participant data. Our intention is that those who create the study have full control over the data that is generated by participants — no data is ever linked back to the reVISit repository or those who have contributed to its creation. See the Deployment section for more information about deploying your study to GitHub.io once the connection to Firebase has been set up.

We provide multiple storage engines and an abstract class that you can extend to create your own storage engine. There are two cloud databases that reVISit supports out of the box: Firebase and Supabase. Firebase is a Google product that provides a real-time NoSQL database and storage solution, while Supabase is an open-source alternative that provides similar functionality that can be self-hosted (perfect for researchers who operate under strict data privacy regulations).

Avoiding the Default Storage Backend in Deployments

When a study is deployed to an external domain, reVISit warns if it detects that the study is using a default reVISit Firebase or Supabase backend. In the study list, this appears as a parser warning. When you open the study directly, its header shows an orange Default Firebase or Default Supabase badge with more detail in a tooltip.

The warning does not prevent the study from running, but participant data might be stored in a backend that you do not manage. Before collecting production data, update the deployment environment variables and rebuild the study:

• For Firebase, set VITE_STORAGE_ENGINE=firebase and replace VITE_FIREBASE_CONFIG with the configuration for your own Firebase project.
• For Supabase, set VITE_STORAGE_ENGINE=supabase and replace VITE_SUPABASE_URL and related credentials with those for your own Supabase project.
• Alternatively, choose another storage engine that is appropriate for your deployment.

The warning is not shown for local development (localhost or 127.0.0.1) or for reVISit-managed domains such as revisit.dev and vdl.sci.utah.edu. These deployment settings are separate from the Study Config.

Recovering from Cloud Storage Failures

In a production build configured with VITE_STORAGE_ENGINE=firebase or VITE_STORAGE_ENGINE=supabase, ReVISit does not fall back to local storage when the configured cloud backend cannot connect. Participation remains blocked until the backend is available, so production data is not collected without being saved to the Study Designer's configured storage.

• If the connection fails when a Participant opens a study, ask them to check their internet connection and select Reconnect. This reloads the page and tries the configured storage again.
• If saving an answer or provenance fails during a study, ReVISit shows a blocking Failed to Save Response modal. Ask the Participant to select Retry and wait for the save to complete before continuing.
• Participants can copy the modal diagnostics or use its contact-email link to send them to the Study Designer for support.

Non-production builds can still warn and fall back to local storage when the configured cloud storage cannot connect. That fallback data is not automatically synchronized to Firebase or Supabase after the connection recovers.