DEPLOYING

Applications

Deploy from Git, a Dockerfile, a Compose file or a prebuilt image, and configure what runs.

An application is one deployable unit: a web service, an API, a worker. It belongs to a project, runs as a container, and DockBoard rebuilds and restarts it whenever you deploy.

Creating an application

From Applications → New application, three choices define what gets built:

Framework: Next.js, NestJS, Docker, Docker Compose and others. This selects the build strategy — pick Docker when your repository already carries a Dockerfile.
Source: A Git repository URL and a branch, or a prebuilt Docker image from a registry.
Port: The port your application listens on inside the container. This is not the public port — routing to it is handled by domains.

What DockBoard gives every application

A predictable container name — dockboard-<slug>.
A predictable internal hostname, identical to the container name.
Membership of the project’s shared Docker network.

Because of the third point, other applications in the same project reach this one at http://dockboard-<slug>:<port> — with no public URL and nothing exposed to the internet. That is the whole basis of service networking.

Lifecycle

Action	What it does
Start / Stop / Restart	Acts on the container as it stands. No rebuild, so the running image does not change.
Redeploy	Re-pulls the Git branch and rebuilds. This is what picks up new commits.
Delete	Tears down the stack and removes the container. Volumes follow the rules in storage.

Every one of these is recorded in the audit trail, and every redeploy appears in the deployment history where you can read its build log or roll it back.

Monorepos and committed Dockerfiles

When your repository is a monorepo (a pnpm, turbo, yarn or lerna workspace) and an application lives in a sub-folder such as apps/api, its committed Dockerfile usually needs files from the repository root:

DOCKERFILE

COPY pnpm-lock.yaml pnpm-workspace.yaml ./
COPY packages/ui/package.json ./packages/ui/

Those COPY instructions fail if the Docker build context is the sub-folder, because pnpm-lock.yaml and packages/* sit above it. That is why such a Dockerfile is normally built with docker build -f apps/api/Dockerfile … . — context is the repository root, not the application’s folder.

Automatic, with no configuration

If DockBoard detects a workspace — a pnpm-workspace.yaml, turbo.json, lerna.json, or a package.json declaring workspaces — and a committed Dockerfile in the sub-folder, it builds from the repository root with -f <sub-folder>/Dockerfile. The root lockfile and sibling packages are then inside the context, so a monorepo deploys with nothing to configure.

Taking explicit control

The Dockerfile & build context card on the application page exposes two optional fields when the detection is not what you want:

Field	What it does	Left empty
Dockerfile path	Which Dockerfile to build, relative to the repository — `apps/api/Dockerfile`, or `apps/api/Dockerfile.prod`.	`<sub-folder>/Dockerfile`
Build context	The directory used as the `docker build` context — empty or `/` for the repository root, or a path such as `apps/api`.	Repository root for a workspace, otherwise the sub-folder

Setting build context to *(empty)* and Dockerfile path to apps/api/Dockerfile is exactly docker build -f apps/api/Dockerfile -t <app> . run at the clone root. The equivalence holds for local deployments and for remote servers alike — the agent synthesises a matching docker compose with build: { context, dockerfile }.

Saving either field triggers a redeploy. Both are validated against path traversal — .. and absolute paths are refused — so they must resolve inside the cloned repository.

A sub-folder application also reads its .env files from two places: the repository root and its own folder, the folder winning. See monorepos and environment variables.

Importing a monorepo

When you import a monorepo, DockBoard inspects each sub-application. If one builds from a committed Dockerfile and carries a prisma/schema.prisma, the import wizard pre-checks Provision database for it, reading the provider from the schema.

On deploy, DockBoard provisions the database and injects a fresh DATABASE_URL that overrides any seeded localhost value. A sub-application that needs a database boots against the real provisioned one instead of crashing against localhost. Uncheck it when the sub-application manages its own database.