Sealos Database

Identity and Discovery

Owner:
```
sealos-database
```
(
```
/sealos-database
```
and database create, connect, backup, logs, or access requests).
Class:
```
cloud-local-mutation
```
through
```
sealos-cli
```
, with an optional redacted handoff to deployment.

Canaries:

DB-REUSE-ENV

DB-CONFIRM-PUBLIC

, and

DB-REDACT-CONNECT

Scope and Boundaries

Accept a project path and database intent. Analyze first, list existing databases, create or reuse the selected type, and wire only the existing application env key. Preserve prior env values and local Compose rollback; private access is the default. Database deletion, public access, backup deletion, restore collisions, and disabling active access remain gated operations.

Risk and Confirmation

Never print passwords, full connection strings, kubeconfig, auth files, or copied env values. Ask before public access or destructive operations and state the private alternative. Parse JSON CLI output and keep the selected workspace, namespace, database, and env mutation scoped to the request.

Lifecycle Workflow

For each request, resolve the project, analyze its database need, confirm CLI/auth/region/workspace, list before create/reuse, fetch connection details, wire the existing env key, and verify connectivity or migrations. Emit request-scoped

success

stopped

, or

error

; the existing analyzer-first workflow remains the domain extension below. Workspace ambiguity, an unavailable credential response, or a tracked env target stops the request before mutation.

Request Contract

yaml

input:
  project: local path or repository source
  intent: database type, purpose, and create-or-reuse preference
  access: private by default; public only after confirmation
preconditions:
  - analyzer evidence names the database signal and env key
  - sealos-cli/auth/region/workspace are resolved
  - the selected env file is ignored and the key is known

The ordered action is

analyze -> resolve account/workspace -> list -> create or reuse -> wait -> fetch -> wire -> verify

. The selected workspace, namespace, database identity, and env mutation remain request-scoped.

Progressive Disclosure

Load the analyzer, CLI, env-wiring, and connectivity procedures one level deep when their phase is reached. Keep credential-handling and public/destructive confirmation visible here even when detailed commands live in owned scripts or references.

Output, Stop, and Error States

```
success
```
: database identity/status, region/workspace, env file and key names, redacted connectivity or migration evidence, confirmation state, and any follow-up access state.
```
stopped
```
: ambiguous workspace, unavailable credential readiness, tracked env target, public/destructive confirmation boundary, or missing precondition with the safe next action; no gated mutation is claimed.
```
error
```
: analyzer, CLI, connection, or env-write step, sanitized diagnostic category, affected artifact, and recovery action with passwords, URLs, auth values, and complete connection strings redacted.

Handoffs

An optional deployment handoff uses the complete tuple below. The receiver re-checks deployment scope and runtime evidence.

yaml

target: sealos-deploy
inputArtifact: redacted database identity, private-access status, approved env-key contract, and connectivity/migration evidence
allowedAction: consume approved Secret/env references within the selected deployment scope
failureReturn: sanitized analyzer, CLI, env, or connectivity diagnostic with the failed phase
responseOwner: sealos-database

Direct database requests use

target: none

and keep the same evidence fields.

Verification

Use

analyze-project-database.mjs

sealos-cli

JSON output, app migration/connectivity evidence, and baseline cases

database-positive-reuse-redacted-connectivity

and

database-violating-unconfirmed-public-or-destructive

. Verify env preservation and redaction before accepting success.

Use this skill to give a project a real Sealos Cloud database during development. The default outcome is: identify the app's database need, create or reuse a Sealos database with

sealos-cli

, fetch connection details, wire only the needed local env vars, and verify the app can connect.

Safety Rules

Never print database passwords or full connection strings in the final answer.
Do not overwrite an existing env value without confirming or preserving the old value.
Do not commit
```
.env
```
,
```
.env.local
```
, connection strings, passwords, kubeconfig, or Sealos auth files.
Ask before enabling public database access. Prefer private connections when the app runs inside Sealos/Devbox.
Ask before destructive operations:
```
database delete
```
,
```
backup-delete
```
, restoring over a name that may collide, or disabling access that an active app depends on.
Use JSON output from
```
sealos-cli
```
by default and parse it instead of scraping table output.

Workflow

1. Resolve the target project

Confirm the working directory with

pwd

git rev-parse --show-toplevel

Run the analyzer when a project directory is available:

bash

node <SKILL_DIR>/scripts/analyze-project-database.mjs <project-dir>

Use the analyzer result as a starting point, then inspect the real files it cites before editing anything. It intentionally avoids printing secret values.

2. Check

sealos-cli

Prefer an existing

sealos-cli

binary:

bash

