Google Forms alternative for file uploads without a Google account

Why public file uploads without a Google account matter for your Google Forms alternative

A public application, insurance claim or supplier onboarding form often has to accept files from people who will never have a Google Account. Google Forms requires a sign-in to upload a file, which excludes applicants, claimants and external suppliers, and the uploaded files land in the form owner's Google Drive. If your organization must keep candidate documents, claim evidence or supplier certificates on infrastructure it controls, that combination is the reason to leave. Self-hosted Formbricks or LimeSurvey can accept anonymous file uploads on your own servers, so the files never leave your environment for a third-party cloud.

Before you commit, check file upload against the exact edition and version you plan to run. Formbricks lists file upload among the features of its self-hosted Community Edition, but its enterprise module is governed by a separate license and the enterprise code ships in the same Docker images, so confirm which features your key or edition actually unlocks. For LimeSurvey, confirm how its file upload question behaves for anonymous respondents on the version you select, since the latest stable release and older lines differ in support status. Test an anonymous upload from a clean browser, not from a logged-in session.

The decisions that matter most are where the uploads are stored, how large a file can be, and how long it is kept. Ask the vendor or your platform team to document the storage path for uploads on your host, the maximum file size and total storage per response, and whether files can be deleted automatically once a retention period ends. Those answers determine your backup scope, your data protection obligations and whether a public form can meet the requirements of the process it supports. Write them down before you publish the form.

What the constraint requires from a public upload form

A public upload form removes the Google Account step, so the controls that Google handled for you now sit with your team. The cards below cover what the respondent sees, where files and answers land, the limits you must set, how long data lives, and who inside the organization can open it.

No respondent account

Respondents on a public Formbricks or LimeSurvey link upload files without signing in to a Google Account, which is the reason to choose these tools for applicants and suppliers. Because no identity is attached, the form cannot tell who submitted a file unless you ask for name and contact fields. Decide which fields identify the respondent, and confirm in the product settings whether the survey is link-based and whether any login or access restriction is switched on.

Where files and responses live

With self-hosted Formbricks or LimeSurvey, uploaded files and answers are written to the servers you run, not to a vendor's cloud or a Drive folder owned by an individual. Confirm the upload storage path or volume, whether backups include it, and whether any hosting provider can access the disk. If you use LimeSurvey Cloud instead, the survey data sits with the provider in the region you select, so check that region before you collect files.

Size and file type limits

Public upload forms accept whatever a stranger sends unless you restrict it, so set the maximum file size and the allowed extensions in the question settings before launch. Test with an oversized file and a renamed executable to see what the form does. Confirm these limits in the chosen product's documentation and in your reverse proxy, since a web server or load balancer may reject large bodies before the application sees them.

Retention and deletion controls

Uploaded files often contain identity documents, bank statements or supplier certificates, so they need a defined retention period. Ask whether the product deletes attachments when a response is deleted, whether a scheduled purge exists, and whether deleted files are removed from backups or only from the application. Write the rule into your privacy notice and test a deletion end to end on a staging instance.

Staff access to uploaded files

Anyone with access to the survey dashboard may be able to download attachments, so review who holds owner, editor and viewer roles. Formbricks gates teams and access roles behind the Enterprise license, while LimeSurvey manages admin users and permissions in its own settings. Confirm which roles can download files, whether downloads are logged, and remove accounts when staff leave.

Where Google Forms stops meeting this requirement

The first test for a public file upload is whether the respondent must sign in to a Google Account to attach a file. In Google Forms, the upload question requires that sign-in, and the uploaded files are saved to the form owner's Drive. For applications, claims and supplier forms sent to people outside your organization, this creates two problems. Respondents without a Google Account cannot complete the upload step, and personal documents end up in a storage area tied to one employee's account rather than to a managed case or records system.

Check these points in your own Google Workspace admin console and in the form itself before you rely on the current setup. Confirm which Drive holds the response folder (a personal My Drive or a shared drive), who can open that folder, whether sharing is limited to your domain, and what happens to the files if the owner's account is suspended, transferred or closed. Also confirm the file type and size limits that apply to the upload question in your edition, since these settings can change and are not repeated here.

The decision to make is whether file storage should stay tied to the form builder at all. If files must come from anonymous public respondents, decide where they will be stored, how long they will be kept, and which small group can read them, then compare each self-hosted option against those answers. The sections below cover how Formbricks and LimeSurvey handle file uploads, storage location and retention in more detail.

Which open-source options take public file uploads

