diff --git a/cloud_docs/02-concepts/01-deployments.md b/cloud_docs/02-concepts/01-deployments.md
index 7d2527e4..d3ce509f 100644
--- a/cloud_docs/02-concepts/01-deployments.md
+++ b/cloud_docs/02-concepts/01-deployments.md
@@ -15,18 +15,13 @@ Deploy your project to Cloud:
 scloud deploy
 ```
 
-The CLI packages your project, uploads it, kicks off the build, and prints URLs you can access once the deployment is live:
+The CLI packages your project, uploads it, and tails the build through four lifecycle stages until the new version is serving traffic. Once the deployment is live, your project is reachable at its default URLs:
 
-```text
-✓ Project uploaded successfully! 🚀
-
-When the server has started, you can access it at:
-  Web:      https://my-app.serverpod.space/
-  API:      https://my-app.api.serverpod.space/
-  Insights: https://my-app.insights.serverpod.space/
+- Web: `https://<project-id>.serverpod.space/`
+- API: `https://<project-id>.api.serverpod.space/`
+- Insights: `https://<project-id>.insights.serverpod.space/`
 
-See `scloud domain --help` to set up a custom domain.
-```
+Set up your own URL with the [`scloud domain`](/cloud/reference/cli/commands/domain) command. See [Custom domains](/cloud/concepts/custom-domains).
 
 Other flags:
 
@@ -44,18 +39,19 @@ Watch the latest deployment as it runs:
 scloud deployment show
 ```
 
-The command prints a real-time lifecycle update:
+The command tracks the deployment through four stages and updates each line as it progresses:
 
 ```text
-Tracking status of my-app deploy 4583d0a1-3d0a-400e-a9a5-9880da6abc94, started at 2026-06-03 13:41:21:
+Tracking my-app deployment 4583d0a1-3d0a-400e-a9a5-9880da6abc94
+(Press Ctrl+C to exit)
 
-✓ Booster liftoff:      Upload successful!
-✓ Orbit acceleration:   Build successful!
-✓ Orbital insertion:    Deploy successful!
-✓ Pod commissioning:    Service successful! 🚀
+Upload successful.
+Cloud build successful.
+Infra deploy successful.
+Service rollout successful. 🚀
 ```
 
-The output marks each of the four lifecycle stages: **Booster liftoff** (upload), **Orbit acceleration** (build), **Orbital insertion** (deploy), and **Pod commissioning** (service ready).
+The stages: **Upload** (your project package reaches Cloud), **Cloud build** (Cloud builds the container), **Infra deploy** (the new version rolls out), and **Service rollout** (the new version takes traffic).
 
 List recent deployments:
 
