Key idea
A monorepo keeps several apps in one repository, each in its own folder, and each folder becomes its own service. Today every build starts from the repository root, so you point the build at your folder with the commands you give it.
This lesson is optional. Skip it if each of your apps has its own repository.
The repository behind these labs is a monorepo:
learn/
└── labs/
├── hello-web/ (a web page, port 8080)
└── sample-api/ (a small API, port 8080)
Building from a subfolder today
With a runtime build (Managed), start both commands in your folder. For hello-web, a Go service:
- Runtime: Go 1.23 or newer
- Build command:
cd labs/hello-web && go build -o /app/app . - Start command:
./app
The build command moves into the folder, compiles, and writes the program to /app, the folder the start command runs from. A Node.js app in apps/web would build with cd apps/web && npm install && npm run build and start with cd apps/web && npm start.
With a Dockerfile, keep it at the repository root and copy in only the folder you need:
FROM golang:1.23-alpine AS build
WORKDIR /src
COPY labs/hello-web/ .
RUN go build -o /out/app .
FROM alpine:3.21
COPY --from=build /out/app /app
EXPOSE 8080
CMD ["/app"]
Copying one folder keeps the image small, and a change elsewhere in the repository can't affect it.
The two settings on the way
- Root directory says which folder holds a service's code, such as
labs/hello-web. Once builds honour it, thecdgoes away and your commands look like a single-app repository's. - Watch paths say which changed files should start a new build, such as
labs/hello-web/**. They're patterns like the ones in a.gitignorefile. With none set, any change counts.
When automatic builds arrive, a push that only touches labs/sample-api/ would rebuild sample-api and leave hello-web alone.
Shared code between services
If services share a folder, say libs/, include it in each service's watch paths: labs/hello-web/** and libs/**. Otherwise a fix to the shared code wouldn't rebuild the services that use it.
Build settings live in a service's Redeploy dialog: choose Build & deploy, then Edit build settings.
Check yourself