Import an existing full-stack repository

Supported repository shapes

BlinkHost can import a supported frontend at the repository root or in a nested directory. This includes common layouts such as frontend/ with backend/, apps/web/ with services/api/, and a monorepo containing several package manifests.

During import, Application root defines the source boundary that belongs to the BlinkHost project. Frontend directory identifies the frontend working directory inside that boundary. When frontend and backend folders are siblings, keep the application root at . and select the frontend directory. BlinkHost shows detected frontend candidates; you confirm the intended one when more than one is present.

Supported frontend families are Astro, static HTML, React, Solid, Svelte and Vue. Managed repository builds support npm, pnpm, Yarn and Bun with a committed lockfile. Browser preview uses the confirmed frontend directory and package scripts. A repository that depends on native binaries, unsupported browser APIs or a package manager unavailable in the browser can still use the managed repository preview after a successful build.

Register backend services

BlinkHost looks for Rust, Go and Python module markers under conventional backend, server, services, api and functions directories, as well as _server_islands. Detection is only a proposal; it does not prove that an ordinary server application is compatible. Review each path, runtime language, module name and entry point before selecting Register module.

Registration preserves the source folder and adds the managed blinkhost.toml contract. The public route remains /_server_islands/<module-name>/ regardless of the source directory. BlinkHost compiles the source in its pinned managed toolchain, checks the resulting artifact and deploys only a verified artifact. A .wasm file committed by a customer is never accepted as a substitute for that build.

Compatible code must use the BlinkHost backend-module SDK and request/response ABI. A conventional Django, Flask, FastAPI, Express, Go HTTP server or other long-running process is not silently converted into a module. Extract compatible handlers behind a small adapter, or continue to run that service outside BlinkHost when it needs unrestricted processes, packages, filesystems or network access. Registration and a successful managed build are the compatibility test; folder naming alone is not.

Configuration contract

For repeatable imports, commit blinkhost.yaml at the application root. Its frontend section can declare a nested root:

schema: blinkhost/v1
application:
  root: .
frontend:
  root: frontend
  framework: react
  package_manager: npm
  install: npm ci
  build: npm run build
  dev: npm run dev
  output: dist
modules:
  - name: api
    path: backend/api
    language: python
    entrypoint: app/main.py

Paths must be normalized, repository-relative paths. Frontend commands are limited to the selected package manager and named package scripts. Backend registration does not grant filesystem, network, database or secret access; those capabilities remain controlled by the module runtime, environment bindings and workspace plan.

Before production

Run a managed preview from the exact commit, register and build every required backend module, connect only the intended environment resources, and verify the output directory. Production capacity, concurrent builds, previews, storage, bandwidth, database use and runtime work continue to count against the workspace's normal plan limits. Importing a different layout does not create a second quota or bypass billing.

Interactive browser preview also requires a confirmed dev package script and dependencies that can run in WebContainer. When browser execution is incompatible, use the managed repository preview to validate the built frontend. A supported framework name alone is not a build guarantee: the committed lockfile, selected scripts, output directory and dependencies must pass the same checks as the production commit.