This table compares self-hosted Formbricks and self-hosted LimeSurvey on anonymous file uploads, storage, server needs and licensing for public applications, claims and supplier forms. Read each row against your own intake process, since the file handling details should be confirmed in a test instance before you commit.

Criterion	Self-hosted Formbricks	Self-hosted LimeSurvey
Anonymous upload by respondent	Public link surveys with file upload questions; confirm that respondents need no account in your version	Public survey links with file upload question type; confirm the upload question settings for anonymous respondents
Where files are stored	On the Formbricks host's storage, which you control; confirm whether the storage is local disk or an object store in your deployment	On the LimeSurvey server's upload directory, which you control; confirm backup scope for that directory
Server requirements	Docker deployment with no subscription needed; Helm chart available for cluster hosting	PHP 8.1.29 or later with mbstring and PDO drivers, plus MySQL 8.0, PostgreSQL 14, MariaDB 10.3.38 or MSSQL 2019 or later
Licensing	Core under AGPLv3; enterprise module needs an Enterprise License Key for SSO, roles and audit logs	GPL v2.0 or any later GPL version; Community Edition is free to download and self-host
Forks and modifications	Privately kept forks must be released under AGPLv3 unless covered by an Enterprise license	GPL terms apply to modifications; confirm obligations with your legal team
Workspace limit	Community Edition allows one workspace, which matters only if separate intake teams need separate workspaces	Not applicable
Audit trail for uploads	Audit logs require the Enterprise license; confirm what the Community Edition records	Confirm the response and upload logging available in your version and plugins
Retention and deletion	Confirm how response and file deletion is configured and whether it can be scheduled	Confirm deletion options for responses and uploaded files in your version

Choosing Formbricks or LimeSurvey for your upload workflow

A short application or claim form sent to the public through one link usually needs a few text fields, one or two upload questions and a confirmation message. Formbricks fits this pattern because link surveys and file upload are part of the self-hosted Community Edition, so respondents can submit without a Google Account and you do not need an Enterprise key for this workflow.

Link distribution: Link surveys let respondents open a URL and submit files directly, with no sign-in step.
Upload size and types: Confirm the maximum file size and accepted file types in your installed version, and check the reverse proxy in front of it, since proxy body-size limits often reject large files before the application receives them.
Storage location: Confirm which storage backend holds uploads in your deployment and that it sits on your own servers or on storage your organization contracts directly.
Retention: Confirm how long uploads and responses are kept, and whether deleting a response also removes the stored file rather than only the record.
Exports and integrations: Test a CSV export and a webhook payload with an attached file to see how the file reference appears.

Before committing, submit test applications with a large file and with one file of each accepted type, then check the stored object, the response record and the export.

How to deploy a public upload form on your own servers

This sequence takes a public upload form from a version check to a documented, tested deployment in your own infrastructure, where respondent files and records sit on servers you control. Each step ends with an output your team can verify before the form goes live.

Confirm file upload behavior in the chosen version
Your platform or security engineer installs a test instance of the candidate product and checks how its file upload question works: which file types it accepts, whether it lets anonymous respondents upload without an account, and where it stores what it receives. For Formbricks, confirm that file upload is available in the Community Edition you plan to run. For LimeSurvey, confirm the file upload question type and its settings in the version you intend to deploy. Record the results in writing. The step is done when a respondent can upload a file to the test form with no sign-in.
Choose hosting in your own cloud or data center
Decide which environment will run the application, such as your own cloud account, a private data center or an air-gapped network, and who on your team administers it. Ask your provider or internal team to confirm the region and that uploads will not leave the environment. For LimeSurvey, confirm that the PHP and database server requirements from the project's documentation can be met on the chosen hosts. For Formbricks, confirm that Docker is available on the host. Hosting choice is complete when the environment, owners and region are written in your deployment record.
Configure the database and file storage location
Install the database the product requires: for LimeSurvey, one of MySQL 8.0, PostgreSQL 14, MariaDB 10.3.38 or MSSQL 2019 or later, with PHP 8.1.29 or later and the mbstring and PDO drivers. For Formbricks, configure the database and storage volumes in the Docker Compose setup so uploaded files persist outside the container. Set the upload directory to a path on storage you control, and restrict filesystem permissions to the application service account. The step is done when a test upload survives a container or service restart and appears in the storage path you chose.
Set up HTTPS and the public form URL
Place the application behind a reverse proxy or load balancer with a valid TLS certificate from your certificate authority, and publish the public form address on a domain you own. Confirm that the application's public URL setting matches that address so links and emails are correct. Confirm that the proxy enforces a request body size limit consistent with the upload limit you set in the product, because a mismatch causes failed uploads that look like form errors. The step is done when the form loads over HTTPS and a test submission completes from a machine outside your internal network.
Define upload limits, retention and deletion
Write down the maximum file size, permitted file types and the period each uploaded file and response is kept, then match those rules to the product's settings. Decide who approves deletion and how it is carried out, including whether backups are covered by the same rule. Confirm with your legal or compliance owner before go-live, because retention periods depend on the data you collect. The step is done when the policy is signed off and each setting in the product matches it.
Test with real file types and edge cases
Run a test plan with the file types your respondents will actually send, including large files near the limit, files over the limit, renamed files with mismatched extensions and files with unusual characters in their names. Submit from a browser on a network without a Google sign-in and confirm the upload completes. Verify that rejected files produce a clear error and that accepted files are stored in the location you configured. Keep a log of each test with its result. The step is done when every test case has a recorded outcome and failures have been fixed and retested.
Document the configuration and hand over
Write a configuration record covering the product version, hosts, database, storage path, proxy settings, upload limits, retention rules, backup scope, administrator accounts and the test results. Store it where the operations and compliance teams can read it, and set a recurring review date for version updates. The step is done when the record is reviewed by the owners named in the hosting decision and the platform team has accepted operational responsibility for the form.

