Guide
Engines on a dedicated server
A dedicated server downloads an engine's binaries the first time it needs them, and keeps them on disk afterwards. The Engines panel in settings shows which engines are installed on each of your servers, lets you install one ahead of time, and lets you take back the disk from an engine you no longer run there. This page covers what it does, what it never touches, and why a control is sometimes grayed out.
This is a dedicated server feature only. Databases in the shared cloud run on our fleet, where engine binaries are our problem and not yours, so there is nothing to manage and the panel does not appear.
Where it lives
Open cloud settings and find the Engines section. You get one panel per active dedicated server you own or reach through a team. Each panel is collapsed by default and its summary line answers the everyday question: how many engines are installed, and how much disk they are using. Open it for the per-engine list.
A server that is still being provisioned does not appear yet. Engines become manageable once the server is delivered and active.
Nothing is preinstalled
A new server ships with no engine binaries at all. The first time you create a database of a given engine, that engine's binaries download to the server automatically and the database starts. There is no setup step, and an engine you never use occupies zero disk forever.
That is what the two states in the list mean:
The binaries are on this server. The row names the version or versions present, the disk they hold, and how many of your databases on this server use that engine.
Nothing has been downloaded. The row names the version that would arrive, and it arrives by itself the first time you create a database of that engine here.
Sizes are the logical size of the downloaded binaries. The store they live in is compressed, so the space they actually consume on the server is typically lower than the number shown.
Installing ahead of time
Install on a not-installed engine downloads its binaries now instead of at first use. It is optional. Nothing about the create flow requires it, and skipping it costs you only the download on your first database of that engine.
It is worth doing in one case: you create databases programmatically, through the API or CLI, and you want that first create to return quickly rather than waiting on a download that can run to a gigabyte or more. Installing holds the disk from that moment until you remove the engine again.
The version installed is the same default a create would pick, so what you warm up is what you would have got anyway.
Removing an engine you no longer run
Remove deletes the downloaded binaries for one engine and gives the disk back. It never touches a database, a backup, or a byte of your data. It is only ever offered for an engine with no databases on that server, so there is nothing there for it to affect.
It is also fully reversible. Create a database of that engine on the server later and the binaries download again automatically, exactly as they did the first time. You can also click Install to bring them back deliberately.
The panel may show a note when it spots engines installed with no databases behind them, naming roughly how much you would reclaim. That is advice and nothing more. Binaries are only ever removed when you click Remove and confirm.
When Remove is unavailable
The button stays visible but grayed out, and hovering it tells you what is holding the engine in place. There are two reasons.
Databases of that engine live on the server. Any state counts: running, hibernated, stopped, or archived. A stopped database still needs its binaries the moment it starts again, so they are never pulled out from under it. Delete those databases, or move them elsewhere, and Remove opens up.
Another engine depends on it. Some engines run on top of another engine's binaries. FerretDB, which speaks the MongoDB wire protocol, runs on a PostgreSQL backend, so PostgreSQL cannot be removed while any FerretDB database exists on that server, even if you have no PostgreSQL databases of your own. The tooltip names the dependency and the count rather than claiming you have zero databases.
The server checks both rules itself when you confirm, so a removal can still be refused if a database was created in the meantime. Nothing is removed in that case, and the dialog tells you why.
Which engines you see
The list covers the engines you can create in Layerbase Cloud. A handful of engines in the wider Layerbase suite cannot be offered as a managed service under their license: MongoDB, CockroachDB, and SurrealDB. They are not creatable in cloud on any plan, dedicated included, so they are not offered here either. They remain available in the desktop app and the CLI, which run on your own machine. If you want MongoDB compatibility on a server, FerretDB is the cloud answer.
Older dedicated servers keep their engine binaries inside the database image rather than in a shared store on disk. There is nothing to add or remove on those, and the panel says so instead of listing engines.
If something goes wrong
A failed install or removal reports the reason in the dialog you are already looking at, and the confirm button becomes a retry. A removal that could not reach the server removed nothing. An install that timed out may still be finishing on the server, so use Refresh to see the current state before trying again. If a failure keeps repeating, contact support.