Instances

An instance is one managed engine — a database, cache, or broker — running in its own unprivileged container on your workspace's private network. Everything on this page is in the dashboard under Resources.

Engines you can launch

Eight engines are live today:

The catalog lists the rest of the platform's engines — ClickHouse, SeaweedFS, Gitea, n8n, k0s and more — greyed out and marked Coming soon. An engine becomes selectable when its provisioning script ships, not before.

Sizes and quota

Sizing is separate from billing. Your account's plan grants a quota — a shared pool of vCPU, memory, and disk — and each instance carves a size out of it:

Each size carries a network rate cap so one busy instance can't take the uplink out from under its neighbours.

Create as many instances as fit in the quota; the create form blocks you when the next one wouldn't. A running instance can be resized to another size from its Settings tab — the new CPU and memory are applied live, no restart — and the same quota rules apply to the new footprint.

Create one

Resources → New, then pick an engine, a name, and a size. For SQL engines you can also set the database name, user, and password up front; leave the password blank and one is generated for you.

Names are per-workspace and become part of the public hostname, so pick something you'll recognise in a connection string.

Watch it build

Provisioning runs as an ordered sequence of steps, and the instance page streams them as they land:

1. Allocating — an ID, a private IP, a node, and a public port are reserved.
2. Network — the workspace's private network is brought up. Usually the longest wait on your first instance, and instant on every one after it.
3. Container — an unprivileged container is cloned from the golden template and started.
4. MTU — the container's MTU is corrected for the VXLAN overlay.
5. Engine — the engine is installed and configured. The long step for most engines.
6. DNS — the public record is published; skipped when the instance is private.
7. Ready — the instance is running and its connection details are filled in.

Typical end-to-end time is about 75 seconds. Steps that haven't started yet render as pending, a step blocked on something the platform expects to resolve itself shows as waiting rather than failed, and a real failure names the exact step it stopped on with an error code — you never get a spinner with no explanation.

Start, stop, restart, delete

The instance page and the list view both carry lifecycle controls, and the list lets you act on several instances at once. Each action records intent and the platform reconciles to it, so the status moves through a transitional state (starting, stopping, restarting) and settles on its own — no need to refresh.

Deleting removes the container, releases its addresses, and withdraws the public DNS record. It is not reversible — and it's also the one thing a backup can't help with after the fact, since a restore reads the source instance. Back up first, then delete.

A provision that fails on an infrastructure step can be retried from the instance page — the platform picks it up again over the resources it already allocated, rather than making you delete and recreate.

Metrics

The Metrics tab charts CPU, memory, disk, and network for the window you pick. The figures are read off the hypervisor, so there's no agent to install inside the instance and nothing to configure.

Working with the data

PostgreSQL and MySQL instances carry three more tabs — a table editor, a SQL editor, and database users — that run against the instance from the dashboard, without a client or a public endpoint. See Database tools.

Next steps

• Connect to an instance — host, port, credentials, and per-engine examples
• Database tools — browse tables, run SQL, add database users
• Backups — dump a database on demand and restore it into a fresh instance
• Workspaces & roles — decide who on your team can create or restart what