sealos-cli --version
sealos-cli database --help
sealos-cli whoami

If it is not installed, use

npx -y sealos-cli@latest ...

for one-off commands. Ask before installing it globally.

If auth is missing or expired, run:

bash

sealos-cli login <region>
sealos-cli workspace list
sealos-cli workspace current

Use the workspace the user expects. If multiple workspaces exist and the target is ambiguous, ask before provisioning.

3. Choose create or reuse

List existing databases first:

bash

sealos-cli database list -o json

Reuse an existing database when the name, type, and purpose match. Create a new one when the project has no suitable database or the user asks for a fresh dev database.

Use conservative development defaults unless the project clearly needs more:

bash

sealos-cli database create postgresql --name <app-dev-db> --cpu 1 --memory 1 --storage 3 --replicas 1 -o json

Before creating, check supported versions if version choice matters:

bash

sealos-cli database versions --type postgresql -o json

Supported CLI database types include

postgresql

mongodb

mysql

apecloud-mysql

redis

kafka

qdrant

nebula

weaviate

milvus

pulsar

, and

clickhouse

. Use the type detected from the project; default to

postgresql

only when the project has no database-specific signals.

4. Wait for readiness and fetch connection data

Poll details until the database is running or connection data is present:

bash

sealos-cli database get <name> -o json
sealos-cli database connection <name> -o json

Read

references/sealos-cli-database.md

for the current command contract and response handling.

5. Wire the development environment

Map the connection into the env var the project already uses:

Project signal	Preferred env key
Prisma, Drizzle, TypeORM, generic Postgres	`DATABASE_URL`
MySQL app with existing MySQL-specific config	`DATABASE_URL` or existing `MYSQL_URL`
MongoDB app	`MONGODB_URI`
Redis cache/queue	`REDIS_URL`

Use the existing local env convention:

Prefer
```
.env.local
```
for Next.js and frontend-adjacent projects.
Prefer
```
.env
```
only when the repo already uses it for local development and it is gitignored.
Treat
```
.env.example
```
as documentation only; never write real secrets there.
Preserve comments and unrelated keys.

If a connection string is not directly returned in the desired form, compose it from

host

port

username

, and

password

fields from

sealos-cli database connection

6. Verify application connectivity

Run the project's normal verification path, not just the CLI command:

Run migrations or introspection if the project has a clear command (
```
prisma migrate
```
,
```
drizzle-kit migrate
```
,
```
db:migrate
```
,
```
db:push
```
).
Start the app or run the smallest test that opens a DB connection.
If the app runs outside Sealos and cannot reach the private endpoint, ask before enabling public access:

bash

sealos-cli database enable-public <name> -o json
sealos-cli database connection <name> -o json

Disable public access after testing if it is no longer needed:

bash

sealos-cli database disable-public <name> -o json

7. Report the result

Summarize:

Database name, type, region/workspace, and status.
Env file and key updated, without revealing the secret value.
Verification command and outcome.
Any public access state and follow-up action.

Common Tasks

Connect an existing project to a Sealos database

Run the analyzer.
Inspect the env/config files it cites.
List existing Sealos databases.
Create or reuse the matching database.
Fetch connection details.
Write the expected env key.
Run the app's DB verification.

Replace a local Compose database for development

Identify the app service env vars that point at
```
postgres
```
,
```
mysql
```
,
```
mongo
```
, or
```
redis
```
compose services.
Provision the equivalent Sealos database.
Update only the app's local env file, not the compose file, unless the user asks to remove the local service.
Keep local Compose rollback simple: the original compose service remains available.

Add a database to a Devbox workflow

Use private database connection details when the Devbox runs in the same Sealos workspace.
Write env vars into the Devbox/app environment expected by the repo.
Restart or reload the Devbox process only after env vars are in place.

References

```
scripts/analyze-project-database.mjs
```
- read-only project database intent analyzer.

references/sealos-cli-database.md

sealos-cli database

command contract.

```
references/env-integration.md
```
- safe env-file editing and connection-string mapping.

sealos-database

NPX Install

Tags

SKILL.md Content

Sealos Database

Identity and Discovery

Scope and Boundaries

Risk and Confirmation

Lifecycle Workflow

Request Contract

Progressive Disclosure

Output, Stop, and Error States

Handoffs

Verification

Safety Rules

Workflow

1. Resolve the target project

2. Check
`sealos-cli`

3. Choose create or reuse

4. Wait for readiness and fetch connection data

5. Wire the development environment

6. Verify application connectivity

7. Report the result

Common Tasks

Connect an existing project to a Sealos database

Replace a local Compose database for development

Add a database to a Devbox workflow

References