Before hosting an AI or Lovable website: inventory the repository

Having code in Git does not yet answer a basic purchasing question: what must keep running? A website may serve static files, run a server or depend on external services even when its home page looks simple.

Inventory the repository before choosing a plan. A useful result lists components, responsibilities and missing evidence. This guide uses an original MIT tool, with 12 local tests verified on Node 22.23.3. Its cases are synthetic manifests, not real Lovable exports or built applications.

If the repository comes from Lovable and you want to host it outside the platform, the guide to hosting a Lovable app elsewhere explains what can stay in Lovable Cloud and what needs a separate migration.

Start with the actual project

Lovable documentation says projects created from 13 May 2026 use TanStack Start with server code; earlier projects use React and Vite with static output.

Do not decide from the name “React” or a date alone. Record commit, branch and subdirectory; inspect package.json, the lockfile, configuration and server entry points. In a monorepo, the root manifest may describe development tools rather than the application you will publish. Identify its directory.

For a code copy under your control, see Lovable Git sync. A code copy does not establish that external authentication, data or files are included and working.

Run a bounded inventory

Use Node 22.23.3, the tested version, and retain the licence. The tool has no external dependencies or lockfile; npm ci is unnecessary. The test manifests contain marker versions and commands: do not install their dependencies or run their scripts.

git clone https://github.com/ocentelles/hostbrid-example-inventory.git
cd hostbrid-example-inventory
git checkout 150c8d09ea2fe0b511dbeac5cdd89e182d7f9b47
node --version
node --test test.mjs
node inventory.mjs fixtures/static
node inventory.mjs fixtures/external
node inventory.mjs fixtures/server
node inventory.mjs fixtures/ambiguous

node --version should show v22.23.3, and the test should finish with 12 passes. These four cases produce candidates static, static with an external-client signal, server and indeterminate. A fifth malformed-JSON case returns an error and nonzero exit: a negative test, not an application to install.

For a stable, trusted copy of a repository you own:

node inventory.mjs /path/to/own/repository

Replace the sample path with yours. The CLI reads a root package.json up to 256 KiB and checks the presence of an allowlist of configuration filenames. It does not traverse directories, run scripts, read .env or source/configuration contents, contact services or upload data.

Treat the result as a hypothesis

This is a subset of fields from the synthetic static case:

{
  "candidate": "static",
  "scripts_executed": false,
  "build_verified": false,
  "env_files_read": false,
  "source_contents_read": false
}

static and server are marker-based candidates. build_verified:false explicitly identifies missing evidence. indeterminate is useful when there is not enough information: do not force a static purchase to hide the uncertainty.

A Dockerfile does not prove what runs inside. Vite can participate in a server application; Next can export static files despite the conservative server marker. An Astro adapter, renamed configuration or dynamically loaded packages may escape the analysis. The tool does not read commands to classify them or inspect workspace subprojects.

Separate three layers before choosing hosting

A Supabase-client marker does not prove a migrated backend. Static frontend files may still call an external backend: that service’s cost and operation remain in the inventory. The official external-hosting guide separates frontend and backend moves; moving PostgreSQL alone does not move authentication, storage, realtime or Edge Functions.

To identify managed Cloud or your own Supabase, open Cloud settings: its icon appears in both cases. Lovable Cloud does not appear in your personal Supabase Dashboard. Follow the official backend-identification guide. The CLI does not query those settings or identify the owning account; do not share tokens or logs.

If keeping the backend, test origins and callbacks, sessions, authorised access, private objects and functions from the new environment. If considering a move, add backup, restore, comparison and rollback; retain the original until the trial is checked. These are pending tasks, not workflows demonstrated by the CLI.

The report is not a secret audit

Output omits versions, commands, project paths and contents, but the manifest is still parsed in memory and some printed names can carry information. Review the report before sharing. Do not paste .env, tokens, customer dumps or complete logs into a hosting enquiry.

The tool cannot certify absence of secrets, vulnerabilities or dependencies. It is not a sandbox against a hostile filesystem. Supabase keys distinguish publishable and secret keys: privileged keys do not belong in the browser. That requires separate review of real source and built output.

Turn the inventory into a decision

Static Projects is a candidate once static output has been tested. For a permanent process, check Projects services, a plan including services with available quota, runtime and limits. A VPS may fit if you need system control and take responsibility for updates, networking, monitoring and backups. This inventory does not demonstrate TanStack compatibility, automatic migration or free Docker services.

Review cost by component: hosting, retained backend, email, AI, domain and operation. After diagnosis, follow the static React recipe, Node server checks or form diagnostics, according to what your application actually needs. They are separate steps; a fixture does not replace their tests.