GETTING STARTED

What DockBoard is

The vocabulary the rest of these docs assumes: servers, projects, environments, applications and instances.

DockBoard runs on your server. You install it once, point it at the machines you already pay for, and it takes over the part nobody enjoys: building images, wiring a reverse proxy, issuing certificates, rotating backups, keeping a fleet in sync.

Nothing runs on our infrastructure. There is no DockBoard-hosted control plane between you and your containers — the panel *is* the control plane, and it lives on a machine you own.

The five words everything else is built from

The rest of this documentation uses these terms precisely. They are worth two minutes now.

Server: A machine DockBoard can deploy onto. The one running the panel counts as a server; others are added by running one install command on them, which puts an agent in place.
Project: The unit of grouping, of access control and of billing-shaped limits. Applications inside a project share a private network and can reach each other by name; nothing crosses a project boundary by accident.
Environment: A slice of a project — production, staging. Same applications, different variables, different domains. Optional: a small project can live with one.
Application: One deployable thing: a Git repository, a Dockerfile, a Compose file or a prebuilt image. This is what has a URL, logs, environment variables and a deployment history. See applications.
Instance: A full Linux box with root on it, for the workload that is genuinely not a container. Different object, different page: instances.

An application belongs to exactly one project and runs on exactly one server (or one cluster). A project can span several servers — that is the normal shape once you outgrow one machine.

What DockBoard actually does for you

Builds and runs. Git push to running container, with the build log streamed live and a rollback to any previous version.
Fronts everything. A reverse proxy is generated on every change, and certificates are issued and renewed without you touching them. See domains and SSL.
Holds the data. Managed databases, persistent volumes, and backups that are verified rather than merely written.
Watches. Metrics, logs, alert rules and a notification when a machine stops reporting.
Lets other people in, carefully. Two permission catalogs, custom roles, teams, SSO and an audit trail of every state-changing action.
Answers to a script. Everything above has an API, and an API key that can be scoped down to exactly one job.

Where to go from here

Nothing installed yet: Installation — one command on a fresh VPS, then a first account that becomes the administrator.
Installed, deciding the shape: Local and multi-server modes — whether the panel runs your containers itself or drives other machines.
Ready to ship something: Projects, then applications. Fifteen minutes to a URL with a certificate on it.
Automating: Deploy from CI — the twenty lines that make a push to main redeploy, and fail the pipeline when the deploy fails.