Instances

An instance is one managed engine — a database, cache, broker, or container registry — running in its own unprivileged container on your workspace's private network. Everything on this page is in the dashboard under Managed services; virtual machines and game servers are instances too, with sidebar entries of their own.

Engines you can launch

Nine engines are live today:

The catalog lists only the engines you can launch today. A new engine appears in it when it ships, not before.

Sizes and quota

Sizing is separate from billing. Each workspace has a quota — a pool of vCPU, memory, and disk set by the workspace owner's plan — 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. Each instance gets the disk its size lists. A running instance can be resized to another size from its Settings tab — a container takes the new CPU and memory live, with no restart, while a virtual machine restarts to apply them and the dashboard asks before it does — and the same quota rules apply to the new footprint.

Resizing a database, cache or broker also grows its disk to the new size's, and the dashboard asks you to confirm first. A disk never shrinks, so a size with less disk than the current one can't be picked. PostgreSQL, MySQL and MariaDB size their memory settings, such as their buffers, to the size: after a resize they switch to the new size's settings at their next restart, so restart the instance when it suits you.

Create one

Managed services → New service, 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. The hostname is set when the instance is first published, and renaming the instance later keeps it.

Hostnames

Every public resource gets a hostname of its own, and the part after its name says what kind of resource it is:

Load balancers use your workspace's shared IP, where each listener answers on a public port of its own, so clients connect to the hostname with that port, for example web-k3x9mq.lb.sahabti.app:40006. Dedicated IP addresses are not offered yet. See Load balancers.

Always connect with the hostname the console shows.

Outbound traffic

Instances, virtual machines and apps can reach the internet. Outbound port 25 is blocked to keep spam off the platform's addresses: send mail through your mail provider on port 587 instead. If your workspace has to deliver mail on port 25 itself, contact support.

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 workspace's private network.
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. Restore what you need to a new instance 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, MySQL and MariaDB instances carry more tabs — a table editor, a SQL editor and database users, plus import and export — that run against the instance from the dashboard, without a client or a public endpoint. See Database tools and Backups.

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