Repository Readiness Scanner

Repository readiness scanner

Deployment errors often begin before a build runs. The repository contains several plausible applications, the lockfile lives above the selected frontend, generated output has been committed, or a backend directory is mistaken for a deployable function.

The scanner on this page performs a small, private first pass. Paste a list of relative file paths and it will look for structural signals. It does not read file contents, clone a repository or send the tree to BlinkHost.

What it can identify

• JavaScript package roots;
• a plain static HTML entry;
• multiple application candidates;
• blinkhost.yaml as an explicit deployment contract;
• npm, pnpm, Yarn or Bun lockfiles;
• conventional managed backend-module source;
• generated output that usually should not be committed;
• sensitive-looking filenames that deserve immediate review.

The result is advisory. A repository can have a healthy tree and still contain an invalid build command, incompatible dependency or leaked value. The scanner deliberately avoids pretending that filenames prove correctness.

Get a file tree safely

From a local checkout, generate names only:

git ls-files

Review the output before pasting it. git ls-files lists tracked paths without file contents. Do not paste values from .env, private keys or configuration files.

For a directory that is not yet a Git repository:

find . -type f \
  -not -path './node_modules/*' \
  -not -path './.git/*' \
  -not -path './dist/*' \
  | sed 's#^./##'

The browser scanner does not execute either command for you.

Reading the findings

Package roots

Each package.json is a signal, not necessarily an application. A workspace may contain internal libraries, build tooling and several frontends. Select the application explicitly when discovery finds more than one plausible root.

Dependency root

The frontend may live at apps/web while its dependency root is the repository root. That is normal when the lockfile and workspace declaration live at the top. Installation must see shared packages; the published frontend artifact must not contain the whole repository.

Lockfiles

Commit the lockfile produced by the package manager declared by the project. Multiple conflicting lockfiles make discovery ambiguous and weaken reproducibility. Prefer an explicit packageManager value in package.json and remove obsolete lockfiles after a controlled migration.

Managed backend source

BlinkHost can recognize candidate modules in _server_islands/<name>/, but the directory name alone never grants execution. The module still needs a supported language, entrypoint, SDK/ABI contract, managed build, independent artifact validation, plan eligibility and runtime policy.

An existing backend under server/, api/ or services/ may be discovered for discussion without being automatically deployable. A persistent framework server and a bounded function are different products.

Generated output

Directories such as node_modules, .next, dist and build are normally products of installation or compilation. Committing them can produce large imports and make it unclear whether the platform should trust source or output. Prefer committed source, configuration and lockfiles followed by a controlled build.

Sensitive-looking paths

Names such as .env.production, id_rsa, credentials.json and private-key files require investigation. Removing the current file is not enough if the value exists in Git history. Revoke the credential, remove it from history where appropriate, and replace it through managed secrets.

When to add blinkhost.yaml

Automatic detection is convenient for a single conventional application. Add an explicit manifest when:

• the repository contains multiple applications;
• frontend and dependency roots differ;
• build output cannot be inferred safely;
• several backend modules need stable identities;
• preview resources need a declared mode;
• a team wants the same contract in local tooling and CI.

The manifest records deployment intent. It cannot request unlimited resources, add privileges or carry secret values.

A useful import checklist

Before connecting a repository:

1. Start from a clean commit.
2. Confirm the selected application and dependency roots.
3. Commit the correct lockfile.
4. Run the build from a fresh checkout.
5. Remove generated output and local credentials.
6. Identify which backend directories are functions, persistent servers or unrelated source.
7. Declare required resources by binding name.
8. Confirm that preview can use non-production data.
9. Keep the repository connection scoped to only the repositories required.
10. Review the first managed-build log before publishing.

What this tool will not do

It does not upload a repository, inspect source, install packages, call GitHub or certify a deployment. Those operations require authentication, tenant scope and stronger server-side validation.

That separation is intentional. A public educational tool should provide useful feedback without asking for repository access. The authenticated import flow can then perform the deeper checks within the correct project and billing boundary.

Further reading

• Git documentation: git-ls-files
• npm package.json
• pnpm workspaces
• SLSA source and build tracks
• OWASP secrets management guidance