What does Vercel say about Hobby use?
Vercel describes Hobby as restricted to 'non-commercial, personal use'. A company internal tool should therefore be reviewed against those terms before deployment, even if only employees can open it. Use the provider's current guidance and ask Vercel about an unclear case; a private URL or low request count does not settle permitted use.
Reviewed 31 October 2026. The linked Hobby documentation states the restriction and points to Vercel's fair-use guidance. This page explains the deployment decision to make; it is not legal advice or an interpretation of a particular organization's agreement. Your organization's approved provider contract and Vercel's current terms are the appropriate references for a final determination.
Separate a personal experiment from a team dependency
A fictional dashboard made to learn a framework and a dashboard used to route today's customer cases have different operating contexts. Before sharing the latter, write down who uses it, what work it supports and who is accountable if it stops working. Include whether the app holds company or customer records and whether colleagues depend on it to make decisions.
Do not decide permitted use by the app's size. A tiny request form can support a business process, while a larger personal experiment can remain an individual project. Similarly, a page without payments can still be used in commercial activity. Avoid converting this distinction into an automated legal classification. Give the actual use case to the person who owns hosting procurement or to the provider when the terms are unclear.
Review the account as well as the plan
An employee's personal provider account introduces ownership questions beyond plan eligibility. Who can recover access when the builder leaves? Who receives usage notices? Who may change environment variables, disable the app or inspect a production failure? Record the answers before the tool becomes part of a routine workflow. A colleague knowing the public link is not a substitute for organization-owned administration.
Put the account and spending responsibility through the process your team uses for other operational services. Review the intended plan with that account in mind, and separate any trial or introductory allowance from a durable arrangement. Confirm how usage is measured and what happens when the included usage is exhausted. This guide deliberately avoids quoting prices or allowances that can change independently of the application.
A provider decision checklist for internal apps
Keep the review tied to the application you intend to run. Read its framework and production build settings, list required server functions and identify the persistent services it uses. Note any background tasks, long-lived connections or file writes. Then evaluate eligible provider products against those requirements and the account's contractual terms before comparing cost.
Include security and recovery in the same record. Name the App Owner, define the launch audience, complete the linked direct-access checks and agree how the team handles an incident. Review secret names and storage locations without pasting secret values into a document. Verify the app from a deployed build with fictional data before introducing company information. A plan review and a working build answer different questions, and both are required for a useful handoff.
- Identify the real business use and accountable owner.
- Confirm permitted use and organization-controlled hosting.
- Check workload compatibility, storage and estimated usage.
- Test the intended audience and direct access authentication.
- Save the deployment result and the support route.
How SpringRoll handles managed placement
SpringRoll's managed deployment path evaluates the application against available Vercel and Cloudflare workloads. Eligibility and provider terms constrain the choices before an estimated price is compared. You do not need to choose a personal Hobby account to publish an app through that path. Inspect the executed placement on the deployment receipt rather than assuming that the lowest advertised tier was selected.
The receipt records the selected runtime, estimate, assumptions and reasons for rejected candidates. Read those assumptions alongside the app's actual data and traffic needs. An estimate is not a fixed invoice, and managed placement is not a promise that every workload is supported. If the app requires persistent local storage or a separate worker, resolve that requirement before attempting the deployment.
What if the prototype already runs on a personal account?
Start by taking an inventory rather than circulating more copies of the URL. Preserve the source, build settings, variable names and current behaviour. Identify whether the app already contains company records or serves colleagues. Ask the hosting owner to review the present use and the intended destination. Do not paste provider credentials into the generated app as a shortcut to moving it.
Prepare the next deployment with fictional data and verify the same task at the destination. Add durable shared storage and server-side permissions where the prototype lacks them. When the new release works, share the intended launch link and review access to the old deployment. An orderly move includes the obsolete URL and any old secrets, rather than assuming the migration is complete when a second site becomes reachable.
Keep plan compliance separate from app security
Moving to a plan appropriate for company use does not add application authorization by itself. Test allowed and denied identities with the linked direct-access checklist, and check that data calls use only the application's approved scope.
Preserve these results with the release, environment and owner. Repeat the relevant checks when data sensitivity, audience or runtime requirements change. If a team is uncertain about provider terms, it should get an answer from the provider or its legal reviewer. If it is uncertain about a data grant, it should ask the data owner. They are separate responsibilities and should remain visible in the operating handoff.
Frequently asked questions
Does employee-only access make the app personal?
No conclusion follows from the audience alone. Review the work the app supports against Vercel's current terms and your organization's agreement.
Does a free trial settle long-term eligibility?
No. Review the ongoing plan, permitted use and account ownership separately from any trial allowance.
Does SpringRoll ask me to supply a Hobby account?
The managed path uses SpringRoll-managed hosting and records the selected eligible workload. Review that placement and its assumptions for your app.