Skip to content

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:

FileDetected as
turbo.jsonTurborepo
pnpm-workspace.yaml or pnpm-workspace.ymlpnpm workspaces
nx.jsonNx
lerna.jsonLerna

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 all to set up every detected folder.
  • Enter a path, such as services/auth, for an app outside apps/ and packages/.

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 init prompt in a Turborepo, Nx, Lerna or pnpm repository, Elula sets root for you.
  • Multi-service repos keep subdir, because their folders are independent.
  • --root-dir skips detection, so it also skips this. Pass --docker-context root yourself.
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.

Warning: If the Dockerfile needs shared workspace packages and the context is 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.

Note: By default, a change only in a shared package (for example packages/ui) doesn't redeploy the apps that use it. Run elula deploy in each app's folder.