DEPLOYING

Projects and environments

Group related applications, isolate production from staging, and give a whole project its own private network.

A project is a group of applications and databases that belong together. It is the unit DockBoard uses for placement, for networking and for access control — almost everything you configure hangs off one.

Its members live on one server — in multi-server mode you pick which.
They share a private Docker network, so they reach each other by name with nothing exposed publicly.
They share access control — who is a member, and what each member may do.

Creating a project

01Go to Projects → New project.
02Give it a name. The slug derived from it appears in container names and internal hostnames, so keep it short.
03In multi-server mode, pick the target server. It can be changed later — see moving a project.

Members and roles

Every member of a project holds one role on it. These are the built-in roles; you can also define your own — see roles and permissions.

Role	What it allows
`OWNER`	Everything, including transferring ownership and deleting the project.
`ADMIN`	Add and remove members, deploy, and move the project to another server.
`DEVELOPER`	Deploy and edit applications. No control over membership.
`VIEWER`	Read-only.

Project roles are separate from platform-level rights. Being an administrator of the DockBoard instance does not silently make you a member of every project — see roles and permissions for how the two catalogs relate.

Environments

A project can be divided into environments — typically staging and production, though the names and the colours are yours. An application, a database or a Linux instance is assigned to at most one of them, and the assignment is what lets the same project hold two copies of the same service without their settings colliding.

The one place this changes behaviour rather than merely labelling things is variable sets: a set scoped to an environment beats the project-wide set key by key, so DATABASE_URL can mean one thing in staging and another in production under the same name.

Promote copies one environment onto another, matching applications by name. An application the destination already has is updated in place; one it does not have is created there as a copy. Two independent switches decide how much travels:

Copy variables: The source application’s own variables overwrite the destination’s. Untick it when production holds credentials that staging must never carry over.
Update build settings: The Git branch travels, and so does *what gets built from it* — the sub-folder, the Dockerfile path and the build context. These move together on purpose: a destination left pointed at an older sub-folder would build different code from the same commit, which is the exact failure a promotion exists to rule out.

Promoting writes branches and variables into the destination, so it demands the same rights as editing those applications directly — not merely the right to deploy. A member whose apps:env permission is denied cannot reach production secrets by promoting into them.

A promotion reports what it changed, what it created, and anything it could not carry across — a Swarm placement, for instance, is deliberately not copied onto a new application. Read those warnings: a promotion that reports success is not the same as one that carried everything.

An environment is deleted only once it is empty. If applications, databases or instances are still assigned to it, the panel refuses and names how many of each — reassign or delete them first. This is the difference between an environment you removed and a set of resources nothing points at any more.

Environments are for copies you keep. For a copy that exists only while a pull request is open and disappears when it merges, use preview environments instead.

The project network

Each project owns a Docker network named dockboard_proj_<projectId>. Every application and database placed in the project joins it automatically, and resolves the others by container name through Docker’s internal DNS.

This is what makes a multi-service application work without publishing a single port. The details, with a worked example, are in service networking.

Moving, exporting and deleting

Move a project to another server, volumes included — moving and exporting projects.
Export it to a file and import it on another DockBoard instance — same page.
Delete it, which tears down its applications and databases. Take a backup first if any of it matters.