Evidence auditors and data protection teams will ask for

Auditors and data protection teams rarely accept a statement that uploads are safe. They ask for records that show how the file collection is configured, where files sit, who can reach them and how long they are kept. The cards below list the artifacts to prepare, and DeployOpen can prepare them as part of a written scope, but independent auditors and certification bodies are the ones who issue any assessment.

Configuration records

Keep a dated export or written record of the survey settings that govern file collection: which questions accept uploads, allowed file types, size limits, required fields and whether the survey is public or link-only. Record the Formbricks or LimeSurvey version in use at the same time, because the same setting can behave differently after an upgrade. Ask the vendor or your implementer to confirm exactly which settings are stored in the database and which live in server configuration files.

Storage location and access lists

Document where uploaded files are written, such as a local volume, a mounted network share or an S3-compatible bucket in your own data center, and which server or storage account holds the keys. Pair this with a list of every account, service user and administrator that can read the storage path or the survey results. Auditors will test this list against the directory, so remove accounts that no longer have a job need.

Retention and deletion procedures

Write down how long uploaded files and linked responses are kept, who approves deletion and how deletion reaches backups and exports. Uploads often live in more places than the response table, including the file store, webhook receivers and downloaded spreadsheets. Test one deletion end to end and keep the ticket and log entry as evidence.

Upload test results

Run a dated set of test uploads that cover accepted types, rejected types, oversized files and files with mismatched extensions. Record what the form accepted, where the file landed and whether it was visible to an anonymous user. These results show that the controls work as configured, which is more useful to a reviewer than a description of intent.

Version and patch records

Keep a register of the survey platform version, its container images or packages, the database server and the PHP runtime where applicable. For LimeSurvey, note the release line in use, because older lines reach end of support on fixed dates and stop receiving fixes. Record the date each patch was applied and who approved it.

Exported responses

Keep a controlled copy of exported responses, with the export date, the filter used and the person who ran it. Store exports in the same access-controlled location as the source data, and do not email them to personal accounts. Check that the export includes or links to the uploaded files, because a spreadsheet that holds only filenames will not show what was actually received.

Questions buyers ask before moving public file uploads

Does a respondent need a Google Account when the form runs on self-hosted Formbricks or LimeSurvey?

No. Both tools serve public surveys by link, so a respondent uploads a file in the browser without signing in to any provider. The account that matters is the administrator account on your own server, which only your staff use. Check the upload field settings on your chosen version, because some tools let you restrict who can submit, and you should decide that on purpose rather than inherit a default. Confirm with your security team that the public URL does not expose the admin interface, and test an upload from a device that has never signed in to anything.

What drives the cost of moving public file uploads to a self-hosted survey tool?

Three components carry the cost. The software is free to download under the Formbricks Community Edition license or the LimeSurvey GPL license, so the main costs are the infrastructure to run it, the storage for files, and the people who configure and operate it. Setup covers the form rebuild, upload field rules, storage placement, backups and access control. Recurring costs are hosting, storage growth, patching and monitoring. Ask any quote to separate one-time implementation from recurring support, and to state which storage and backup assumptions it includes.

What must be confirmed about file size limits and retention before go-live?

