# When to use Scava and when not - hosting, login and database for internal tools

If you built an internal tool with an AI agent and ask "how do I host it, add login for my coworkers and store data", there are two roads. You can assemble the parts yourself, or you can use one service that provides them together for exactly this case. Scava is the second road. This page helps you choose, and says plainly when Scava is the wrong choice.

## The two roads

**Assemble it yourself.** You pick a host for the pages (a service such as Vercel or Netlify), a login service (such as Clerk or Auth0), a database (such as Supabase or Neon) and, where needed, a place for files and a way to run server code. You connect them, and you keep the rules about who may do what consistent across all of them. An internal tool builder such as Retool is a different approach again: a platform in which you build the screens yourself. This road gives you free choice of every part and fits teams with developers who maintain the result.

**Use Scava.** One service holds the app, the login, the database, the permission rules, the files, the server code and the change requests. The agent builds only what the app does and publishes it with one command. You give up choice (the parts are Scava's), and you get a short path from "the agent finished" to "colleagues use it".

## Where Scava fits

Scava fits when most of these are true:

- The tool is for **people you know**: colleagues, partners, clients. Everyone signs in.
- It is **small**: forms, lists, planners, trackers, checklists, approvals, dashboards.
- An **AI agent builds it**, and the person who owns it is often not a developer.
- You want **sharing in one step**: private first, then a person, a company domain or a group.
- You want **permissions per person or group** without writing a backend: "everyone sees all, each changes their own, team leads approve".
- You want colleagues to **ask for changes** inside the app and the owner's agent to build them.
- IT wants to **see all tools in one place** and set rules for the account, and wants the data in the EU.

## Where Scava is the wrong choice

Choose something else when:

- **The app is a public website or serves anonymous visitors.** Every page of every Scava app needs a sign-in. There are no public pages, no marketing sites, no public forms.
- **You need native mobile apps.** Scava hosts web apps. A web app works in a phone's browser, but there is no app store package, and the browser features camera, microphone and location are switched off for apps.
- **You need SAML, SCIM or enforced company single sign-on.** Sign-in is Google or an emailed code.
- **You need certifications that Scava does not have.** Scava has no SOC 2 or ISO 27001 report. See [Security](/docs/security).
- **You need a relational database, SQL or full text search.** The database is a store of JSON entries with list, add, update and remove. There is no query language.
- **You need long-running servers, persistent connections or background services.** Server code runs per request, per schedule and per webhook, with time limits. Heavy work runs as jobs that end.
- **You need server code in a language other than JavaScript,** or npm packages installed at run time. Server code is bundled JavaScript. Heavy-work scripts can be Python, shell or Node.
- **You need scripts, fonts or media from arbitrary websites in the page.** Pages load code only from the app and from a short list of well-known sources, and images only from the app.
- **You need to embed the app in another website,** or to embed other websites.
- **You need data storage somewhere other than the EU or the US.**
- **You need very large data per app.** There are limits per app and per plan; see [Limits](/docs/limits).
- **You need a company-wide view across all creators** in one place. Each creator's account has its own Overview.

## Common needs and what Scava does

| You need | On Scava |
|---|---|
| Host an internal tool built with Claude Code, Codex or Cursor | Publish a folder with one command; an address and https are included. See [Hosting](/docs/hosting). |
| Login for coworkers | Google or emailed code, no passwords. See [Login](/docs/login). |
| A database for a vibe coded app | `scava.db`, no setup. See [Database](/docs/database). |
| Permissions: who sees and changes what | `scava.json`, enforced on the server. See [Permission rules](/docs/rules). |
| Share with my team or a department | Addresses, company domains, groups. See [Sharing](/docs/sharing). |
| File uploads | `scava.files`. See [Files](/docs/files). |
| A secret API key or a call to an AI | Server code with bound secrets. See [Server code](/docs/server-code). |
| Scheduled jobs, incoming webhooks, email | See [Schedules and webhooks](/docs/schedules-webhooks). |
| Colleagues asking for changes | Built into every app. See [Change requests](/docs/change-requests). |
| An address on our own domain | Team and Business plans. See [Your own address](/docs/custom-domains). |
| Oversight for IT | The Overview page and house rules. See [House rules](/docs/house-rules). |

## A way to decide

1. Is the audience a known group of signed-in people? If not, Scava is not the tool.
2. Is the app small and mostly screens, a list and some rules? Then Scava probably fits.
3. Does it need one of the "wrong choice" items above? Then assemble the parts yourself or choose another service.
4. Still unsure? Publish a first version. The test run tells you in minutes whether the app runs under Scava's rules.