cubeship

Creating a database

An engine, a version, a login. Four things are fixed the moment it exists, and each for a reason.

cubeship db create pg --engine postgres
cubeship db create pg --engine postgres --version 16 --username shop --database shop
cubeship db create cache --engine redis
cubeship db engines                       # what this release can run

Or New database on the Databases screen, which offers the same fields and generates the password for you.

Provisioning runs detached from the request: the row appears as provisioning, the image is pulled, the container started, and the status follows. A database that failed to come up is failed with the reason on it, and Start retries it.

The fields

FieldDefaultNotes
name—a slug, unique on the instance; it becomes cubeship-db-<name>
engine—postgres, mysql, mariadb, redis, mongodb
versionthe newest offeredsee Engines for the list
usernamecubeshipRedis has one login, default, and refuses another; MySQL and MariaDB refuse root
passwordgenerated24 characters when left empty, so a weak one is never the default
databasethe namethe database created on first start; Redis has none

The default login is cubeship rather than the engine's own: postgres and root are the two names every scanner on the internet tries first.

Fixed after creation

  • The name. It is the container's, which every attached app resolves.
  • The engine and the version. A data directory written by one major version is not readable by another. A database that "changed version" would be a container that will not start, with the only copy of the data inside a directory it will not read. Running a new version is a second database and the engine's own migration tools — or a backup restored into it.

The password can be rotated while the database is running. Cubeship changes the engine login and then stores the new value.

You can also change the description and ceiling.

Where the data lives

A host directory under the data directory, <data dir>/datastores/<id>, mounted into the container. Anything in a container's writable layer is destroyed when its configuration changes — publishing a port is such a change — so the data is outside it, and survives.

Through an agent

create_datastore, list_datastore_engines and the rest are in the tool reference. No tool reads or sets a password, and none exposes a database: an agent can provision one and attach an app without ever holding the credential.

On this page