OPERATING

Linux instances

Full Linux environments alongside your containers, for the workloads that are not a container.

Some workloads are not an application. A build machine, a legacy service nobody will containerise, a box someone just needs ssh into. A Linux instance is a full Ubuntu or Debian environment with root, running next to your containers and managed from the same dashboard.

Creating one

Pick an image, a size and a project. Available images:

TEXT

Ubuntu 24.04
Ubuntu 22.04
Debian 12
Debian 11

Creation returns an SSH command and a root password, shown once. The instance also gets a keypair, and you can authorise additional public keys afterwards:

TEXT

ssh root@your-server.example.com -p 2201

SSH lands on a dedicated host port, not on 22 — port 22 belongs to the server itself. Ports for instances are allocated from the same authority that assigns them to applications, so two instances can never collide, and neither can an instance and an application.

You can publish further guest ports on the host afterwards, from the instance’s page — useful when whatever you installed listens on something you want reachable.

Where instances may run

On a server running the agent — not, by default, on the machine hosting DockBoard itself.

This is the load-bearing rule of the whole feature. Everything else in DockBoard stops a tenant from executing arbitrary code on a platform host; an instance deliberately hands them a root shell on a kernel shared with that host. The platform host runs the API with access to the Docker socket, so an escape there would surrender the entire control plane — licenses, database, every other tenant.

An administrator can allow it anyway, with an explicit setting. It is deliberately an opt-in rather than an inferred condition: nothing at install time distinguishes a solo operator’s own machine — where this is perfectly reasonable — from a multi-tenant platform, and the product must not guess.

Isolation tiers

Standard: A container with root inside it. Right when the person holding that root is you or your own team.
Hardened: The same, with capabilities dropped and additional security options applied. Right when you hand the box to someone you do not fully trust.

Which tiers you can create depends on your license — the list of images and tiers the dashboard offers is the list your license actually grants, not a menu with locked entries.

Day-to-day

Start, stop and restart, like an application.
Read the container logs — the sshd output, which is where a refused key shows up.
Live CPU and RAM for that box, and its history in monitoring.
Change the RAM and CPU ceiling without recreating it.
Rotate the root password and re-seed the authorised keys in the live box.

The instance’s /root, /home and /data live in volumes and are captured by backups under their own switch — separate from application volumes, because an instance is a whole machine and can be an order of magnitude larger.

Who can do what

Instances carry five permissions, and one of them is unusual:

Permission	Grants
`instances:view`	See the instance and its metrics.
`instances:create`	Create new ones.
`instances:manage`	Start, stop, resize, publish ports — and read the root password.
`instances:ssh`	Open a root shell on the box.
`instances:delete`	Delete it and purge its volumes.

ssh is deliberately not folded into manage. Opening a root shell is a strictly bigger power than resizing a box or publishing a port, and a custom role must be able to grant one without the other — an operator who can restart and resize, without a shell on the machine.

Deleting an instance purges its volumes. There is no separate “keep the data” option here as there is for an application: an instance’s data is the instance.

Instances count against your project and user quotas — their own count ceiling, plus the RAM and CPU they reserve on the server.