Confirm the maximum file size and file type rules for the exact version you deploy, because limits can come from the application, the web server, the PHP or proxy configuration, and the storage backend. Confirm where files are written, how long they stay, and who can delete them. For applications, claims and supplier forms, agree a retention period with your records owner and test that deletion removes both the response and the stored file. Also confirm how backups treat uploaded files, since a backup can keep copies after the live copy is removed.

How long does migrating public file uploads take?

The duration depends on the number of forms, the number and size of existing files, how much of the workflow is rebuilt, and whether files must be moved from Google Drive. Existing uploads in the owner's Drive need an export plan before the account changes. Other variables are the number of approval steps, integrations with downstream systems, and how many people must test. Ask any proposal to list the forms in scope, the file volume it assumes, and the milestones it commits to in writing. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

What does your team need to provide for a self-hosted upload project?

Expect to provide the following:

A hosting environment with the database and PHP or container requirements of the chosen tool, and the network path to it
A named owner for the records retention decision and the privacy notice shown to applicants
Access to the existing forms, questions and a sample of responses, so the rebuild can be checked
A decision on who may administer the tool and how staff authenticate
Test accounts and sample files for upload and deletion testing

The more of this is ready at kickoff, the less the schedule depends on waiting for internal decisions.

Can our own team set up public file uploads without outside help?

Yes, if your team already runs web applications on Linux, can manage a database and TLS certificates, and has someone who can own backups and patching. The software itself is free to self-host, so the question is capacity rather than license. Teams without that experience often underestimate restore testing, storage growth and security configuration of the public endpoint. A fixed-scope engagement can cover planning, configuration, hardening and documentation, while your staff keep day-to-day operation. Decide early which parts you will own after handover.

Which parts of uploads should a security review check first?

Start with the public submission endpoint, the file type and size validation, and where files are stored and served. Check that uploaded files are not publicly listable by URL guessing, that the storage path is not inside the web root, and that access logs record who downloaded a file. Review admin accounts, multi-factor authentication for administrators, and backup encryption. Vulnerability testing of the public form is a useful input before launch. Treat findings as scope for hardening, not as a reason to delay.

Moving existing Drive uploads out of Google

Files that respondents uploaded before the switch are not part of the new setup. Google Forms stores each upload in a folder in the form owner's Drive, so those files stay under that owner's account even after you rebuild the form on a self-hosted platform. Treat existing uploads as a separate transfer plan, with its own inventory, destination and sign-off, rather than assuming that moving the form moves the files with it. Identify which folders hold uploads, who owns them, and which shared links or Sheet formulas still point to them, because those links will keep working for anyone who has them until the files are moved or deleted.

Before any Google account closes or loses access to the Drive, confirm three things in writing: that every file has been copied to the new storage location and checked, that theownership and sharing settings of the source folders are recorded, and that a named person can still reach the files if a response is disputed later. Also confirm whether your retention policy requires you to keep the originals, since deleting them early can remove evidence you may need. The sibling migration and export pages walk through the full process, including how to match uploads to their response records, so use them as the working checklist for this step.

Ask your Google Workspace administrator or the form owner to confirm which accounts hold the upload folders and whether any files were shared with people outside the organization. Those answers decide the order of work: transfer the files tied to open applications or claims first, then archive closed records. Plan for the transfer to take longer than the form rebuild, since file counts and sizes are often not visible until someone inventories the Drive. Keep a log of each file's original location, new location and checksum so the record of each respondent's submission stays complete.

How DeployOpen deploys public upload forms under your constraints

DeployOpen plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a public upload form, that means scoping where files land, who can reach them, how long they are kept and how the setup is documented before any respondent sees it.

How we scope

We confirm which file types, sizes and volumes the public form must accept before choosing a platform.
We document where uploaded files will be stored, who may read them and how they are retrieved.
We agree retention periods and deletion steps for files and responses in the written scope.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We install Formbricks or LimeSurvey on infrastructure you choose, with the database and file storage kept under your control.
We configure upload limits, malware scanning and access controls for the public link, as your scope requires.
We run security testing against the public form and its upload endpoints before go-live.
We integrate the form with your downstream review tools, such as webhooks or exports, as agreed.

How we hand over

You receive documentation of the architecture, configuration, storage paths and retention settings.
We prepare the evidence and control records your compliance assessors may ask for, without issuing any attestation ourselves.
We walk your team through operating the form, reviewing uploads and running exports and deletions.
Independent auditors and certification bodies, not DeployOpen, issue any audit report or certification.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers.
We can apply platform upgrades and retest upload handling after each change you approve.
Confirm with us the response times and coverage terms that will be written into any retainer.
Ask for a written quote based on your scope, which sets out what is one-time and what recurs.