Deploying
Monorepos
Deploy one or more apps from a repository that holds several projects.
In Elula, each deployable folder in a monorepo is its own app, with its own URL, environment variables, scaling and deployments. They share one Git repository.
Automatic detection
Run elula init from the repository root. Elula looks for these files at the root:
| File | Detected as |
|---|---|
turbo.json | Turborepo |
pnpm-workspace.yaml or pnpm-workspace.yml | pnpm workspaces |
nx.json | Nx |
lerna.json | Lerna |
If one is found, every folder under apps/ and packages/ is offered as an app.
If none is found, Elula scans the top-level folders for build files (Dockerfile, package.json, requirements.txt, pyproject.toml, go.mod, pom.xml, Gemfile, composer.json or index.html). If two or more folders have one, the repository is treated as a multi-service repo. Folders such as docs, scripts, tests, infra, public, dist and build are skipped.
When a monorepo is detected, elula init asks which apps to set up:
Turborepo detected — 3 apps found.
Which apps do you want to deploy?
1 apps/api
2 apps/web
3 packages/ui
Enter numbers (e.g. 1,2), "all", or a custom path [all]:- Enter numbers, such as
1,2, to pick apps. - Enter
allto set up every detected folder. - Enter a path, such as
services/auth, for an app outsideapps/andpackages/.
Each selected folder becomes an app named <repo>-<folder>, and gets its own .elula.json inside that folder. Deploy each one from its folder:
cd apps/web && elula deploy cd ../api && elula deploy
The dashboard does the same detection when you import a repository and lets you tick several apps. Each one becomes its own service.
Pick a folder yourself
Skip detection with --root-dir:
elula init --root-dir apps/web elula init --root-dir apps/api --name my-platform-api
In the dashboard, set Root directory when creating the app.
Docker build context
By default, the build runs inside the app's folder (--docker-context subdir). The build can't see files outside that folder.
Turborepo, Nx, Lerna and pnpm workspace apps usually need shared packages from elsewhere in the repository. For those, use --docker-context root: the build runs from the repository root, using the Dockerfile in the app's folder. Paths in COPY lines are then relative to the repository root.
- When you pick apps from the
elula initprompt in a Turborepo, Nx, Lerna or pnpm repository, Elula setsrootfor you. - Multi-service repos keep
subdir, because their folders are independent. --root-dirskips detection, so it also skips this. Pass--docker-context rootyourself.
elula init --root-dir apps/api --docker-context root
Use root together with your own Dockerfile in the app's folder, for example one that uses turbo prune.
subdir, the build fails, for example with "Missing packageManager field" or unresolved workspace imports.Apps created in the dashboard use subdir. To switch an existing app to root, run elula init again from the repository root with the same root directory. Elula links the existing app and updates the setting:
elula init --root-dir apps/api --docker-context root elula deploy
elula status shows Context: root when it is set.
Auto-deploy in a monorepo
With auto-deploy on, a push to the app's branch only deploys an app if the push changed a file inside that app's root directory. Pushing a change to apps/web doesn't redeploy apps/api.
If GitHub doesn't include the list of changed files (it can leave it out for very large pushes), every app on that branch is deployed.
packages/ui) doesn't redeploy the apps that use it. Run elula deploy in each app's folder.