Frontend and repository compatibility

Supported frontend contract

BlinkHost accepts Astro, static HTML, React, Solid, Svelte and Vue frontends. Managed repository builds support npm, pnpm, Yarn and Bun. A frontend may be at the repository root or nested under paths such as frontend/, client/ or apps/web/. The application root can contain sibling backend and shared-code directories.

Import detection proposes candidates; it does not promise that every repository using a named framework will build. A managed build requires a valid package manifest, a committed lockfile, a safe named build script and the correct static output directory. A monorepo may keep its lockfile in the selected frontend directory or an ancestor dependency root declared in blinkhost.yaml. BlinkHost installs dependencies at that dependency root and runs the frontend build from the frontend directory. When several package-manager lockfiles are present, identify the intended manager with the standard packageManager field or an explicit BlinkHost manifest.

Static HTML with an index.html does not require a package manager or a build command. Keep a package-free static frontend in its own directory when the repository also contains backend source; BlinkHost blocks a direct static output that could publish server files to the browser. Unsupported application targets such as a server-rendered Next.js, Nuxt, SvelteKit, Remix or React Router server are reported rather than misclassified as a static site. A framework that can produce a self-contained static export may be imported only when its declared build emits one of the supported static frontend outputs; long-running frontend servers are not production targets on the edge runtime. Create React App's standard build/ output and Vite's standard dist/ output are detected. Custom build pipelines must declare their actual output in blinkhost.yaml.

Preview guarantee

There is no unconditional preview guarantee based on a framework name alone. Browser preview additionally depends on WebContainer-compatible dependencies, browser APIs, available device memory and a usable development script. If those browser requirements fail but the source contract is otherwise valid, a managed repository preview can build the exact commit in BlinkHost's isolated build environment. A successful managed preview is the closest pre-production validation because production uses the same declared frontend directory, build script and output path.

Conventional backend directories

Rust, Go and Python source under backend/, server/, services/, api/, functions/ or _server_islands/ is shown as a candidate. Nothing is compiled or exposed merely because a directory has one of those names. The developer must register each intended module and confirm its entry point. The module must implement BlinkHost's request/response SDK and WASI ABI.

Conventional Django, Flask, FastAPI, Express and long-running Go servers are not silently rewritten. Keep reusable business logic in ordinary library code and add a thin BlinkHost adapter for compatible request handlers, or continue to operate the conventional service externally when it requires a persistent process, unrestricted filesystem, unsupported native dependencies or unrestricted networking.

Repository layout never grants runtime capability. Managed builds enforce source-size and file-count ceilings, secret scanning, deterministic dependencies, time and memory limits, verified artifacts and signed release identity. Production bandwidth, storage, requests, database work, build concurrency, preview capacity and runtime compute continue to use the workspace's normal meters and limits.

Existing full-stack repositories: the end-to-end path

A conventional repository can keep frontend and backend code in separate directories. For example:

frontend/
  package.json
  package-lock.json
  src/
backend/
  api/
    pyproject.toml
    app/
shared/

Choose . as Application root and frontend as Frontend directory. For a nested application such as apps/store/frontend plus apps/store/backend, choose apps/store and frontend. BlinkHost preserves the selected tree rather than moving files into a template layout. A lockfile may sit in the frontend directory or a declared ancestor workspace root. Import review shows the exact frontend candidate, package manager, output directory, backend candidates and compatibility blockers before files are replaced.

The selected frontend can preview in the browser when its dependency graph and development command are compatible with WebContainer. Direct static HTML needs only an index.html; package-based Vite, Create React App, Astro, Vue, Svelte and Solid projects use their confirmed package scripts. A managed repository preview builds the exact commit using the same declared source and output path used for production.

Adapting an existing backend without rewriting business logic

BlinkHost backend modules are request handlers, not long-running servers. An existing Rust, Go or Python service therefore needs a thin entry-point adapter that reads the BlinkHost request, calls portable application code, and returns a BlinkHost response. Keep domain rules, validation and data transformations in ordinary library modules; change only the transport, process-lifecycle and capability edges. Register each intended backend directory explicitly after import and select its entry point. LiveStack Preview becomes available after that source compiles into a verified module.

Framework detection is guidance, not authorization. Finding Django, Flask, FastAPI, Axum, Actix, Rocket, Gin, Fiber, Echo or net/http source does not start the framework server and does not expose a route. Node.js, .NET, Java, PHP and Ruby long-running server directories are reported as unsupported runtime targets; they may remain external while the BlinkHost frontend calls them, or their portable request logic can be moved behind a supported Rust, Go or Python module.

The following behavior usually requires more than a thin adapter and should remain on an external service until redesigned: background daemons, listening sockets, unrestricted filesystem access, native extensions outside the managed toolchain, runtime package installation and arbitrary network access. Frontend environment variables are never a safe replacement for backend secrets.

Dependency compatibility is decided by the pinned offline compiler for the selected language, not by whether a package exists in a public registry. Rust and Go builds require their committed dependency metadata and the dependencies available to the managed toolchain. Python Preview accepts the pinned standard-library environment and explicitly approved pure-Python packages; native extensions, subprocess dependencies and build-time downloads are rejected. The build result identifies the first incompatible dependency. BlinkHost does not publish an exhaustive package guarantee because package versions and transitive native requirements change; add dependencies one at a time and require a successful managed preview for the exact lockfile before production.

What import never bypasses

Import does not activate a resource or choose a paid entitlement. Repository size and file limits apply before import. Backend registration, language and SDK checks, offline deterministic dependency policy, secret scanning, compiler time and memory limits, artifact validation and release signing apply before execution. Preview and production then enforce the same workspace storage, build concurrency, database, request, network, bandwidth and compute allowances shown in Billing.

The practical portability boundary is source code: keep framework-independent business logic and an external build path where portability is critical. BlinkHost does not currently distribute a generic runtime package that runs a production BlinkHost module unchanged on another provider, and it does not accept a customer-built module binary as production evidence.

Automation boundary

GitHub App events can trigger the documented repository preview and deployment workflow. BlinkHost does not currently label a general customer API-key surface for complete export, migration or deployment automation as generally available. Do not automate by copying dashboard cookies. Use the supported Git connection and customer exports, and obtain a written automation contract before making an unpublished endpoint a production dependency.