---
title: Multi-Ecosystem
description: Compose one Better Fullstack project from frontend, backend, database, and mobile parts across ecosystems.
translationStatus: pending
updated: 2026-08-22
---

Multi-Ecosystem mode models a project as connected stack parts instead of one flat ecosystem selection. Use it when a product spans languages: a TypeScript frontend, a Go API, a shared PostgreSQL database, and a React Native app in one workspace. Open it in the [Stack Builder](https://better-fullstack.dev/new?mode=multi) or pass repeated `--part` flags.

## Stack parts

Each part has the shape `role:ecosystem:tool`, or `owner.role:ecosystem:tool` when the role attaches to a parent part:

| Example                              | Meaning                                            |
| ------------------------------------ | -------------------------------------------------- |
| `frontend:typescript:next`           | Generate a TypeScript Next.js frontend.            |
| `backend:go:gin`                     | Generate a Go Gin backend.                         |
| `backend.orm:go:gorm`                | Attach GORM to that backend.                       |
| `backend.api:rust:tonic`             | Attach Tonic gRPC to a Rust backend.               |
| `database:universal:postgres`        | Add a shared PostgreSQL database part.             |
| `mobile:kotlin:jetpack-compose`      | Generate a Kotlin Jetpack Compose app.             |
| `mobile:swift:swiftui`               | Generate a SwiftUI app.                            |
| `frontend:dotnet:blazor-webassembly` | Generate a standalone Blazor WebAssembly frontend. |

Top-level roles describe generated apps or shared infrastructure. Owned roles attach capabilities such as ORM, API, auth, or libraries to their owner.

## Scripted example

```npm
npm create better-fullstack@latest my-mixed-app -- \
  --part frontend:typescript:next \
  --part backend:go:gin \
  --part backend.orm:go:gorm \
  --part backend.auth:go:jwt \
  --part database:universal:postgres \
  --part mobile:kotlin:compose-multiplatform \
  --part mobile.libraries:kotlin:ktor-client \
  --part workspaceRunner:universal:turborepo \
  --part containerOrchestration:universal:docker-compose
```

## Source of truth

Multi-ecosystem projects write `stackParts` to `bts.jsonc`, and those parts drive generated structure, history, and reproducible commands. Legacy flat fields may still appear as compatibility views derived from the graph. The generated command preserves the graph as repeated `--part` flags, so nothing depends on hidden builder state.

The builder's Multi-Ecosystem flow walks through frontend, backend, database, mobile/apps, then finalize (tooling, AI docs, install, Git, version settings).

## Compatibility

- Owned capability parts must reference an owner, and their ecosystem generally must match it.
- Primary services can take an explicit stable ID as a fourth segment, such as `backend:go:gin:api`; capabilities then target that ID with `api.orm:go:gorm`.
- Repeatable named backends render under `services/<id>` when their adapters support independent output; the checker rejects repeated projections it cannot render safely.
- Universal database parts can be shared across ecosystems.
- Some tools imply parts, for example a backend that assumes routing, and those appear in generated `stackParts`.
- The compatibility validator runs before generation and reports owner, duplicate, and unsupported-tool issues.

## Multiple named services

```npm
npm create better-fullstack@latest services-app -- \
  --part frontend:typescript:next \
  --part backend:go:gin:api \
  --part backend:go:echo:admin \
  --part api.orm:go:gorm \
  --part admin.orm:go:sqlc \
  --part database:universal:postgres
```

Stable IDs make ownership unambiguous and keep generated service paths reproducible.