diff --git a/cloud_docs/02-concepts/02-logs.md b/cloud_docs/02-concepts/02-logs.md
new file mode 100644
index 00000000..8850c981
--- /dev/null
+++ b/cloud_docs/02-concepts/02-logs.md
@@ -0,0 +1,142 @@
+---
+title: Logs
+description: How Serverpod Cloud surfaces logs through Insights, the scloud CLI for terminal access and filtering, and session-log configuration.
+---
+
+# Logs
+
+Serverpod Cloud collects logs from your running app and from each deployment's build, and surfaces them in two places: Serverpod Insights, a visual log viewer in the Cloud console; and the `scloud` CLI, which gives terminal access to runtime logs (with rich filtering) and is the only path to build logs from failed deploys.
+
+Insights is usually the right starting point for understanding what your app is doing because logs are grouped by session. The CLI is faster for one-off checks, supports filtering by time, and is the source of truth for build-time output.
+
+## View logs in Insights
+
+Open Insights from the Cloud console once a project is deployed. Sessions appear in a chronological list; selecting one expands into its messages, errors, and (when enabled per project) the database queries the session ran and the stack traces for any caught exceptions. Query logging and stack-trace capture add overhead, so they're off by default.
+
+:::tip
+
+Use Serverpod Insights for root-cause analysis. The session-grouped view makes it straightforward to follow a single request end-to-end, which is harder to do from terminal output.
+
+:::
+
+## View build logs
+
+Build logs are emitted while Cloud builds your deployment package: package installation, compilation, warnings, and errors. They're the first place to look when a deploy fails. Fetch the latest build log:
+
+```bash
+scloud deployment build-log
+```
+
+Pass a sequence number (where `0` is the latest) or a UUID to inspect a specific deployment; `scloud deployment list` shows the IDs:
+
+```bash
+scloud deployment build-log 3
+scloud deployment build-log 550e8400-e29b-41d4-a716-446655440000
+```
+
+For longer build logs, redirect to a file or filter inline:
+
+```bash
+scloud deployment build-log > build-log.txt
+scloud deployment build-log | grep ERROR
+```
+
+## View runtime logs
+
+Runtime logs are the live output of your deployed service. Each entry contains:
+
+- **Timestamp**: local time by default, UTC with `--utc`
+- **Level**: `INFO`, `ERROR`, and so on
+- **Origin service**: `API`, `insights`, or `web`
+- **Message body**
+
+Fetch the most recent records:
+
+```bash
+scloud log
+```
+
+By default this returns 50 records. Use `--limit` to fetch more (or fewer):
+
+```bash
+scloud log --limit 100
+```
+
+Pass `--utc` for UTC timestamps (useful when collaborating across time zones):
+
+```bash
+scloud log --utc
+```
+
+Pipe to standard shell tools for further filtering, or redirect to a file for sharing:
+
+```bash
+scloud log | grep ERROR
+scloud log > project_logs.txt
+```
+
+## Filter logs by time
+
+The `--since` and `--until` options accept either duration strings or ISO 8601 timestamps.
+
+Duration strings cover recent windows:
+
+```bash
+scloud log 120s              # last 120 seconds
+scloud log 5m                # last 5 minutes
+scloud log 12h               # last 12 hours
+scloud log 7d                # last 7 days
+scloud log --since 1h --until 10m
+```
+
+ISO 8601 strings allow specific times:
+
+```bash
+scloud log --since "2026-06-15T14:00:00Z"
+scloud log --since "2026-06-15T14:00:00Z" --until "2026-06-15T16:00:00Z"
+```
+
+Lower-precision ISO forms are also accepted:
+
+```bash
+scloud log --since "2026-06-15T14:00"     # without seconds
+scloud log --since "2026-06-15T14"        # without minutes and seconds
+scloud log --since "2026-06-15"           # just the date (starts at 00:00:00)
+```
+
+Duration and ISO forms can be mixed:
+
+```bash
+scloud log --since "2026-06-15T14:00:00Z" --until 30m
+scloud log --since 1h --until "2026-06-15T16:00:00Z"
+```
+
+## Stream logs
+
+Follow new log records as they arrive:
+
+```bash
+scloud log --tail
+```
+
+Press `Ctrl+C` to stop. `--tail` cannot be combined with `--since` or `--until`.
+
+## Configure session logging
+
+Two environment variables control how each request's session logs are handled. By default:
+
+- `SERVERPOD_SESSION_CONSOLE_LOG_ENABLED` defaults to `true`. Session logs print to the runtime console.
+- `SERVERPOD_SESSION_PERSISTENT_LOG_ENABLED` defaults to `false`. Session logs are not written to the database for later inspection.
+
+To change either default, set the value with `scloud variable set`. See [Passwords, secrets, and environment variables](/cloud/concepts/passwords-secrets-env-vars) for variable management.
+
+## Troubleshooting
+
+**Invalid timestamp format.** Use ISO 8601 form (`YYYY-MM-DDTHH:MM:SSZ`) or a supported duration string (`5m`, `2h`, `1d`).
+
+**No logs appearing.** Check that the time range is correct, that the app is running and generating output, and (for `--tail`) that you haven't also passed `--since` or `--until`.
+
+## Related
+
+- [CLI reference: `log` command](/cloud/reference/cli/commands/log)
+- [CLI reference: `deployment` command](/cloud/reference/cli/commands/deployment)
diff --git a/cloud_docs/02-concepts/03-passwords-secrets-env-vars.md b/cloud_docs/02-concepts/03-passwords-secrets-env-vars.md
new file mode 100644
index 00000000..0ea04314
--- /dev/null
+++ b/cloud_docs/02-concepts/03-passwords-secrets-env-vars.md
@@ -0,0 +1,147 @@
+---
+title: Passwords, secrets, and environment variables
+description: "Serverpod Cloud has three configuration tiers: encrypted passwords via the Serverpod API, encrypted secrets as named env vars, and plaintext variables."
+---
+
+# Passwords, secrets, and environment variables
+
+Serverpod Cloud has three tiers for project configuration. Passwords are encrypted and accessed through Serverpod's `getPassword()` API. Secrets are encrypted and injected as environment variables under a name you choose. Variables are plaintext, for non-sensitive configuration.
+
+|                       | Passwords                                              | Secrets                                                    | Variables                                               |
+| --------------------- | ------------------------------------------------------ | ---------------------------------------------------------- | ------------------------------------------------------- |
+| **CLI**               | `scloud password`                                      | `scloud secret`                                            | `scloud variable`                                       |
+| **Stored as**         | Env var with `SERVERPOD_PASSWORD_` prefix              | Env var (any name)                                         | Env var (any name)                                      |
+| **Encrypted**         | Yes                                                    | Yes                                                        | No (values visible in CLI and dashboard)                |
+| **Access in code**    | `session.serverpod.getPassword('name')`                | `Platform.environment['NAME']`                             | `Platform.environment['NAME']`                          |
+| **Use when**          | Serverpod code reads the value (preferred for secrets) | A dependency reads env vars and cannot use `getPassword()` | Non-sensitive config (URLs, feature flags)              |
+
+All three commands follow the same shape:
+
+- **`--name`** (mandatory): positional or as a flag
+- **Value**: positional, `--value`, or `--from-file`
+- **`-p, --project`**: required only when the project isn't linked
+- **`set` is create-or-update**: running it again with the same name overwrites the value
+
+## Manage passwords
+
+Passwords are the default tier for sensitive values the server reads through the Serverpod API. They are encrypted at rest, never shown after they're set, and accessed in code by the name you gave them. Each password is stored under a `SERVERPOD_PASSWORD_` prefix that the CLI adds on `set` and that `getPassword()` strips on read, so the name in your code stays clean.
+
+Serverpod Cloud also provisions a set of platform-managed passwords automatically: database credentials, Insights tokens, `serverpod_auth_idp_server` keys, and keys for the legacy auth module. `scloud password list` groups them into four categories: **Custom** (passwords you add), **Services** (database, Insights, and related platform passwords), **Auth** (passwords for `serverpod_auth_idp_server`), and **Legacy Auth** (passwords for the legacy authentication module). The Status column marks platform-managed passwords `AUTO (Platform)` and user-set ones `SET (User)`.
+
+Override a platform-managed password by setting a custom value with the same name. Unset it to restore the platform default.
+
+Set a password by name and value:
+
+```bash
+scloud password set myApiKey "your_secret_value"
+```
+
+Read the value in code:
+
+```dart
+final apiKey = await session.serverpod.getPassword('myApiKey');
+```
+
+Pass `--from-file` when the value is long, multi-line, or shouldn't appear in shell history:
+
+```bash
+scloud password set myApiKey --from-file path/to/file.txt
+```
+
+List all configured passwords:
+
+```bash
+scloud password list
+```
+
+Remove a user-added password:
+
+```bash
+scloud password unset myApiKey
+```
+
+## Manage secrets
+
+Secrets are the right tier when a library or dependency reads a value from `Platform.environment['SOMETHING']` and can't use the Serverpod API. They're encrypted at rest and never shown in the CLI after creation.
+
+Set a secret by name and value:
+
+```bash
+scloud secret set API_KEY "your_secret_value"
+```
+
+Read the value in code:
+
+```dart
+final apiKey = Platform.environment['API_KEY'];
+```
+
+Pass `--from-file` for long, multi-line, or sensitive values you don't want in shell history:
+
+```bash
+scloud secret set API_KEY --from-file path/to/file.txt
+```
+
+List configured secrets:
+
+```bash
+scloud secret list
+```
+
+Remove a secret:
+
+```bash
+scloud secret unset API_KEY
+```
+
+## Manage environment variables
+
+Variables are for non-sensitive configuration: URLs, feature flags, region names, or other settings that don't need encryption. Values are stored in plaintext and visible in the CLI and the Cloud console.
+
+Set a variable by name and value:
+
+```bash
+scloud variable set LOG_LEVEL "info"
+```
+
+Read the value in code:
+
+```dart
+final logLevel = Platform.environment['LOG_LEVEL'];
+```
+
+Pass `--from-file` to load the value from a file:
+
+```bash
+scloud variable set LOG_LEVEL --from-file path/to/file.txt
+```
+
+List configured variables:
+
+```bash
+scloud variable list
+```
+
+Remove a variable:
+
+```bash
+scloud variable unset LOG_LEVEL
+```
+
+:::warning
+
+Do not use variables for API keys, tokens, or passwords. Use passwords or secrets for sensitive data.
+
+:::
+
+## Limits
+
+The same naming and size rules apply across all three tiers:
+
+- Names use letters (`a-z`, `A-Z`), digits (`0-9`), and underscores (`_`) only, and must start with a letter or underscore.
+- Maximum name length is 255 characters.
+- Variables and secrets each have a separate per-project storage budget of 64,000 bytes (the total of all names plus values within that tier). Passwords share the secrets budget because they're stored as secrets under the `SERVERPOD_PASSWORD_` prefix.
+
+## Related
+
+- CLI reference: [`password`](/cloud/reference/cli/commands/password), [`secret`](/cloud/reference/cli/commands/secret), [`variable`](/cloud/reference/cli/commands/variable)
diff --git a/cloud_docs/02-concepts/04-custom-domains.md b/cloud_docs/02-concepts/04-custom-domains.md
new file mode 100644
index 00000000..f7c0aeb0
--- /dev/null
+++ b/cloud_docs/02-concepts/04-custom-domains.md
@@ -0,0 +1,114 @@
+---
+title: Custom domains
+description: Custom domains attach to the web, API, or Insights surface of a Serverpod Cloud project, with automatic TLS and DNS-based verification.
+---
+
+# Custom domains
+
+Every Serverpod Cloud project gets default domains automatically. A project named `my-app` is reachable at:
+
+| Service  | Default domain                             |
+| -------- | ------------------------------------------ |
+| Web      | `https://my-app.serverpod.space/`          |
+| API      | `https://my-app.api.serverpod.space/`      |
+| Insights | `https://my-app.insights.serverpod.space/` |
+
+Custom domains let you replace any of those with your own URL. Serverpod Cloud provisions and renews TLS certificates automatically; the only setup required is a DNS record and a verification step.
+
+## Attach a custom domain
+
+A custom domain points at one of the three surfaces:
+
+- `web`: a Flutter web app or other content served by Serverpod's web server
+- `api`: Serverpod endpoints your Flutter app or other clients call
+- `insights`: the Serverpod Insights app (typically on a separate subdomain like `insights.example.com`)
+
+Attach the domain to your project, specifying the target surface:
+
+```bash
+scloud domain attach example.com --target web
+```
+
+After attaching, the CLI prints DNS records to add at your registrar. For an apex domain like `example.com`, two records are needed:
+
+```text
+Custom domain attached successfully!
+
+Complete the setup by adding the records to your DNS configuration
+
+┌────────────────────────────────────────────────────────────────────────────────┐
+│ Record type | Domain name | Value                                              │
+│ ------------+-------------+--------------------------------------------------- │
+│ ANAME       | example.com | my-app.api.serverpod.space                         │
+│ TXT         | example.com | scloud-verify=cbe1f5cc-f176-4183-8142-e0585ad15999 │
+│                                                                                │
+└────────────────────────────────────────────────────────────────────────────────┘
+```
+
+Each row corresponds to one record to add at your registrar:
+
+- **ANAME (or ALIAS)**: points the domain at the Serverpod Cloud surface
+- **TXT**: carries a verification token that Serverpod Cloud uses to confirm ownership
+
+Plain CNAMEs aren't valid at the zone apex, which is why ANAME or ALIAS is required there. [Cloudflare](https://www.cloudflare.com/), [Route 53](https://aws.amazon.com/route53/), and [DNSimple](https://dnsimple.com/) all support ANAME or ALIAS records.
+
+For a subdomain like `api.example.com`, a single CNAME record is enough:
+
+```text
+Custom domain attached successfully!
+
+Complete the setup by adding the records to your DNS configuration
+
+┌────────────────────────────────────────────────────────────┐
+│ Record type | Domain name     | Value                      │
+│ ------------+-----------------+--------------------------- │
+│ CNAME       | api.example.com | my-app.api.serverpod.space │
+│                                                            │
+└────────────────────────────────────────────────────────────┘
+```
+
+## Verify the domain
+
+DNS changes typically propagate within a few minutes but can take up to 48 hours. Once propagation completes, Serverpod Cloud verifies the domain automatically.
+
+To force a verification attempt without waiting:
+
+```bash
+scloud domain verify example.com
+```
+
+A successful verification triggers TLS certificate provisioning, which usually completes within the hour. Certificates are renewed automatically.
+
+Once the domain is active, point your client at the new URL:
+
+```dart
+final client = Client('https://api.example.com');
+```
+
+## List custom domains
+
+Show the domains attached to a project, with their target surface and verification status:
+
+```bash
+scloud domain list
+```
+
+## Detach a custom domain
+
+Remove a custom domain from a project. The CLI prompts for confirmation before removing:
+
+```bash
+scloud domain detach example.com
+```
+
+## Troubleshooting
+
+**Verification fails.** DNS records may be missing or still propagating. Confirm the records are in place at your registrar, then wait up to 48 hours and retry with `scloud domain verify <domain>`.
+
+**Can't attach the domain.** The domain is already attached to another project. Detach it from that project first.
+
+**TLS certificate errors.** TLS provisioning is still in progress. It usually completes within an hour of successful verification.
+
+## Related
+
+- [CLI reference: `domain` command](/cloud/reference/cli/commands/domain)
diff --git a/cloud_docs/02-concepts/05-database.md b/cloud_docs/02-concepts/05-database.md
new file mode 100644
index 00000000..ad2850f1
--- /dev/null
+++ b/cloud_docs/02-concepts/05-database.md
@@ -0,0 +1,103 @@
+---
+title: Database
+description: How Serverpod Cloud's managed PostgreSQL works, including provisioning, automatic server credentials, migrations on deploy, backups, user access, and resetting the database.
+---
+
+# Database
+
+Serverpod Cloud can provision and run a managed PostgreSQL database alongside your project. When the database is enabled, Cloud handles provisioning, connection details for your server, migrations on every deploy, and backups. Direct access from tools like `psql` or a GUI client is opt-in and requires a database user that you create yourself.
+
+The managed database runs on PostgreSQL 17 with TLS required, connection pooling on by default, and autoscaling compute. Cloud manages the infrastructure for you.
+
+## Enable the database
+
+The database is opt-in. You choose whether to enable it when you create the project, and you can enable it in two ways:
+
+- **Interactively with `scloud launch`.** Launch prompts you with *"Enable the database for the project?"* and defaults to yes.
+- **Non-interactively with `--enable-db`.** Pass `--enable-db` (or `--no-enable-db`) to `scloud launch` to skip the prompt. The same flag is **required** on `scloud project create`: it has no default there, so you must pass one.
+
+Once a project is created with the database enabled, the database is provisioned automatically and made available to your server on the next deploy.
+
+If your project doesn't use a database, pass `--no-enable-db` instead.
+
+## How your server connects
+
+When the database is enabled, your deployed Serverpod server receives its connection details as environment variables, injected by Cloud:
+
+| Variable                          | What it holds                       |
+| --------------------------------- | ----------------------------------- |
+| `SERVERPOD_DATABASE_HOST`         | The database host                   |
+| `SERVERPOD_DATABASE_PORT`         | The port (5432 by default)          |
+| `SERVERPOD_DATABASE_NAME`         | The database name                   |
+| `SERVERPOD_DATABASE_USER`         | The server's database user          |
+| `SERVERPOD_DATABASE_REQUIRE_SSL`  | Always `true`; TLS is required      |
+| `SERVERPOD_PASSWORD_database`     | The server's database password      |
+
+Your server reads these through Serverpod's standard configuration. You don't write them into `config/production.yaml` or `passwords.yaml`; Cloud supplies them at runtime. The server's password is managed by the platform and never exposed to you.
+
+## Migrations run on every deploy
+
+When Cloud deploys your server, the container starts with `--apply-migrations`. Any pending migrations in your project's `migrations/` directory are applied before the server begins serving requests.
+
+If a migration fails to apply, the server fails to start and the deployment is reported as failed. Fix the migration in your project and redeploy.
+
+To undo a migration that already applied successfully, write a new migration that reverses the change and deploy. Serverpod's migration system rolls forward, not backward.
+
+## Backups
+
+Cloud takes regular backups of the managed database. Backup behavior is handled by the platform and doesn't require any configuration from you.
+
+## Access the database directly
+
+You can connect to the managed database from your machine, a GUI client, or `psql` for inspection and debugging. This is independent of how your server connects.
+
+The steps:
+
+1. Run `scloud db connection` to print the host, port, and database name.
+2. Run `scloud db user create <username>` to create a superuser. The password is shown **once**; save it.
+3. Connect from your client with the host, port, database, your username, and the saved password.
+
+Both commands need to know which project you're working with. From a project directory that's been linked (any project created with `scloud launch` is linked automatically), the project ID is picked up from `scloud.yaml`. From anywhere else, pass `-p your-project-id`.
+
+If you lose the password, run `scloud db user reset-password <username>` to reset it. The new password is also shown only once.
+
+Any PostgreSQL-compatible client works. A few popular options:
+
+- [Postico](https://eggerapps.at/postico/), a focused PostgreSQL client for macOS
+- [pgAdmin](https://www.pgadmin.org/), the official open-source admin tool
+- [DBeaver](https://dbeaver.io/), cross-platform and free for personal use
+- [DataGrip](https://www.jetbrains.com/datagrip/), JetBrains' database IDE
+- `psql`, the standard PostgreSQL command-line client
+- A PostgreSQL VS Code extension if you prefer to stay in your editor
+
+## Reset the database
+
+`scloud db wipe` deletes all tables, all data, and all applied migrations from the managed database. It asks for confirmation by default.
+
+```bash
+scloud db wipe
+```
+
+After a wipe, your server will error on its next request because the schema is gone. Redeploy with `scloud deploy` to reapply migrations and bring the database back into a working state.
+
+Use this when you want to start clean during development. **Do not wipe a production database.**
+
+## Security
+
+The managed database is built so you don't have to think about credentials in your code or your repo:
+
+- **TLS is required for all connections.** Cloud sets `SERVERPOD_DATABASE_REQUIRE_SSL` to `true` for your server, and the same applies to direct connections from `psql` or a GUI client.
+- **The server's password is managed by the platform.** It's never written into your repo and never shown to you. Your server reads it from the injected environment at runtime.
+- **Direct access uses separate superusers that you create.** The server's user and the users you create with `scloud db user create` are distinct, so revoking or rotating a direct-access password does not affect the server.
+
+## Performance
+
+The managed database includes infrastructure features you'd otherwise wire up yourself:
+
+- **Connection pooling is on by default.** The connection details returned by `scloud db connection` point at a pooled endpoint, so short-lived connections from many clients don't exhaust Postgres connection slots.
+- **Compute autoscales.** The database scales compute up and down within bounds set by your plan, so you don't need to provision for peak traffic up front.
+
+## Related
+
+- [CLI reference: `scloud db`](/cloud/reference/cli/commands/db) for all `db` subcommands and options.
+- [Deployments](/cloud/concepts/deployments) for how migrations apply during deploy.
diff --git a/cloud_docs/02-guides/01-logs.md b/cloud_docs/02-guides/01-logs.md
deleted file mode 100644
index a3e589cc..00000000
--- a/cloud_docs/02-guides/01-logs.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Logs
----
-
-# Logs
-
-This guide covers the fastest ways to inspect logs in Serverpod Cloud. Use Serverpod Insights for structured investigation, and use the CLI for quick checks from your terminal and accessing build logs.
-
-## Prerequisites
-
-Before using logs, make sure you have:
-
-- Completed the **Installation** steps (`scloud` installed and authenticated).
-- Deployed a project to Serverpod Cloud.
-
-## Serverpod Insights
-
-Insights is Serverpod's built-in visual log viewer. After you have deployed your server, you can access Insights through the Cloud console. It's usually the best place to start looking if you need to access Serverpod's logs.
-
-With Insights you can see your log messages grouped by session. You can also choose to log database queries and stack traces.
-
-:::tip
-
-Use Serverpod Insights for root-cause analysis. Logs are grouped by session, which makes it easier to follow a single request end-to-end.
-
-:::
-
-## View build logs
-
-Build logs are the first place to look when a deployment fails.
-
-View the latest deployment build log:
-
-```bash
-scloud deployment build-log
-```
-
-View build logs for a specific deployment:
-
-```bash
-# By sequence number (0 is latest)
-scloud deployment build-log 3
-
-# By deployment UUID
-scloud deployment build-log 550e8400-e29b-41d4-a716-446655440000
-```
-
-To find the ID of a deployment use the `deployment list` command:
-
-```bash
-scloud deployment list
-```
-
-## Raw runtime logs
-
-To fetch the latest runtime logs for your deployed service:
-
-```bash
-scloud log
-```
-
-By default, this returns recent log records. Add `--utc` if you want timestamps in UTC:
-
-```bash
-scloud log --utc
-```
-
-## Stream logs in real time
-
-To follow new logs continuously while reproducing an issue:
-
-```bash
-scloud log --tail
-```
-
-Press `Ctrl+C` to stop streaming.
-
-## Related documentation
-
-- [CLI reference: `log` command](../reference/cli/commands/log)
-- [CLI reference: `deployment` command](../reference/cli/commands/deployment)
diff --git a/cloud_docs/02-guides/02-passwords.md b/cloud_docs/02-guides/02-passwords.md
deleted file mode 100644
index e5fcc36d..00000000
--- a/cloud_docs/02-guides/02-passwords.md
+++ /dev/null
@@ -1,134 +0,0 @@
----
-title: Passwords and env vars
----
-
-# Passwords and environment variables
-
-This guide shows how to set passwords, secrets, and environment variables for your Serverpod Cloud project. Use passwords when your server code can use Serverpod's API; use secrets when a dependency only reads environment variables; use variables for non-sensitive configuration.
-
-## Prerequisites
-
-Before configuring values, make sure you have:
-
-- Completed the **Installation** steps (`scloud` installed and authenticated).
-- Linked your project (e.g. run from your server directory, or use `scloud project link`).
-
-## Passwords vs secrets vs variables
-
-| | Passwords | Secrets | Variables |
-| --- | --- | --- | --- |
-| **CLI** | `scloud password` | `scloud secret` | `scloud variable` |
-| **Stored as** | Env var with `SERVERPOD_PASSWORD_` prefix | Env var (any name) | Env var (any name) |
-| **Encrypted** | Yes | Yes | No (values visible in CLI and dashboard) |
-| **Access in code** | `session.serverpod.getPassword('name')` | `Platform.environment['NAME']` | `Platform.environment['NAME']` |
-| **Use when** | Serverpod code needs the value (preferred for secrets) | A dependency reads env vars and cannot use `getPassword()` | Non-sensitive config (URLs, feature flags) |
-
-Under the hood, a **password** is a secret whose key is prefixed with `SERVERPOD_PASSWORD_`. Serverpod Cloud adds that prefix for you when you use `scloud password set`, and Serverpod's `getPassword()` looks up that prefixed key. Use **secrets** when you need a custom key name (e.g. for a third-party library that expects `API_KEY`).
-
-## Set a password
-
-Passwords are the right choice for sensitive values that your Serverpod endpoints or code can read via `getPassword()`. They are encrypted and only accessible through the Serverpod API.
-
-Set a password (run from your server project directory, or pass `-p your-project-id`):
-
-```bash
-scloud password set myApiKey "your_secret_value"
-```
-
-The name you pass is used without the prefix in code. In your server code you request it by that name:
-
-```dart
-final apiKey = await session.serverpod.getPassword('myApiKey');
-```
-
-To set a password from a file (e.g. to avoid putting the value in shell history or if the password is multiple lines):
-
-```bash
-scloud password set myApiKey --from-file path/to/file.txt
-```
-
-List existing password names (values are never shown):
-
-```bash
-scloud password list
-```
-
-Remove a password you set:
-
-```bash
-scloud password unset myApiKey
-```
-
-## Set a secret
-
-Use **secrets** when you need a sensitive value injected as an environment variable with a **specific key name**. Typical cases: a library or dependency that reads `Platform.environment['SOME_KEY']` and does not have access to Serverpod's `getPassword()`. Secrets are encrypted at rest and never shown in the CLI after creation.
-
-Create a secret:
-
-```bash
-scloud secret create API_KEY "your_secret_value"
-```
-
-Your app (or any code in the same process) can read it as:
-
-```dart
-final apiKey = Platform.environment['API_KEY'];
-```
-
-To create from a file:
-
-```bash
-scloud secret create API_KEY --from-file path/to/file.txt
-```
-
-List secret names (values are never shown):
-
-```bash
-scloud secret list
-```
-
-Secrets cannot be updated in place; delete and recreate to change a value:
-
-```bash
-scloud secret delete --name API_KEY
-scloud secret create API_KEY "new_value"
-```
-
-## Set an environment variable
-
-Use **variables** for non-sensitive configuration: URLs, feature flags, region names, or other settings that are fine to see in the Cloud console or CLI. Values are **not** encrypted.
-
-Create a variable:
-
-```bash
-scloud variable create LOG_LEVEL "info"
-```
-
-Update or delete as needed:
-
-```bash
-scloud variable update LOG_LEVEL "debug"
-scloud variable delete LOG_LEVEL
-```
-
-List variables (names and values are shown):
-
-```bash
-scloud variable list
-```
-
-In code, read them like any environment variable:
-
-```dart
-final logLevel = Platform.environment['LOG_LEVEL'];
-```
-
-:::warning
-
-Do not use variables for API keys, tokens, or passwords. Use **passwords** or **secrets** for sensitive data.
-
-:::
-
-## Related documentation
-
-- CLI reference: [`password`](../reference/cli/commands/password), [`secret`](../reference/cli/commands/secret), [`variable`](../reference/cli/commands/variable)
diff --git a/cloud_docs/02-guides/03-database.md b/cloud_docs/02-guides/03-database.md
deleted file mode 100644
index c4e86026..00000000
--- a/cloud_docs/02-guides/03-database.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: Access the database
----
-
-# Access the database
-
-This guide walks you through getting connection details, creating a database user, and connecting with a PostgreSQL client so you can inspect data, run queries, or debug issues directly.
-
-:::info
-
-Serverpod Cloud automatically manages a user and keys for your server to connect to your database. Use this guide if you want to connect to your database through other tools or services.
-
-:::
-
-## Prerequisites
-
-Before accessing the database, make sure you have:
-
-- Completed the **Installation** steps (`scloud` installed and authenticated).
-- A Serverpod Cloud project with the **database enabled** (e.g. you chose to enable it during `scloud launch` or created the project with `--enable-db`).
-- Linked your project (run commands from your server directory, or use `-p your-project-id`).
-
-## Get connection details
-
-From your server project directory (or with `-p your-project-id`), run:
-
-```bash
-scloud db connection
-```
-
-The command prints the host, port, and database name you need to connect. You still need a username and password; create a database user next.
-
-## Create a database user
-
-Serverpod Cloud does not show a default password for security reasons. Create a superuser to connect from your machine or a GUI client.
-
-Create a new user (choose any username):
-
-```bash
-scloud db user create myuser
-```
-
-The CLI prints a password **once**. Save it in a password manager or another secure place; it cannot be retrieved again.
-
-Example output:
-
-```text
-DB superuser created. The password is only shown this once:
-xxxxxxxxxxxxxxxxxxxxxxxx
-```
-
-If you lose the password, create a new user or reset the password for the existing user:
-
-```bash
-scloud db user reset-password myuser
-```
-
-The new password is shown once; save it immediately.
-
-## Connect with a PostgreSQL client
-
-Use the connection details from `scloud db connection` and the username and password you created. Enter them in your client as follows:
-
-| Field | Where to get it |
-| --- | --- |
-| **Host** | From `scloud db connection` |
-| **Port** | From `scloud db connection` |
-| **Database** | From `scloud db connection` (often the default database name) |
-| **User** | The username you passed to `scloud db user create` |
-| **Password** | The one-time password printed when you created or reset the user |
-
-Suggested GUI clients:
-
-- **[Postico](https://eggerapps.at/postico/)** – PostgreSQL client for macOS with a simple interface.
-- **[pgAdmin](https://www.pgadmin.org/)** – Open-source admin and management tool (all platforms).
-- **[DBeaver](https://dbeaver.io/)** – Universal database tool supporting PostgreSQL and others.
-- **[DataGrip](https://www.jetbrains.com/datagrip/)** – JetBrains database IDE with advanced query and schema tools.
-
-Any client that supports PostgreSQL (e.g. `psql`, VS Code extensions) will work with the same details.
-
-## Related documentation
-
-- CLI reference: [`scloud db`](../reference/cli/commands/db) – All `db` subcommands and options
diff --git a/cloud_docs/02-guides/04-custom-domains.md b/cloud_docs/02-guides/04-custom-domains.md
deleted file mode 100644
index 4eb57c8f..00000000
--- a/cloud_docs/02-guides/04-custom-domains.md
+++ /dev/null
@@ -1,169 +0,0 @@
----
-title: Custom domains
----
-
-# Custom domains
-
-Serverpod Cloud automatically provides default domains for your projects, but you can also configure custom domains to use your own branded URLs.
-
-## Default domains
-
-Every Serverpod Cloud project automatically gets these domains:
-
-| Service | Default Domain |
-|---------|---------------|
-| Web | `https://my-app.serverpod.space/` |
-| API | `https://my-app.api.serverpod.space/` |
-| Insights | `https://my-app.insights.serverpod.space/` |
-
-## Prerequisites
-
-Before setting up a custom domain in Serverpod Cloud, you need:
-
-1. A registered domain name
-2. Administrative access to your domain's DNS settings
-3. A deployed Serverpod Cloud project
-
-## Steps to attach a custom domain
-
-1. **Choose which service to link your domain to**
-
-   Decide whether your custom domain should point to your web server, API, or insights app.
-
-   - **Web server**: This is where your public-facing web content is served. If you're building a website or web application with Serverpod's built-in web server, this is typically what you want your main domain to point to.
-
-   - **API**: This is the entry point for your Serverpod's API server that your Flutter apps or other clients will communicate with. This is the domain used by all your endpoints.
-
-   - **Insights**: This provides access to Serverpod Insights, which gives you visibility into your server's performance, logs, and metrics. This is typically used by developers and administrators rather than end users, so it's often set up on a separate subdomain like `insights.yourdomain.com`.
-
-2. **Attach the domain to your Serverpod Cloud project**
-
-   ```bash
-   scloud domain attach example.com --target web
-   ```
-
-   Available targets are:
-   - `web` - For the web server
-   - `api` - For API endpoints
-   - `insights` - For the Serverpod Insights app
-
-3. **Configure your DNS settings**
-
-   After attaching the domain, you'll receive specific DNS configuration instructions:
-
-   **For a apex domain (example.com):**
-
-   ```text
-   Custom domain attached successfully!
-
-   Complete the setup by adding the records to your DNS configuration
-
-   ┌────────────────────────────────────────────────────────────────────────────────┐
-   │ Record type | Domain name | Value                                              │
-   │ ------------+-------------+--------------------------------------------------- │
-   │ ANAME       | example.com | my-app.api.serverpod.space                         │
-   │ TXT         | example.com | scloud-verify=cbe1f5cc-f176-4183-8142-e0585ad15999 │
-   │                                                                                │
-   └────────────────────────────────────────────────────────────────────────────────┘
-   ```
-
-   You'll need to add two records:
-   - An ANAME (or ALIAS) record pointing your domain to the Serverpod domain
-   - A TXT record with verification token (for domain ownership verification)
-
-   **For a subdomain (api.example.com):**
-
-   ```text
-   Custom domain attached successfully!
-
-   Complete the setup by adding the records to your DNS configuration
-
-   ┌────────────────────────────────────────────────────────────┐
-   │ Record type | Domain name     | Value                      │
-   │ ------------+-----------------+--------------------------- │
-   │ CNAME       | api.example.com | my-app.api.serverpod.space │
-   │                                                            │
-   └────────────────────────────────────────────────────────────┘
-   ```
-
-   For subdomains, you'll typically only need to add a CNAME record.
-
-4. **Verify your domain status**
-
-   After updating your DNS settings, check the status of your domain:
-
-   ```bash
-   scloud domain list
-   ```
-
-   Once DNS propagation completes, your domain will be verified automatically.
-
-5. **Manually verify your domain**
-
-   If you've updated your DNS settings and want to force a verification, you can manually trigger verification:
-
-   ```bash
-   scloud domain verify example.com
-   ```
-
-   If verification succeeds, you'll see a confirmation message. If it fails, you'll receive information about what needs to be fixed in your DNS configuration.
-
-## DNS configuration tips
-
-### Using an apex domain
-
-If you want to use a apex domain (like `example.com` without the `www`), note that it requires special DNS handling:
-
-1. **Most DNS providers require ANAME/ALIAS records for apex domains**
-   - Standard CNAME records don't work for apex domains
-   - Providers like Cloudflare, Route53, DNSimple support ANAME/ALIAS records specifically for this purpose
-
-2. **Verification requires a TXT record**
-   - Apex domains need an additional TXT record with a verification token
-   - This proves domain ownership to Serverpod Cloud
-
-### DNS propagation
-
-DNS changes can take anywhere from a few minutes to 48 hours to propagate globally. If your domain verification fails initially, wait a few hours and try again.
-
-### SSL certificates
-
-Serverpod Cloud automatically provisions and manages SSL certificates for your custom domains. No additional steps are required for HTTPS.
-
-## Managing your custom domains
-
-### List your custom domains
-
-```bash
-scloud domain list
-```
-
-This will show all your custom domains, their targets, and verification status.
-
-### Detach a custom domain
-
-```bash
-scloud domain detach example.com
-```
-
-You'll be prompted to confirm the removal.
-
-## Troubleshooting
-
-| Issue | Possible Solution |
-|-------|------------------|
-| Verification fails | Check your DNS configuration and wait for propagation (up to 48 hours) |
-| Can't attach domain | Ensure the domain isn't already in use by another project |
-| SSL certificate errors | Wait for certificate provisioning to complete (usually within an hour) |
-
-## 🧪 Example code
-
-For clients using your custom domain for API:
-
-```dart
-// Initialize Serverpod client with custom domain
-final client = Client('https://api.example.com');
-
-// The rest of your code stays the same
-final result = await client.example.hello('John Doe');
-```
diff --git a/cloud_docs/02-guides/05-redis.md b/cloud_docs/02-guides/05-redis.md
index 4c8504cd..7c40c7da 100644
--- a/cloud_docs/02-guides/05-redis.md
+++ b/cloud_docs/02-guides/05-redis.md
@@ -75,4 +75,4 @@ After a successful deploy, your server will use Upstash for Redis-backed caching
 - [Serverpod configuration](https://docs.serverpod.dev/concepts/configuration) – Redis options and environment variables
 - [Serverpod caching](https://docs.serverpod.dev/concepts/caching) – Local and Redis-backed caches
 - [Upstash: Connect your client](https://upstash.com/docs/redis/howto/connectclient) – Connection details and TLS
-- [Passwords and environment variables](./02-passwords.md) – How Serverpod Cloud injects passwords and variables
+- [Passwords, secrets, and environment variables](/cloud/concepts/passwords-secrets-env-vars) – How Serverpod Cloud injects passwords and variables
diff --git a/cloud_docs/reference/01-deployment/04-deployment-hooks.md b/cloud_docs/reference/01-deployment/04-deployment-hooks.md
index f149ab0f..3622b81a 100644
--- a/cloud_docs/reference/01-deployment/04-deployment-hooks.md
+++ b/cloud_docs/reference/01-deployment/04-deployment-hooks.md
@@ -192,4 +192,4 @@ project:
 ## Related documentation
 
 - [Deployments](/cloud/concepts/deployments) - Deploy operations, status checks, package validation, and `.scloudignore` configuration.
-- [Configuration Overview](/cloud/guides/passwords) - Overview of secrets, variables, and passwords
+- [Passwords, secrets, and environment variables](/cloud/concepts/passwords-secrets-env-vars) - Project configuration tiers and operations.
diff --git a/cloud_docs/reference/02-logging.md b/cloud_docs/reference/02-logging.md
deleted file mode 100644
index 8ecbde51..00000000
--- a/cloud_docs/reference/02-logging.md
+++ /dev/null
@@ -1,218 +0,0 @@
-# View logs
-
-View logs from your running applications to monitor performance, diagnose issues, and track application behavior. Serverpod Cloud automatically collects logs from your applications. You can view these logs using the `scloud log` command, which provides powerful filtering and real-time monitoring capabilities.
-
-## Viewing deployment logs
-
-### Basic log viewing
-
-To view logs for your deployment:
-
-```bash
-scloud log
-```
-
-This displays the most recent logs for your deployment.
-
-### Filtering logs by time
-
-You can filter logs using the `--since` and `--until` options. Both options accept either ISO date strings or duration strings, providing flexibility in how you specify time ranges.
-
-#### Using duration strings
-
-You can quickly view logs from recent time periods using duration strings:
-
-```bash
-# View logs from the last 120 seconds
-scloud log 120s
-
-# View logs from the last 5 minutes
-scloud log 5m
-
-# View logs from the last 12 hours
-scloud log 12h
-
-# View logs from the last 7 days
-scloud log 7d
-
-# View logs in a time range using durations
-scloud log --since 1h --until 10m
-```
-
-#### Using ISO date strings
-
-You can filter logs using ISO 8601 timestamp format:
-
-```bash
-# View logs after a specific time
-scloud log --since "2023-06-15T14:00:00Z"
-
-# View logs before a specific time
-scloud log --until "2023-06-15T16:00:00Z"
-
-# View logs in a time range
-scloud log --since "2023-06-15T14:00:00Z" --until "2023-06-15T16:00:00Z"
-```
-
-The timestamp format is flexible and supports various levels of precision:
-
-```bash
-# Full ISO 8601 format with seconds and timezone
-scloud log --since "2023-06-15T14:00:00Z"
-
-# Without seconds
-scloud log --since "2023-06-15T14:00"
-
-# Without minutes and seconds
-scloud log --since "2023-06-15T14"
-
-# Just the date (starts at 00:00:00)
-scloud log --since "2023-06-15"
-```
-
-#### Mixing ISO dates and durations
-
-You can mix ISO date strings and duration strings:
-
-```bash
-# View logs since a specific date until 30 minutes ago
-scloud log --since "2023-06-15T14:00:00Z" --until 30m
-
-# View logs since 1 hour ago until a specific date
-scloud log --since 1h --until "2023-06-15T16:00:00Z"
-```
-
-### Real-time log streaming
-
-To continuously stream logs as they are generated:
-
-```bash
-scloud log --tail
-```
-
-Press `Ctrl+C` to stop the stream.
-
-> ⚠️ **Note**: The `--tail` flag cannot be used together with the `--since` or `--until` options.
-
-### Display logs in UTC time
-
-By default, logs are displayed in your local time zone. To view logs in UTC time:
-
-```bash
-scloud log --utc
-```
-
-## Viewing build logs
-
-To diagnose issues during the deployment process, you can view the build logs for your deployments:
-
-### Basic build log viewing
-
-To view build logs for your most recent deployment:
-
-```bash
-scloud deployment build-log
-```
-
-### Viewing logs for specific deployments
-
-You can view build logs for specific projects or deployments:
-
-```bash
-# View build logs for a specific project
-scloud deployment build-log
-
-# View build logs for a specific deployment by index (0 is most recent)
-scloud deployment build-log 0
-
-# View build logs for a specific deployment by ID
-scloud deployment build-log abc123
-```
-
-### Understanding build logs
-
-Build logs show the complete output from the build process, including:
-
-- Package installation steps
-- Compilation messages
-- Warning and error messages
-
-If a deployment failed, the build logs will help you identify where the failure occurred and any specific error messages.
-
-### 💡 Tips for Build Logs
-
-- Use `scloud deployment list` to see all recent deployments before viewing logs for a specific one
-- Redirect lengthy build logs to a file for easier analysis:
-
-  ```bash
-  scloud deployment build-log > build-log.txt
-  ```
-
-- Filter for specific messages:
-
-  ```bash
-  scloud deployment build-log | grep ERROR
-  ```
-
-## 💡 Best Practices
-
-1. **Use specific time ranges** when debugging known issues to reduce noise
-2. **Enable UTC mode** (`--utc`) when collaborating with team members in different time zones
-3. **Combine with `grep`** for further filtering:
-
-   ```bash
-   scloud log | grep ERROR
-   ```
-
-4. **Redirect output to file** for persistence or sharing:
-
-   ```bash
-   scloud log > project_logs.txt
-   ```
-
-## Log format
-
-Each log entry includes:
-
-- Timestamp
-- Log level (INFO, ERROR, etc.)
-- Origin service (API, insights, or web)
-- Message content
-
-## 🧪 Example Scenarios
-
-### Monitoring during critical operations
-
-```bash
-# Stream logs in real-time with UTC timestamps
-scloud log --tail --utc
-```
-
-### Investigating a specific incident
-
-```bash
-# View logs around a reported error
-scloud log --since "2023-07-10T13:45:00Z" --until "2023-07-10T14:15:00Z"
-```
-
-## Session logs configuration
-
-By default, the session logs settings are configured as follows:
-
-- `SERVERPOD_SESSION_CONSOLE_LOG_ENABLED`: `true`
-- `SERVERPOD_SESSION_PERSISTENT_LOG_ENABLED`: `false`
-
-If your application needs different log handling, please adjust these
-parameters using the `scloud variable create` command to set them
-as [environment variables](/cloud/guides/passwords#set-an-environment-variable).
-
-## Troubleshooting
-
-### Invalid timestamp format
-
-If you see an error about invalid timestamp format, ensure you're using ISO 8601 format (`YYYY-MM-DDTHH:MM:SSZ`).
-
-### No logs appearing
-
-- Check if your time range is correct
-- Ensure your application is running and generating logs
diff --git a/cloud_docs/reference/cli/commands/password/_password.md b/cloud_docs/reference/cli/commands/password/_password.md
index 58fe9cae..bf0411a2 100644
--- a/cloud_docs/reference/cli/commands/password/_password.md
+++ b/cloud_docs/reference/cli/commands/password/_password.md
@@ -49,4 +49,4 @@ If you need to set a secret without the `SERVERPOD_PASSWORD_` prefix, you can do
 - [`scloud secret`](/cloud/reference/cli/commands/secret) - Manage general secrets without the `SERVERPOD_PASSWORD_` prefix
 - [`scloud variable`](/cloud/reference/cli/commands/variable) - Manage non-sensitive configuration values
 
-For detailed information about when to use passwords vs secrets vs variables, see the [Configuration Management guide](/cloud/guides/passwords).
+For detailed information about when to use passwords vs secrets vs variables, see the [Passwords, secrets, and environment variables](/cloud/concepts/passwords-secrets-env-vars) concept page.
diff --git a/cloud_docs/reference/cli/introduction/introduction.md b/cloud_docs/reference/cli/introduction/introduction.md
index 2e5bad8a..f73ac045 100644
--- a/cloud_docs/reference/cli/introduction/introduction.md
+++ b/cloud_docs/reference/cli/introduction/introduction.md
@@ -32,7 +32,7 @@ to get an interactive, guided set up of a new Serverpod Cloud project:
 scloud launch
 ```
 
-If the project requires any environment variables, secrets, or passwords, they can be added with the [`variable`](/cloud/reference/cli/commands/variable), [`secret`](/cloud/reference/cli/commands/secret), and [`password`](/cloud/reference/cli/commands/password) commands. See the [Configuration Management guide](/cloud/guides/passwords) for details on when to use each. Once the project is ready to be deployed, run the following command:
+If the project requires any environment variables, secrets, or passwords, they can be added with the [`variable`](/cloud/reference/cli/commands/variable), [`secret`](/cloud/reference/cli/commands/secret), and [`password`](/cloud/reference/cli/commands/password) commands. See the [Passwords, secrets, and environment variables](/cloud/concepts/passwords-secrets-env-vars) concept page for details on when to use each. Once the project is ready to be deployed, run the following command:
 
 ```sh
 scloud deploy
diff --git a/docusaurus.config.js b/docusaurus.config.js
index aafd4fad..8fda3739 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -221,6 +221,22 @@ const config = {
             from: ['/cloud/reference/deployment/deploying-your-application'],
             to: '/cloud/concepts/deployments',
           },
+          {
+            from: ['/cloud/guides/logs', '/cloud/reference/logging'],
+            to: '/cloud/concepts/logs',
+          },
+          {
+            from: ['/cloud/guides/passwords'],
+            to: '/cloud/concepts/passwords-secrets-env-vars',
+          },
+          {
+            from: ['/cloud/guides/custom-domains'],
+            to: '/cloud/concepts/custom-domains',
+          },
+          {
+            from: ['/cloud/guides/database'],
+            to: '/cloud/concepts/database',
+          },
         ],
       },
     ],