Your whole Docker infrastructure, driven from one screen.
Applications, databases, private networking, domains, SSL, backups and mail server. DockBoard deploys from Git or a Docker image, on one VPS or across your fleet, with no config file to write.
Install DockBoard on your own VPS in one command
One VPS, or an entire fleet.
Everything on this VPS
The simplest setup: the API creates the project network and attaches your apps to it. The Servers page stays hidden.
- No agent to install
- Docker network handled by the API
- Switch to Multi at any time
Regions, isolation, load
One SSH one-liner: the agent installs itself, the server turns ONLINE, and you pick its target for each project.
- A project lives on one server
- Network and compose override written by the agent
- Move a project between VPS
From repo to domain, in four steps.
Every deployment follows the same path, whether the target is this VPS or a remote server driven by the agent.
- 01
Source
Git repo and branch, or a pre-built Docker image. Framework detected.
- 02
Build
Build context resolved, monorepos included. Image built and tagged.
- 03
Network
Container attached to the project network, env vars and databases injected.
- 04
Exposure
Caddy regenerated, domain attached, certificate issued and renewed.
Your services talk by name.
Every project owns a Docker network. Apps resolve through internal DNS: one public domain, everything else stays private.
Attach a domain to the frontend only. api and db stay internal, with no public port and no firewall rule.
The right records, and their real state.
Keep your nameservers. DockBoard reconciles what is expected with what is published, and issues the certificate as soon as DNS points correctly.
| HOST | TYPE | VALUE | STATE |
|---|---|---|---|
| @ | A | 51.83.42.17 | OK |
| api | CNAME | athexis.xyz | OK |
| A | 51.83.42.17 | OK | |
| @ | MX 10 | mail.athexis.xyz | PENDING |
| @ | TXT | v=spf1 mx ~all | OK |
Up to 24h of propagation is normal. The Verify button re-runs the check on demand.
What the platform handles for you.
Git or image, one port
Framework, branch, listening port. Start, stop, redeploy, delete: the stack follows.
Provisioned, never exposed
PostgreSQL, MySQL, MongoDB, Redis, ClickHouse. Generated credentials, connection string ready.
What must survive, survives
Named volumes re-attached on every redeploy and picked up by the backup system.
One server per domain
Postfix and Dovecot in containers. MX, SPF, DKIM, DMARC, PTR: the page tells you what's missing.
Live logs and state
Build and runtime output per app, container state and deployment history.
Per-project access
Members and roles at project level: network and permissions follow the project.
Build context, inferred correctly.
A pnpm, turbo, yarn or lerna workspace with a Dockerfile in a subfolder builds from the repository root. Root lockfile and sibling packages are in the context.
COPY pnpm-lock.yaml pnpm-workspace.yaml ./
COPY packages/portal-kit/package.json ./packages/
# resolved by DockBoard:
docker build -f apps/licensing-api/Dockerfile .A sub-app containing a prisma/schema.prisma gets its database provisioned at deploy time, and a fresh DATABASE_URL overrides the pre-filled localhost.
Move a project from VPS to VPS.
One button on the server card. Source volumes stay intact on the old server, in every case.
- 01Apps and databases torn down on the source, volumes kept.
- 02The project's server switches to the target.
- 03Asynchronous transfer of Docker volumes.
- 04Redeployment once the data has landed.
- 05Caddy regenerated: domains follow.
- uploads
- /app/uploads
- pgdata
- /var/lib/postgresql
Named volumes only: any host path is rejected for safety.
- Automatic discovery of platform volumes
- Daily or hourly schedule depending on plan
- Restore onto a different server
- Optional S3-compatible offsite retention
Four roles, explicit permissions.
| ROLE | DEPLOY | MEMBERS | MIGRATE | DELETE |
|---|---|---|---|---|
| OWNER | allowed | allowed | allowed | allowed |
| ADMIN | allowed | allowed | allowed | not allowed |
| DEVELOPER | allowed | not allowed | not allowed | not allowed |
| VIEWER | not allowed | not allowed | not allowed | not allowed |
Free to start, per server after that.
Billing follows your servers, not your deployments. Change plan or stop whenever you want, no commitment.
Questions that come up.
SSL is stuck on PENDING.
DNS not propagated yet, an A record pointing at the wrong IP, or ports 80/443 closed on the VPS. Re-run Verify in the Records tab.
The app is RUNNING but the URL doesn't answer.
Domain not attached, reverse proxy out of sync (Sync button), or a container port different from what Caddy expects.
Can two projects talk internally?
No: the network is scoped to the project. Use the public HTTPS URL, or group the services in a single project.
Can I split one project across several VPS?
Not today: a project lives on one Docker host. Split it into two projects and expose services over HTTPS through Caddy.
What happens to an app if I switch back to Local?
It keeps running on the remote server, simply hidden from the dashboard until you switch back.
Do I need my own compose file?
No, but if your app ships one it wins: the platform injects nothing into it and respects your volumes.
Your VPS is ready. The rest is one command.
Create a project, add an app, attach a domain. DockBoard handles the network, databases, SSL and backups.