Application framework and language support

Backify is TypeScript-first, not TypeScript-only. Prefer TypeScript for new generated applications. Preserve existing JavaScript applications and customer frameworks rather than rewriting them to match the default.

  • React with Vite for new browser frontends, following the expense-manager reference application in the repository.
  • An explicit Node.js/TypeScript Backify backend when server capabilities are needed, using @backifydev/sdk/app and a backify.config.ts server entry.
  • Web apps with frontend/backend, API-only apps, or worker-only apps, generated with backify new and described by a committed lockfile.

This is a development baseline, not certification of every capability or hosting target. The CLI supervises Vite and explicit static frontends; other frameworks use native development servers. Follow local development, inspect installed SDK types and verify the application's actual behavior.

Compatible JavaScript/TypeScript frameworks

Assess existing Next.js, Astro, SvelteKit, Nuxt, Express and other frameworks individually. Being Node-based does not establish supported SSR, middleware, serverless behavior, identity propagation or capability integration. Preserve the framework and explain gaps rather than inventing adapters. Dependency detection is advisory, not deployment admission or a security check.

Image builds require the layout and process-role runtime contract in application build verification. Framework selection never bypasses build checks, preview acceptance, authorization or production approval.

Advanced custom containers

Preserve repository-root Dockerfiles and the custom-container hosting path, including Python, .NET and Go applications. Hosting does not promise a Backify SDK for those languages. Use only explicitly supported capability integrations. Explain missing capabilities and ask before adding an external platform service as a workaround.

Additional first-class languages or adapters require demonstrated customer demand, supported SDK and identity integration, local tooling, deployment verification and authorization/capability conformance tests where applicable. A container that starts is insufficient evidence of first-class support.

CLI diagnostics

Doctor and local reports include an advisory support assessment: tier, detected framework and guidance. Tiers are recommended for React/Vite, compatible for other package-based applications, advanced for custom containers and unassessed when no package or Dockerfile exists. Warnings do not reject an existing stack. Recommended does not establish verified SDK integration, security or deployment.